Resumindo: engenharia de aproveitamento de agentes e sua superfície de ataque oculta
A engenharia de agentes é a prática de construir tudo em torno de um modelo de IA (instruções, ferramentas, permissões, memória e ciclos de feedback) que o transforma em um agente funcional. É nesse sistema de segurança, e não no modelo, que reside a maior parte do verdadeiro risco de segurança atualmente.
- A mudança: As equipes pararam de ajustar as instruções e começaram a projetar as estruturas de suporte. Agente = modelo + estrutura de suporte.
- O problema: O código reside em arquivos de texto simples (regras, habilidades, configurações do MCP) que são revisados como documentação, se é que são revisados.
- As provas: A vulnerabilidade Backdoor no arquivo de regras e as CVEs reais do MCP mostram que os atacantes já a estão visando.
- O conserto: Trate o chicote de fios como código. Faça o inventário, revise e digitalize-o antes do envio.
Toda discussão sobre segurança em IA acaba inevitavelmente chegando ao modelo. Ele pode ser desbloqueado (jailbreak)? Ele terá alucinações? O fornecedor está treinando com nossos dados?
Perguntas pertinentes. Mas, cada vez mais, são perguntas equivocadas. Quando um agente de IA exclui uma tabela de produção, acessa um sistema de segurança ou envia uma lista de clientes por e-mail para um desconhecido, raramente a falha está no modelo. O modelo fez exatamente o que sua estrutura permitia.
Agente = modelo + arnês
Ao longo do último ano, a indústria mudou silenciosamente o significado de construir com IA. A engenharia de instruções imediatas deu lugar à engenharia de contexto, e a engenharia de contexto deu lugar a algo maior: engenharia de aproveitamento de agentes.
A ideia é simples. Um modelo por si só é um mecanismo de raciocínio sem mãos. O conjunto de ferramentas é tudo o que lhe dá mãos e uma função: as instruções que segue, as ferramentas que pode utilizar, as permissões que possui, a memória que armazena e as verificações que detectam seus erros. Site de Martin Fowler descreve a engenharia de chicote de fios como o trabalho que os usuários de agentes de codificação agora fazem para tornar os agentes confiáveis, e um quadro acadêmico publicado este ano divide o sistema em onze responsabilidades, desde o acesso às ferramentas e a memória do projeto até as permissões e a verificação.
Os resultados são reais. Equipes que praticam engenharia de interfaces de agentes relatam que alterar apenas a interface, mantendo o mesmo modelo subjacente, pode mudar drasticamente os resultados de um agente. Isso levanta uma questão incômoda para qualquer pessoa na área de segurança: se a interface determina como o agente se comporta, ela determina como ele pode ser usado de forma abusiva.
Considere algo tão corriqueiro quanto instalar uma dependência. Um desenvolvedor para para verificar o nome do pacote. Um agente com a ferramenta certa simplesmente executa o comando e, se o pacote for malicioso, nada no modelo o impedirá. É exatamente isso que analisamos neste episódio do SafeDev Talks: O que muda quando agentes de IA instalam dependências? por conta própria, e por que a engenharia de aproveitamento de agentes se tornou silenciosamente um problema na cadeia de suprimentos.
Como a engenharia de aproveitamento de agentes se apresenta em um repositório?
Abra um repositório onde os desenvolvedores usam agentes de IA e a ferramenta estará lá, em arquivos que você provavelmente nunca analisou:
- Arquivos de regras e instruções (
AGENTS.md,.cursorrules, instruções do copiloto) que dizem ao agente como se comportar. - Arquivos de habilidades que inclui funcionalidades reutilizáveis que o agente carrega sob demanda.
- Configurações do servidor MCP que conectam o agente a ferramentas, bancos de dados e APIs.
- Avisos do sistema e modelos de avisos incorporado no código do aplicativo.
- Agente de fiação: quais ferramentas um agente pode acessar, quais dados ele pode recuperar e se existe alguma proteção intermediária.
Tudo está em texto simples. Tudo está committudo isso junto com o código. E tudo é revisado da mesma forma que a documentação: uma olhada rápida, uma aprovação, uma fusão. No entanto, cada um desses arquivos pode reescrever silenciosamente o que um agente é instruído a fazer e o que ele tem permissão para acessar.
Essa é a verdadeira consequência da engenharia de agentes: a configuração mais poderosa do seu software é agora a menos revisada.
Os atacantes já perceberam
Essa não é uma preocupação teórica. O cinto de segurança tem um histórico de incidentes curto, porém revelador.
- O Backdoor do Arquivo de Regras. Em março de 2025, pesquisadores revelaram um ataque no qual caracteres Unicode ocultos em um arquivo de regras instruíam assistentes de codificação de IA a inserir código malicioso, sem mencionar isso em sua resposta visível. Um revisor que leu o arquivo não encontrou nada de incomum. Agora, ele está catalogado como Estudo de caso MITRE ATLAS AML.CS0041.
- Ferramentas MCP envenenadas. Ao longo de 2025, pesquisadores demonstraram repetidamente que os agentes confiam implicitamente nas descrições das ferramentas, de modo que um servidor MCP malicioso pode direcionar um agente simplesmente descrevendo-se da maneira correta. No mesmo ano, CVE-2025-6514 Um cliente MCP amplamente baixado permitia a execução remota de comandos ao conectar-se a um servidor não confiável, classificado com 9.6 no CVSS.
- Agência excessiva. O OWASP Top 10 para candidaturas a mestrado em Direito (LLM) A agência excessiva é listada como um dos principais riscos: agentes que recebem mais ferramentas, permissões ou autonomia do que a tarefa exige. Isso não é uma falha do modelo, mas sim uma falha no projeto da estrutura de controle.cisíon.
Observe o padrão. Nenhum desses ataques quebra o modelo. Eles quebram o arnês, e o modelo fielmente faz o resto.
Por que sua pilha de segurança não o detecta?
E aqui está a parte complicada. A maioria das organizações já utiliza boas ferramentas de segurança de aplicativos (AppSec), e quase nenhuma delas foi desenvolvida especificamente para essa camada.
A análise estática entende o código, mas não sabe o que é um modelo ou por que um texto não confiável que flui para um prompt do sistema é relevante. A análise de composição inventaria pacotes, mas não enumera servidores MCP ou arquivos de habilidade. Os scanners de segredos podem não detectar uma chave de API presente em um arquivo de configuração de agente. Nenhuma dessas ferramentas é defeituosa. Elas foram simplesmente criadas para um mundo onde a configuração não dava ordens.
Assim, o desenvolvimento da infraestrutura de agentes avança rapidamente, e a equipe de segurança revisa a parte que consegue ver: o modelo e o código. A infraestrutura fica em uma posição intermediária.
Cinco hábitos para prender o arnês com segurança.
Garantir a segurança da engenharia de agentes não exige uma nova equipe. Exige apenas alguns hábitos que tratem a ferramenta como o que ela é: uma intenção executável.
| Hábito | Por que é importante | O que fazer |
|---|---|---|
| 1. Faça um inventário de todos os arneses. | Não é possível contratar agentes que ninguém declarou. | Encontre todos os modelos, agentes, servidores MCP, habilidades e prompts em seus repositórios, diretamente do código e dos arquivos de configuração, em vez de por meio de uma pesquisa. |
| 2. Analise os arquivos de configuração, como o código. | Regras, habilidades e configurações do MCP podem reescrever o que um agente faz, mas são revisadas como documentação. | Dê a eles o mesmo pull request análise minuciosa como lógica de aplicação, incluindo verificações de caracteres ocultos. |
| 3. Defina o que o agente carrega. | Um prompt ou modelo referenciado por um rótulo mutável pode ser redirecionado sem alteração de código. | Fixe prompts e modelos em versões imutáveis. |
| 4. Instale uma grade de proteção em cada pia. | Documentos recuperados, resultados de ferramentas e conteúdo do usuário podem conter instruções inseridas no modelo. | Coloque uma proteção lateral no caminho, sempre que esse conteúdo puder alcançar a maquete. |
| 5. Mantenha as credenciais fora do controle. | Chaves de provedores de IA em arquivos de prompts e configurações de agentes são uma vantagem fácil para um atacante. | Remova-os e continue verificando os arquivos de segurança em busca de segredos. É uma solução fácil. |
Garantir a segurança do arnês, e não apenas do modelo.
Segurança de IA da Xygeni Começa onde a engenharia de aproveitamento de agentes deixa sua marca: em seus repositórios. Ela descobre os recursos de IA em toda a sua base de código (modelos, agentes, servidores MCP, habilidades, prompts, etc.). guardrailse as ferramentas de codificação de IA em uso) a partir do código, das dependências e dos arquivos de configuração que essas ferramentas deixam para trás.
Em seguida, analisa arquivos de habilidades, arquivos de regras e configurações do MCP como artefatos de segurança, não como documentação, e detecta riscos de injeção de prompts na configuração do agente, como conteúdo não confiável chegando a um prompt do sistema ou a um coletor de recuperação sem proteção. A verificação de segredos do Xygeni identifica credenciais de provedores de IA em prompts e arquivos de configuração do agente, e as dependências da sua pilha de IA recebem a mesma detecção de malware que todo o resto, antes mesmo de existir uma assinatura.
Perguntas frequentes
O que é engenharia de aproveitamento de agentes?
A engenharia de infraestrutura de agentes é a disciplina que se dedica a projetar o ambiente em torno de um modelo de IA (instruções, ferramentas, permissões, memória, contexto e ciclos de verificação) para que ele se comporte como um agente confiável. O modelo fornece o raciocínio; a infraestrutura decide o que o agente pode ver e fazer.
Qual a diferença entre engenharia de aproveitamento de agentes e engenharia de estímulos?
A engenharia de prompts define uma única instrução. A engenharia de sistemas de agentes define todo o sistema em que o agente opera, abrangendo várias etapas, ferramentas e sessões. Um prompt é um arquivo nesse sistema.
Por que o arnês representa um risco de segurança?
Porque controla o que um agente pode fazer e reside em arquivos de texto simples que raramente são revisados como artefatos de segurança. Comprometa um arquivo de regras ou uma configuração do MCP e você controla o agente, sem alterar o modelo.
Quem deve ser o responsável pela segurança do agente?
Segurança de aplicações, trabalhando com os engenheiros que criam e configuram os agentes. O framework faz parte do software que você distribui, portanto, deve ser submetido aos mesmos processos de revisão, verificação e inventário que o restante do seu código.
