Integração do Pillar Security com o TrueFoundry

‍Estamos entusiasmados em anunciar nossa parceria com a Pillar Security, que traz guardrails adaptativos de tempo de execução diretamente para o caminho do tráfego de agentes de IA e LLMs.

Equipes que roteiam o tráfego de modelos e agentes através do AI Gateway da TrueFoundry agora podem conectar a Pillar Security como um provedor de guardrails de primeira classe para obter varredura em tempo real e aplicação de políticas em prompts e respostas, chamadas de ferramentas e interações MCP em produção. A integração funciona nos quatro hooks de guardrail expostos pelo gateway e não requer alterações no código do agente ou da aplicação.

Esta publicação aborda a arquitetura da integração. Ela explica como o TrueFoundry AI Gateway executa guardrails em tempo de execução, como o pipeline de scanner da Pillar se conecta a esse modelo de execução e como as equipes configuram regras que visam modelos específicos, servidores MCP e populações de usuários.

Por que a IA agêntica empresarial precisa de duas camadas

TrueFoundry fornece a camada de controle para sistemas de IA em produção. Através do AI Gateway, as equipes centralizam o roteamento de modelos, gerenciamento de chaves, controle de acesso, observabilidade e governança em LLMs, ferramentas e fluxos de trabalho conectados a MCP. Cada solicitação flui através de uma única camada de proxy onde a identidade é verificada, limites de taxa são aplicados e rastreamentos são capturados.

Pillar Security fornece a camada de segurança em tempo de execução. Seus modelos de detecção escaneiam prompts e respostas em busca de tentativas de jailbreak, injeção de prompt, dados PII e PCI, segredos, linguagem tóxica e ataques de caracteres invisíveis. Os guardrails adaptativos da Pillar são informados por exercícios de red teaming executados contra a mesma aplicação e se ajustam ao propósito de negócio definido do agente para reduzir falsos positivos.

Juntas, as duas soluções oferecem às equipes uma arquitetura de produção limpa. A TrueFoundry lida com a implantação, roteamento e controle operacional. A Pillar lida com a inspeção em tempo de execução, detecção de ameaças e aplicação de políticas. A Pillar Security é suportada como um provedor de guardrails de primeira classe dentro do gateway TrueFoundry com hooks em llm_input_guardrails, llm_output_guardrails, mcp_tool_pre_invoke_guardrails e mcp_tool_post_invoke_guardrails.

A lacuna nas implantações de agentes em produção

A maioria das equipes que constroem agentes de IA se concentra em acertar a implantação e a confiabilidade. O agente precisa chamar as ferramentas certas, gerenciar o contexto em conversas longas, lidar com novas tentativas e escalar para vários usuários. Esse trabalho é necessário, mas não responde à questão da segurança em tempo de execução.

A segurança em muitas implantações de IA agêntica para no perímetro. Controles de acesso à plataforma, listas de permissões de servidores MCP, permissões em nível de ferramenta e credenciais com escopo para sistemas downstream estão todos em vigor. Esses controles são importantes, mas deixam o caminho de tempo de execução sem inspeção.

As perguntas que o perímetro não pode responder incluem o que o agente está realmente fazendo uma vez que começa a executar, quais ferramentas ele está chamando, em que sequência e com quais dados. Se uma injeção de prompt passar por um contexto recuperado, por uma resposta de servidor MCP ou por um resultado de API externa, o perímetro não tem visibilidade se o agente está prestes a agir sobre ela.

Guardrails de tempo de execução no caminho do gateway

A ideia arquitetônica por trás desta integração é direta. Se todo o tráfego de modelos, ferramentas e MCP já flui através do gateway, então o gateway é o lugar certo para aplicar a segurança em tempo de execução. Com a Pillar conectada ao TrueFoundry AI Gateway, as equipes podem aplicar guardrails no mesmo caminho onde o tráfego do agente já está sendo roteado e governado. A avaliação acontece no tráfego ao vivo e não em rastreamentos revisados após a execução.

O Pillar Argus funciona como a camada adaptativa de tempo de execução. A Pillar aplica seus scanners a cada interação em produção para que as equipes de plataforma e segurança possam monitorar, avaliar e aplicar políticas sobre o comportamento do agente enquanto ele está acontecendo. As saídas do scanner incluem um identificador de sessão, um booleano sinalizado, os gatilhos por categoria e um array de evidências com o texto ofensivo e sua posição na entrada.

