Saltar para o conteúdo
Se não funciona, não pagas. 30 dias.
Implementa.

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Ver o serviço
O teu agente de IA não precisa de se enganar para fazer estragos. Basta que alguém de fora lhe fale. · Implementa