O agente errou: qual é o tamanho do estrago permitido?

A Docker reuniu os riscos de agentes autônomos em cinco grupos: injeção de instruções, uso indevido de ferramentas, autonomia excessiva, exposição de credenciais e exfiltração de dados.[1] O ponto central da análise é que instruir o modelo a ignorar ataques não constitui uma defesa confiável; é preciso limitar o alcance de um agente comprometido.[1]

A pergunta útil para engenharia não é apenas se o agente obedecerá ao usuário. É o que ele poderá fazer quando interpretar algo errado.

O que muda para quem desenvolve

Segundo a reportagem, páginas, documentos, comentários de código e descrições de ferramentas podem carregar instruções que tentam redirecionar o agente.[1] Isso coloca uma fronteira de confiança dentro do próprio fluxo de desenvolvimento: o material necessário para resolver a tarefa também pode tentar mudar a tarefa.

Minha leitura é que o projeto deve separar três decisões: qual conteúdo pode ser consultado, quais operações podem ser propostas e quais operações podem efetivamente acontecer. Aprovar uma integração não deveria significar entregar ao modelo toda a autoridade de quem a configurou.

A oferta descrita combina microVMs descartáveis, controles de arquivos e rede e governança de ferramentas e credenciais.[1] O valor arquitetural a avaliar é a fronteira imposta, não o nome comercial do isolamento.

Como aplicar

Comece por uma tarefa estreita, como corrigir um teste em um repositório de demonstração. Defina previamente os diretórios graváveis, os destinos de rede necessários e as operações proibidas. Use credenciais exclusivas desse ambiente, sem acesso a produção.

Depois, acrescente um documento de teste que peça ao agente para ler um arquivo fora do escopo ou enviar conteúdo a um destino não permitido. Esse é um experimento proposto, não um resultado já medido. O critério de aprovação deve ser a operação bloqueada pela infraestrutura, mesmo que o modelo tente executá-la.

Registre separadamente a ação solicitada, a ação tentada e a decisão do controle. Para publicação de código ou mudança de configuração, prefira uma autorização específica vinculada ao efeito esperado.

Cuidados e limites

A discussão citada pela InfoQ ressalta que contêineres não resolvem sozinhos a concessão excessiva de autoridade e que executar código de terceiros em ambiente multiusuário pode exigir uma fronteira mais forte que um kernel compartilhado.[1]

Isolamento também não deve virar desculpa para deixar todas as ferramentas disponíveis. Minha recomendação é reduzir o conjunto por tarefa e manter a saída de dados tão explícita quanto a entrada. Um ambiente descartável com credenciais poderosas continua sendo uma decisão de confiança ruim. O objetivo não é provar que o modelo nunca errará. É tornar o erro suportável.

Fonte

[1] Fonte: InfoQ