A Pillar expõe as seguintes categorias de detecção em tempo de execução. Detecção de jailbreak identifica tentativas de contornar o treinamento de segurança do modelo. Injeção de prompt detecção cobre tanto a injeção direta quanto a indireta através de contexto recuperado ou saída de ferramenta. Detecção de PII e PCI cobre mais de quarenta categorias de dados pessoais e de cartão de pagamento e suporta mascaramento antes que os dados cheguem ao modelo. Detecção de segredos identifica chaves e tokens de API e credenciais em prompts ou na saída do modelo. Moderação de conteúdo e linguagem tóxica detecção cobrem conteúdo inseguro e que viola políticas. Caractere invisível detecção captura cargas úteis Unicode ocultas usadas para contrabandear instruções sem revisão humana.

Para sistemas agentivos, o Pillar avalia não apenas um único par de prompt e resposta, mas também as invocações de ferramentas, as requisições MCP e o contexto de execução multi-etapas. Muitas falhas de IA agentiva surgem ao longo de toda a cadeia de ações e não em uma única chamada de modelo.

Como o gateway executa as barreiras de segurança

O TrueFoundry AI Gateway é executado no framework Hono e um único pod de gateway lida com mais de 250 requisições por segundo em 1 vCPU e 1 GB de RAM, com aproximadamente 3 ms de latência adicionada. Os pods de gateway são sem estado e limitados pela CPU, e escalam horizontalmente para dezenas de milhares de RPS através de pods adicionais. O plano de controle e o plano de gateway são separados. A configuração, incluindo regras de barreiras de segurança, definições de modelo e limites de taxa, reside no plano de controle e sincroniza com os pods de gateway via NATS. O caminho real da requisição permanece na memória, sem chamadas externas além do provedor LLM.

As barreiras de segurança são executadas em quatro pontos de interconexão discretos no ciclo de vida da requisição.

llm_input_guardrails intercepta um prompt antes que ele chegue ao modelo. O gateway envia a carga útil de entrada para o Pillar primeiro. Se o Pillar retornar flagged: true para qualquer scanner configurado, a requisição é bloqueada e o LLM nunca é chamado. A chamada da barreira de segurança de entrada é executada concomitantemente com a requisição do modelo para otimizar o tempo até o primeiro token, e a chamada do modelo é cancelada imediatamente em caso de violação para evitar custos com o provedor.

llm_output_guardrails é acionado depois que o LLM respondeu, mas antes que a resposta seja retornada ao chamador. Os guardrails de saída são sequenciais. O gateway aguarda a saída do modelo e a submete ao Pillar para varredura antes de entregá-la ao cliente. Este é o ponto de aplicação para detectar vazamento de PII, exposição de segredos, geração tóxica e qualquer conteúdo inseguro produzido pelo modelo.

mcp_tool_pre_invoke_guardrails é acionado antes que uma ferramenta seja executada pelo agente. O Pillar avalia o nome da ferramenta, os argumentos e o contexto da chamada. Se os argumentos contiverem dados sensíveis ou indicarem acesso a recursos fora do escopo, a invocação da ferramenta é bloqueada antes que qualquer ação no mundo real ocorra.

mcp_tool_post_invoke_guardrails é acionado depois que a ferramenta retorna seu resultado e antes que esse resultado seja passado de volta para o loop de raciocínio do agente. Este é o ponto de aplicação para detectar injeção indireta de prompt na saída da ferramenta, vazamento de credenciais de servidores MCP e PII retornados por APIs upstream. Pará-lo aqui impede que o agente atue em um contexto comprometido.

Cada hook suporta três estratégias de aplicação. Aplicar bloqueia em caso de violação ou em caso de erro do serviço de guardrail. Aplicar, mas Ignorar em Caso de Erro bloqueia em caso de violação, mas permite que a solicitação prossiga se o próprio serviço de guardrail estiver inacessível. Auditoria registra o veredito e nunca bloqueia. Cada guardrail também suporta dois modos de operação. Validar o modo produz uma decisão de bloqueio ou permissão. Mutar o modo permite que o serviço de guardrail modifique o conteúdo em trânsito, que é como a capacidade de mascaramento do Pillar é integrada. O modo de máscara é configurado no lado do Pillar e exibe valores redigidos para PII e segredos correspondentes antes que o prompt chegue ao modelo.

A interface de integração

O Pillar é configurado no painel de controle do TrueFoundry como uma integração de guardrail com duas entradas. A primeira é a chave de API emitida pelo console do Pillar. A segunda é a configuração do scanner que seleciona quais categorias de detecção devem ser executadas para esta integração.

