Ferramentas abertas miram validação reproduzível de agentes de IA, com testes Pytest, análise de premissas de projeto e foco em injeção indireta de prompts, regressões e risco de exfiltração.
| Componente | RAMPART e Clarity, duas ferramentas abertas da Microsoft voltadas ao desenvolvimento e à validação de segurança de agentes de IA. |
| Vetor | RAMPART executa casos de teste Pytest por meio de um adaptador conectado ao agente, permitindo sondar fluxos como injeção indireta de prompts por e-mail, arquivo ou página web processada pelo sistema. |
| Impacto | A abordagem permite transformar achados de red teaming em testes reproduzíveis, verificar mitigações e detectar regressões comportamentais ou risco condicionado de exfiltração antes da entrega do agente. |
| Prioridade | Equipes que constroem agentes devem registrar decisões de projeto, limitar acesso a ferramentas sensíveis e manter testes executáveis para validar comportamento de segurança ao longo do ciclo de vida. |
| Artefatos | RAMPART é descrito como uma estrutura nativa de Pytest e se apoia no PyRIT; Clarity atua como mecanismo estruturado para questionar premissas, explorar soluções, analisar falhas e rastrear decisões. |
A Microsoft abriu duas ferramentas para apoiar equipes que desenvolvem agentes de inteligência artificial: RAMPART, voltada a testes executáveis de segurança e segurança operacional, e Clarity, orientada à análise estruturada de decisões antes da implementação. O foco técnico está no deslocamento de parte do red teaming para etapas mais iniciais da engenharia, quando mudanças de arquitetura, limites de acesso e hipóteses de comportamento ainda podem ser corrigidos sem reescrever o sistema já entregue.
RAMPART, sigla para Risk Assessment and Measurement Platform for Agentic Red Teaming, funciona como uma estrutura nativa de Pytest para escrever e executar testes contra agentes de IA. A ferramenta cobre cenários adversariais e benignos, além de diferentes categorias de dano, permitindo que engenheiros descrevam casos em que o agente é atacado, sondado ou colocado diante de entradas não confiáveis. O resultado esperado é um conjunto de artefatos executáveis que avaliam se o comportamento do agente viola requisitos de segurança, segurança de uso ou desenho previsto.
Clarity tem papel diferente: a ferramenta funciona como um mecanismo de raciocínio estruturado para discutir intenção de projeto, premissas, alternativas, modos de falha e decisões registradas antes do código existir. Em agentes de IA, essa etapa é relevante porque muitos riscos não surgem apenas do modelo, mas da combinação entre instruções, dados externos, ferramentas conectadas, permissões e objetivos definidos para o agente. Quando uma decisão como conceder acesso a uma ferramenta é tomada sem explicitar motivo, limite e consequência, a superfície de ataque cresce sem uma trilha clara para auditoria posterior.
O funcionamento de RAMPART depende de um adaptador que conecta o agente avaliado à suíte de testes. A partir desse ponto, os casos escritos pela equipe podem estimular o agente com entradas de teste, observar respostas e avaliar resultados. Essa arquitetura é importante porque evita que a validação fique limitada a análises pontuais feitas por especialistas depois que o sistema já está pronto. Ao adotar um formato compatível com Pytest, os testes passam a se parecer mais com ativos de engenharia mantidos junto ao produto, em vez de relatórios isolados de avaliação.
Um dos cenários citados é a injeção indireta de prompts, também chamada no contexto de cross-prompt injection. Nesse tipo de risco, o dado malicioso ou enganoso não precisa ser digitado diretamente por um usuário no campo principal de interação. Ele pode estar presente em um e-mail, arquivo, página web ou outra fonte que o agente processa como parte de sua tarefa. Se o agente interpreta esse conteúdo não confiável como instrução operacional, pode alterar o comportamento esperado, ignorar restrições, usar uma ferramenta fora de contexto ou expor informação que deveria permanecer protegida.
A ferramenta também é descrita como capaz de apoiar testes para regressões comportamentais e risco de exfiltração de dados. Isso não significa que um incidente específico de vazamento tenha sido confirmado; o ponto técnico é que agentes mudam de comportamento quando prompts, ferramentas, políticas, modelos ou integrações são alterados. Um teste que antes verificava a recusa a uma ação insegura pode voltar a falhar após uma modificação legítima no sistema. Ao tornar o cenário reproduzível, a equipe consegue diferenciar uma melhoria funcional de uma regressão de segurança.
RAMPART se apoia no PyRIT, ferramenta anterior da Microsoft voltada à identificação de risco em sistemas de IA. A distinção operacional apresentada é que PyRIT foi otimizado para descoberta em caixa-preta por pesquisadores de segurança após a construção do sistema, enquanto RAMPART busca servir engenheiros durante a construção. Essa diferença muda o momento da defesa: em vez de esperar uma revisão final, a equipe passa a acumular hipóteses, achados e verificações como parte do desenvolvimento contínuo do agente.
Clarity complementa esse fluxo ao atuar antes da implementação. A ferramenta orienta discussões sobre clareza do problema, exploração de solução, análise de falhas e rastreamento de decisões. Para um agente com acesso a ferramentas, esse registro é útil porque obriga a equipe a justificar quais capacidades são necessárias, quais condições de uso são aceitáveis e quais falhas precisam ser tratadas. Em segurança de agentes, decisões não documentadas sobre acesso, escopo e confiança em fontes externas costumam ser tão relevantes quanto bugs tradicionais de código.
A superfície principal são agentes de IA em desenvolvimento que consomem dados externos e podem executar ações por meio de ferramentas conectadas. Isso inclui sistemas que leem documentos, e-mails, páginas web, registros internos ou outros conteúdos fornecidos por usuários e fontes automatizadas. O risco aumenta quando o agente mistura instruções confiáveis, dados não confiáveis e permissões de ação em uma mesma cadeia de decisão.
O componente sensível não é apenas o modelo de linguagem, mas a orquestração ao redor dele: adaptadores, conectores de dados, ferramentas acessíveis, políticas de autorização, prompts de sistema, testes de regressão e critérios de avaliação. Um agente que somente responde perguntas tem uma superfície diferente de um agente que pode consultar sistemas internos, abrir chamados, alterar registros ou encaminhar conteúdo. A proposta de RAMPART e Clarity se encaixa justamente nesse ponto, pois tenta transformar essas diferenças de desenho em testes e decisões verificáveis.
- Agentes que processam e-mail, arquivos ou páginas web como entrada não confiável.
- Agentes com acesso a ferramentas cuja autorização precisa ser justificada e limitada no projeto.
- Sistemas de IA que mudam com frequência e podem sofrer regressões de comportamento após ajustes de prompts, integrações ou políticas.
- Fluxos de engenharia que já usam testes automatizados e podem incorporar casos de segurança executáveis contra o agente.
A adoção dessas ferramentas não substitui telemetria operacional. Para equipes de defesa, os testes de RAMPART devem ser tratados como uma base de validação e não como prova absoluta de ausência de risco. O monitoramento precisa observar entradas não confiáveis que chegam ao agente, decisões tomadas após processar esses dados, ferramentas invocadas, parâmetros enviados e diferenças entre comportamento esperado e comportamento real. O objetivo é descobrir quando um agente passou a seguir conteúdo externo como instrução de controle.
Em ambientes com agentes conectados a sistemas internos, registros de autorização e execução são essenciais. Uma chamada de ferramenta deve ser correlacionada com a origem da tarefa, a entrada que influenciou a decisão, o usuário ou serviço associado e o resultado produzido. Quando um teste de RAMPART representa um cenário de injeção indireta, a defesa pode transformar o mesmo raciocínio em consultas de telemetria: entradas contendo instruções suspeitas, uso inesperado de ferramentas após leitura de documentos externos e respostas que revelem mudança de política ou tentativa de expor dados.
Clarity contribui para hunting de forma indireta ao registrar intenção e premissas. Se uma decisão de projeto define que um agente não deve usar determinada ferramenta após consumir conteúdo externo, essa regra vira referência para auditoria. Sem esse registro, a equipe investiga apenas eventos isolados; com ele, consegue comparar comportamento observado contra uma decisão explícita. Essa trilha também ajuda a verificar se uma mitigação aplicada após um achado de red teaming permanece válida quando o produto evolui.
- Entradas de e-mail, arquivo ou página web que contenham instruções dirigidas ao agente em vez de dados de negócio.
- Invocações de ferramentas sensíveis logo após o processamento de conteúdo externo não confiável.
- Mudanças em respostas de recusa, política ou limite de ação após alterações no agente.
- Casos em que a saída do agente sugere divulgação indevida de informação ou execução fora da intenção documentada.
- Divergência entre decisões registradas no desenho e comportamento observado em testes ou logs.
A resposta defensiva começa com modelagem explícita do agente. Antes de conectar ferramentas ou fontes de dados, a equipe deve documentar a finalidade do agente, quais entradas são confiáveis, quais são não confiáveis, quais ferramentas podem ser chamadas e quais condições precisam bloquear uma ação. Clarity foi apresentado para apoiar esse tipo de discussão, principalmente quando ainda é barato alterar o desenho. A mitigação mais importante nessa fase é evitar que permissões e integrações sejam adicionadas sem justificativa verificável.
Depois que o agente existe, RAMPART permite transformar riscos conhecidos em testes reproduzíveis. A equipe pode escrever casos que representem injeção indireta de prompts, regressões de comportamento e situações em que o agente deve preservar limites de dados e ferramentas. Quando uma falha é corrigida, o teste correspondente deve permanecer como guarda contra regressão. Esse modelo também torna a mitigação verificável: a correção não é apenas uma alteração descrita em documento, mas um comportamento que pode ser exercitado novamente.
Como os testes dependem de um adaptador, a integração deve refletir o modo real de operação do agente sem expor comandos, segredos ou dados sensíveis. A validação deve priorizar cenários de alto impacto: ferramentas com efeito externo, acesso a informação interna, processamento de documentos não confiáveis e fluxos em que a saída do agente pode influenciar uma decisão automatizada. A defesa deve manter esses testes atualizados sempre que prompts, conectores, permissões, modelos ou políticas forem alterados.
A publicação de RAMPART e Clarity reforça uma mudança de processo: segurança de agentes não deve ser um evento único no fim do projeto. O ciclo defensivo precisa combinar decisão registrada, teste executável, observabilidade e revisão de comportamento. Para equipes que já constroem agentes, a ação prática é converter premissas críticas em artefatos verificáveis, validar mitigações com repetição controlada e tratar regressões de segurança com a mesma disciplina usada para regressões funcionais.
- Registrar premissas de projeto, intenção do agente, limites de ferramenta e critérios de falha antes da implementação.
- Criar testes de segurança executáveis para injeção indireta de prompts, regressões e risco condicionado de exfiltração.
- Manter o adaptador de teste alinhado ao fluxo real do agente sem incluir segredos ou dados confidenciais.
- Reexecutar testes após mudanças em prompts, ferramentas, políticas, modelos ou fontes de dados.
- Correlacionar resultados de teste com logs de entrada, decisão e chamada de ferramenta para validar mitigação em operação.
0 Comentários