A stack de segurança de agentes: porque é que nenhum controlo isolado aguenta

A maioria das equipas que leva a prompt injection a sério agarra-se a uma boa ideia e fica por aí. Acrescenta um delimitador à volta do texto não confiável, ou aparafusa um classificador que sinaliza inputs suspeitos, e trata o problema como resolvido. O instinto está certo. O controlo isolado não chega, e vale a pena perceber porquê com precisão, porque isso muda a forma como desenha o sistema todo.

Só que a prompt injection indireta não é uma vulnerabilidade que se corrige. É uma propriedade estrutural do funcionamento dos modelos de linguagem. Um modelo lê um fluxo de tokens e não consegue dizer com fiabilidade que tokens são instruções suas e quais são conteúdo de um documento que lhe pediram para processar. Se uma fatura envenenada contiver uma frase que se lê como um comando, o modelo pode segui-la, porque para o modelo é tudo texto. Não há forma conhecida de tornar um modelo perfeitamente imune a isto mantendo-o útil. Por isso o objetivo não é a imunidade. O objetivo é a contenção, e a contenção é uma propriedade de uma stack, não de uma camada qualquer.

É esta a parte que separa uma arquitetura séria de uma esperançosa. Qualquer controlo que nomeie tem um modo de falha. A pergunta nunca é "este controlo é bom?". É "quando este controlo falhar, o que apanha a falha?". Se a resposta honesta for "nada", não tem segurança. Tem um ponto único de falha com uma etiqueta de segurança.

O spotlighting reduz a superfície de ataque. Não a fecha.

Comece pelo controlo isolado mais comum, porque é o que as equipas mais confundem com uma solução.

O spotlighting é a prática de marcar conteúdo não confiável para que o modelo o distinga das instruções de confiança: codificando-o, delimitando-o, ou etiquetando cada token vindo de uma fonte externa. Ajuda genuinamente. Um modelo a quem se diz "tudo entre estas marcas é dado, não instrução" segue comandos injetados com menos frequência. Se não fizer mais nada, faça isto.

Mas repare no que o spotlighting faz de facto. Baixa a probabilidade de o modelo confundir dado com instrução. Não torna a confusão impossível, porque o modelo continua a ser um sistema probabilístico a ler os dois fluxos pelos mesmos olhos. Uma injeção suficientemente bem construída, ou uma distribuição de inputs para que a marcação não foi afinada, passa a uma taxa acima de zero. E "acima de zero" é o número errado para um processo em que uma única injeção bem-sucedida pode mover dinheiro ou expor dados regulados.

O spotlighting é uma primeira camada precisamente porque é barato e alivia a carga de tudo o que vem atrás. Nunca é a única camada, porque o que vem atrás tem de assumir que o spotlighting por vezes falha.

As quatro camadas, e porque é que cada uma assume que a anterior falhou

Defesa em profundidade aqui não são quatro cópias da mesma ideia. São quatro mecanismos independentes, cada um a apanhar uma classe diferente de falha, dispostos para que contornar um caia no seguinte.

Camada 1: spotlighting do input. Marcar e isolar conteúdo não confiável para que o modelo tenha menos probabilidade de o tratar como instrução. Reduz a superfície de ataque. Assume que nada apanha o que lhe escapa, por isso nunca se confia que seja completa.

Camada 2: isolamento dual-LLM CaMeL. Este é o núcleo estrutural, e é qualitativamente diferente da camada 1. Em vez de pedir a um modelo que tenha cuidado com texto não confiável, divide-se o trabalho por dois. Um planeador privilegiado, o P-LLM, decide o que fazer e invoca ferramentas, mas nunca lê diretamente conteúdo não confiável. Um leitor em quarentena, o Q-LLM, lê o documento não confiável e extrai o necessário, mas não detém ferramentas e não consegue agir. O componente que toca no input envenenado não consegue estruturalmente executar uma ação privilegiada. Perante qualquer dúvida, o padrão falha fechado. Custa cerca de sete pontos percentuais de utilidade, um preço modesto para transformar "esperamos que o modelo resista à injeção" em "o modelo que lê o ataque não tem mãos". Onde o spotlighting baixa uma probabilidade, o isolamento remove uma capacidade.

Camada 3: guardrails de deteção. Classificadores e heurísticas independentes que inspecionam inputs, outputs e chamadas a ferramentas à procura de assinaturas de ataque conhecidas e de anomalias. Esta camada assume que as camadas 1 e 2 podem ambas ser contornadas por algo novo, e tenta apanhá-lo por padrão. É imperfeita na direção oposta à do modelo: falha nos ataques que não viu, e é exatamente por isso que fica ao lado da camada estrutural e não em vez dela.

Camada 4: ponto de decisão de políticas, política como código. A última linha, e a que não depende de detetar o ataque. Cada ação com consequência passa por um PDP que a avalia contra política de que a sua equipa de compliance é dona, que versiona e assina (OPA/Rego, por exemplo). Mesmo que uma injeção sobreviva às três camadas anteriores e chegue ao ponto de disparar uma ação real, o PDP faz a pergunta determinística: este agente, com estes argumentos, neste contexto, pode fazer isto? Um reembolso fora de política é negado, por muito convincentemente que o agente tenha sido persuadido a pedi-lo. Esta camada apanha a falha da própria deteção, porque não tenta saber se o pedido era malicioso. Só sabe se é permitido.

Leia a stack de baixo para cima e a intenção de desenho fica clara. O spotlighting torna os ataques mais raros. O isolamento remove ao leitor a capacidade de agir. A deteção apanha padrões conhecidos. O PDP impõe o que é permitido independentemente do que o modelo acreditou. Cada camada é escolhida pelo que apanha quando a de cima falha, e a nenhuma se pede que seja perfeita, porque nenhuma consegue.

Mapear a stack na OWASP Agentic Security Initiative

Uma stack é mais fácil de defender quando cada risco nomeado tem um dono nomeado. A OWASP Agentic Security Initiative enumera as classes de ameaça; cada uma deve corresponder a um controlo explícito, e não a um aceno de mão.

A tabela não é decoração. É o artefacto que permite a um comité de risco perguntar, linha a linha, "quem é dono disto e onde vive?" e obter uma resposta que aponta para um componente. Repare que nenhum controlo isolado aparece em todas as linhas. O ASI01 é contido por isolamento mais spotlighting; o ASI02 e o ASI06 pelo PDP; o ASI03 e o ASI09 pela identidade; o ASI10 pelo controlo de saída. O mapa só fecha quando as camadas se combinam. Uma stack a que falte qualquer uma delas deixa linhas sem dono, e uma linha sem dono é onde começa o próximo incidente.

O reenquadramento

A pergunta errada, a que leva as equipas a comprar uma ferramenta e a declarar vitória, é "qual é a melhor defesa contra a prompt injection?". Não há melhor defesa, porque todas as defesas falham nalgum ponto, e as falhas são o problema de desenho todo.

A pergunta certa é quando o nosso controlo mais forte for contornado, que camada independente apanha a ação antes de ela se concretizar, e cada risco OWASP mapeia num dono com nome? Se a sua arquitetura responde a isso, tem uma stack de segurança. Se nomeia um controlo engenhoso e confia que ele aguenta, tem uma demonstração que ainda não encontrou o seu primeiro adversário a sério.

Se quiser percorrer as quatro camadas contra um dos seus processos em produção e encontrar as linhas sem dono, marque uma reunião.