Solução · AI Operations
O teu agente de IA não precisa de se enganar para fazer estragos. Basta que alguém de fora lhe fale.
A governação de agentes decide o que o teu tem permissão para fazer. A segurança decide o que alguém que não trabalha aqui lhe consegue fazer fazer: uma instrução escondida num e-mail que o agente lê, uma ferramenta que ninguém auditou, um segredo que viaja no contexto. Montamos essa camada —isolamento, identidade, filtragem e rasto forense— e operamo-la.
O problema
Um agente com permissões é uma superfície de ataque nova. Não a cobre o teu fornecedor de segurança nem a cobre a tua camada de governação.
- O teu agente lê e-mails, tickets, documentos ou páginas web. Tudo isso é texto que alguém de fora escreveu, e o modelo não distingue o que tu lhe pediste do que chega dentro do conteúdo.
- As credenciais do agente não são dele: são as de um utilizador técnico com mais permissões do que qualquer pessoa da equipa, e vivem numa variável de ambiente que ninguém rodou desde o primeiro dia.
- Cada ferramenta que lhe ligas alarga o que ele pode fazer e, na mesma medida, o que lhe podem fazer fazer. Ninguém revê quem publicou esse conector, o que pede em cada chamada, nem o que mudou na última versão.
- O contexto arrasta dados de um caso para o seguinte porque a sessão nunca é limpa, ou porque o índice de onde recupera informação não filtra pelas permissões de quem está a perguntar.
- Se amanhã alguém perguntar o que fez o agente, com que dados e sob que versão, a resposta está espalhada pelos registos de três sistemas que não partilham identificador.
O custo de continuar igual
A lista de referência do setor já não deixa margem para dúvida: no OWASP Top 10 for LLM Applications, edição de 2025, a injeção de instruções ocupa o primeiro lugar pela segunda edição consecutiva, a exposição de informação sensível o segundo, a cadeia de fornecimento o terceiro e o excesso de autonomia —dar ao agente mais capacidade do que a tarefa exige— o sexto. Não é um risco futuro: é exatamente o guião com que te vai olhar quem quer que audite o teu sistema, seja o teu cliente grande, a tua seguradora ou o teu regulador. E o custo de não ter resposta não se paga em tickets abertos: paga-se num dado que saiu, numa ação que foi executada e numa explicação que não podes dar porque não há rasto.
A solução
Montamos a camada de segurança do agente —isolamento, identidade, filtragem e rasto forense— e operamo-la como função contínua
- 1Modelamos a ameaça agente a agente, o passo que quase ninguém dá: de onde vem o texto que lê, que dados alcança, que ações pode executar e o que acontece se um terceiro controlar qualquer uma dessas três coisas. É daí que sai a lista do que há para blindar, por ordem — e não ao contrário.
- 2Separamos instrução de dado. O que vem de fora entra como conteúdo, nunca como ordem: modelos que o conteúdo não pode reescrever, filtragem à entrada e validação da saída antes de tocar num sistema real. Que o modelo se deixe convencer é gerível; que a sua saída se execute sem revisão, não.
- 3Damos a cada agente identidade própria em vez de uma chave-mestra partilhada: credenciais de vida curta, privilégio mínimo por ferramenta e por dado, e ações sensíveis suportadas por uma autorização delimitada em vez de um token eterno num ficheiro de ambiente.
- 4Isolamos a execução das ferramentas: ambiente delimitado, lista branca de destinos e domínios, e revisão a sério de cada conector instalado —quem o publica, que permissões pede, o que muda em cada versão. A cadeia de fornecimento é o terceiro risco da lista e também o mais fácil de infiltrar.
- 5Cortamos a fuga pelo contexto: a recuperação de informação filtra pelas permissões de quem pergunta, a sessão limpa-se entre casos, e segredos e dados pessoais são mascarados antes de saírem para qualquer modelo externo.
- 6Fechamos com rasto forense e resposta: um identificador de caso que atravessa modelo, ferramentas e sistemas, retenção pensada para poder investigar, travão por agente e um procedimento de resposta escrito. E operamo-lo: testes adversários periódicos contra os agentes vivos, não uma auditoria única que envelhece em três meses.
O que muda
O que deixas de perder
A injeção de instruções deixa de ser teórica: testa-se contra os teus agentes vivos, com casos reais do teu negócio, antes de a testar alguém de fora.
Mecanismo
O agente deixa de partilhar a chave-mestra: cada um tem identidade própria, privilégio mínimo e credencial de vida curta, por isso um agente comprometido não abre a casa toda.
Mecanismo
A fuga pelo contexto deixa de depender de ninguém perguntar o que não deve: filtra-se pelas permissões de quem pergunta e limpa-se entre casos, por desenho e não por confiança.
Mecanismo
O que medimos: percentagem de agentes com modelo de ameaça vivo, % de ações sensíveis cobertas por credencial delimitada ou autorização, achados de testes adversários abertos e fechados, e tempo até reconstruir um caso completo de ponta a ponta.
O que medimos
Ficha técnica
- Trabalho que elimina
- descobrir a posteriori que um agente se deixou enganar, que arrastava permissões a mais ou que o seu contexto deixou sair dados —e reconstruir o caso à mão entre registos que não encaixam
- Implementação habitual
- 3–6 semanas
- Entrada
- os agentes que já tens em produção, as suas ferramentas ligadas, as suas credenciais e as fontes de texto que leem
- Saída
- cada agente com modelo de ameaça, identidade própria e privilégio mínimo, ferramentas isoladas e em lista branca, contexto filtrado por permissões e um rasto de ponta a ponta que permite investigar a sério
- Compatível com
- OpenAIAnthropicAzure OpenAILangChainLlamaIndexn8nServidores MCP
- Pode ligar-se a
- Tu gestor de secretos y tu proveedor de identidadTu SIEM o tu stack de observabilidadTu capa de gobierno de agentes, si ya la tienes montada
- O que medimos
- percentagem de agentes com modelo de ameaça vivo% de ações sensíveis com credencial delimitada ou autorizaçãoachados de testes adversários abertos e fechadostempo até reconstruir um caso completo
- Adequado para
- empresas com agentes já em produção que leem texto de terceiros ou atuam sobre sistemas reais, e que têm de responder a um cliente, a uma auditoria ou a um regulador
- Não adequado para
- quem ainda está na prova de conceito sem dados reais nem permissões de escrita: aí o que é preciso é desenhar bem, não blindar
Perguntas frequentes
No adversário. Governar responde a «o que é que o meu agente tem permissão para fazer e quem responde se se enganar»: políticas, aprovações, auditoria, conformidade. É a camada que evita o erro próprio, e está desenvolvida em governar os agentes de IA da tua empresa. Segurança responde a outra pergunta: «o que é que alguém que não trabalha aqui consegue fazer com o meu agente». Aí não há política que valha, porque o atacante não lê as tuas políticas: é preciso separar instrução de dado, isolar ferramentas, delimitar identidades e deixar rasto para investigar. Completam-se e a ordem pouco importa; o que não funciona é ter uma e julgar que se têm as duas.
Para o perímetro, os acessos e os postos, chega, e não lhe tocamos. Onde a estrada acaba é na superfície nova: um agente que executa ações a partir de texto escrito por um terceiro não se parece com nada que uma firewall cubra. A injeção de instruções não é um exploit de rede, é o modelo a obedecer a quem não deve. O isolamento de ferramentas não é segmentar a rede, é decidir o que um processo que improvisa em tempo de execução pode invocar. E rever um conector não é uma análise de vulnerabilidades, é ler que permissões pede e quem o publicou. Essa camada está em terra de ninguém entre o teu fornecedor de segurança e a tua consultora de IA: por isso a montamos nós, e por isso o serviço por trás é segurança completa, clássica e de IA.
Não, e desconfia de quem te diga que sim. Enquanto o modelo processar instruções e dados pelo mesmo canal, haverá sempre texto capaz de o convencer; é por isso que esse risco leva duas edições seguidas no primeiro lugar da lista da OWASP. O que se pode fazer —e que muda mesmo o resultado— é garantir que deixar-se convencer não chegue para causar dano: privilégio mínimo para que a ação perigosa nem esteja disponível, validação da saída antes de tocar num sistema, autorização humana no que custa dinheiro ou toca em pessoas, e rasto para o detetar cedo. A defesa não é um muro: são camadas que impedem que uma falha do modelo se transforme num incidente do negócio.
Montamos no teu negócio?
Localizaste o problema. Nós entregamos a solução e deixamo-la medida.