Uma vez que a integração é registrada, o gateway a expõe como um seletor que pode ser referenciado a partir de qualquer regra de guardrail. As regras são configuradas através de um bloco de regras YAML. Cada regra usa um bloco 'when' com duas condições. alvo corresponde a modelo ou mcpServers ou mcpTools ou metadados da requisição. assuntos corresponde à identidade do usuário ou da equipe com os operadores in e not_in. A regra então declara quais integrações de guardrail executar em qual dos quatro hooks.

Uma regra base que executa o Pillar na entrada e na saída para um modelo OpenAI usado por todas as equipes é assim.‍

name: guardrails-control
type: gateway-guardrails-config
rules:
  - id: pillar-baseline
    when:
      target:
        operator: or
        conditions:
          model:
            values:
              - openai-main/gpt-4o
            condition: in
      subjects:
        operator: and
        conditions:
          in:
            - team:everyone
    llm_input_guardrails:
      - pillar/pillar-default-profile
    llm_output_guardrails:
      - pillar/pillar-default-profile
    mcp_tool_pre_invoke_guardrails: []
    mcp_tool_post_invoke_guardrails: []

Uma segunda regra que adiciona a varredura do Pillar em torno de um servidor MCP usado por uma equipe de agentes visaria o servidor MCP e aplicaria a integração nos hooks de invocação de ferramenta pré e pós. Todas as regras correspondentes são avaliadas em conjunto e seus conjuntos de guardrail são unidos por hook. Duas regras que ambas visam llm_input_guardrails ambas serão executadas na entrada.

Substituições por requisição são suportadas através do X-TFY-GUARDRAILS cabeçalho. O cabeçalho contém um objeto JSON especificando seletores de guardrail para qualquer combinação dos quatro hooks. Isso permite que as equipes de aplicação fixem uma política mais rigorosa ou mais permissiva para uma chamada específica sem modificar a configuração global.

Cada decisão de guardrail é capturada no rastreamento da requisição. O span inclui o hook que foi acionado, o seletor de integração, o veredito, a latência da chamada do guardrail e as evidências retornadas pelo Pillar. Os rastreamentos são emitidos assincronamente via NATS e exportados via OTEL para qualquer backend de observabilidade que a equipe tenha configurado. O painel do Pillar exibe os mesmos eventos de seu lado, com transcrições completas de ataques e detalhamento por categoria para revisão de conformidade.

Resumo da Arquitetura

De ponta a ponta, o fluxo da requisição é assim. Um cliente envia uma requisição de conclusão de chat ou de agente para o gateway. O gateway autentica o chamador usando chaves IdP em cache e resolve o identificador do modelo através do roteamento de Modelo Virtual. As regras de guardrail correspondentes são avaliadas em memória e o payload de entrada é despachado para o Pillar concomitantemente com a chamada do modelo. Se o Pillar sinalizar a entrada, a chamada do modelo é cancelada e um erro estruturado é retornado. Se a entrada estiver limpa, a resposta do modelo é aguardada e submetida aos scanners de saída do Pillar antes da entrega. Para o tráfego de agentes, a mesma lógica se aplica em cada invocação de ferramenta MCP e em cada resposta de ferramenta antes que ela reentre no contexto do agente. Cada etapa é capturada em um span de rastreamento com o veredito do guardrail anexado.

Nada mais precisa ser alterado na aplicação. Não há SDK para instalar no cliente, nenhum sidecar para implantar junto ao agente e nenhum middleware de segurança por serviço para manter. O gateway já está no caminho da requisição e o Pillar se conecta a esse caminho através de sua API. O código cliente compatível com OpenAI existente continua funcionando sem modificações.

O princípio arquitetônico que torna isso limpo é a consolidação da aplicação de políticas na camada do gateway. Quando o tráfego de modelos, o tráfego de ferramentas e o tráfego MCP convergem em um único proxy, então os guardrails configurados nesse proxy se aplicam uniformemente a cada modelo, cada equipe e cada agente, sem código por aplicação. Os scanners do Pillar são executados em linha no mesmo ponto e o modelo de hook do gateway dá ao Pillar acesso aos quatro pontos de aplicação onde as decisões em tempo de execução realmente importam.

Começar

Saiba mais sobre o TrueFoundry AI Gateway e a plataforma Pillar Security. Conecte o Pillar na configuração de guardrails do TrueFoundry e referencie o seletor de integração de qualquer regra que vise seus modelos ou servidores MCP.