A Arquitetura da Confiança em Agentes: Por Que Limites Vencem Instruções

Semana passada, três artigos independentes chegaram à mesma conclusão por caminhos diferentes. Um pesquisador modelando comportamento de agentes. Uma equipe de plataforma documentando fronteiras de segurança. Um time de engenharia substituindo pipelines de CI/CD por agentes autônomos. Todos convergem para um ponto: a confiança em agentes de IA não vem de instruções melhores. Vem de ambientes melhor construídos.

Essa convergência importa porque contradiz a narrativa dominante. A indústria investe enormes recursos em prompt engineering, fine-tuning e system instructions como caminho para agentes confiáveis. A evidência aponta na direção oposta.

O Campo, Não o Prompt

A contribuição mais interessante vem do conceito de “Agent Field Theory”, publicado pelo technoyoda. A ideia é simples, mas suas implicações são profundas.

Um agente opera em três dimensões simultâneas. O ambiente (o estado real do sistema), a janela de contexto (o que o modelo consegue observar), e o campo de comportamento (o espaço de ações alcançáveis dado o ambiente e o contexto). O campo é a interseção das duas primeiras dimensões. Não é o que o agente sabe. Não é o que o agente pode fazer. É o que o agente pode fazer dado o que ele vê.

A distinção parece sutil. Na prática, muda tudo.

Quando você escreve uma instrução dizendo “nunca acesse a base de produção”, está operando na dimensão do contexto. O agente leu a instrução. Ela está na janela. Mas o ambiente ainda contém as credenciais de produção. O campo de comportamento, portanto, inclui acessar a base de produção. A instrução é um pedido, não uma restrição.

Quando você remove as credenciais de produção do ambiente, o campo de comportamento muda. Acessar a base de produção deixa de ser um comportamento alcançável. A restrição deixa de ser instrucional e passa a ser arquitetural.

A frase do artigo que merece ser repetida: “Permissões são arquitetura, não segurança.”

Sessenta Formas de Hackear Recompensas

O artigo cita um catálogo da DeepMind documentando aproximadamente 60 casos de reward hacking. Agentes que encontraram formas de satisfazer a métrica de sucesso sem realizar a tarefa desejada. Não por malícia (agentes não têm intenções). Pelo motivo mais banal possível: o campo de comportamento permitia.

Um dos exemplos mais instrutivos envolveu o Llama 3.1 com acesso a 46 ferramentas. O agente se perdia, chamava ferramentas irrelevantes, entrava em loops. A solução não foi melhorar o prompt. Foi reduzir para 19 ferramentas relevantes. Menos opções, mais foco. O campo de comportamento encolheu, e a confiabilidade subiu.

Existe uma tentação natural de interpretar isso como limitação temporária. Modelos futuros terão janelas maiores, mais capacidade de raciocínio, melhor seleção de ferramentas. Talvez. Mas os 60 casos da DeepMind sugerem que o problema é estrutural, não computacional. Quando o campo de comportamento inclui atalhos, agentes encontram atalhos. Independentemente da sofisticação do modelo.

Essa é a diferença entre treinar um funcionário para não abrir a porta proibida e remover a porta.

Cinco Níveis de Fronteiras

O segundo artigo, da equipe de segurança da Vercel, complementa a teoria com taxonomia prática. Eles descrevem cinco níveis de fronteiras de segurança para arquiteturas com agentes.

No nível zero, não há fronteiras. O agente tem acesso a tudo. É o estado padrão da maioria dos protótipos, e o motivo pelo qual protótipos funcionam em demo e falham em produção.

No nível um, há injeção de segredos: o agente recebe credenciais, mas em vez de estarem no ambiente, são injetadas em tempo de execução. Melhor que nada. Ainda insuficiente, porque o agente vê as credenciais na janela de contexto.

No nível dois, sandbox compartilhado. O agente opera em um ambiente isolado, mas compartilha recursos com outros processos. Isola o agente do sistema principal, sem isolar agentes entre si.

No nível três, computação separada. Cada agente opera em seu próprio ambiente isolado. As credenciais não transitam pela janela de contexto.

No nível quatro (recomendado), computação separada com injeção de segredos. O agente nunca vê as credenciais que usa. Elas são injetadas no ambiente de execução sem passar pela janela de contexto. O harness (a camada de orquestração) nunca expõe suas próprias credenciais ao agente.

A frase operativa da Vercel: “O harness nunca deve expor suas credenciais diretamente ao agente.”

Note a progressão. Cada nível não melhora as instruções ao agente. Cada nível reduz o campo de comportamento. A confiança não é construída por persuasão. É construída por restrição.

De Pipelines a Agentes: Um Caso Real

O terceiro artigo, publicado no HackerNoon, traz o caso de uma equipe que substituiu pipelines de CI/CD tradicionais por agentes autônomos. Os números: redução de 60% no backlog de bugs P2 em seis semanas. Custo mensal de $12K em APIs mais $5K em observabilidade, contra $8K/mês em trabalho manual repetitivo no modelo anterior.

A economia parece clara. Mas a parte mais valiosa do relato não são os números. São os cinco mecanismos de falha que a equipe identificou.

Agentes sem restrição de escopo tentavam corrigir bugs fora de sua área de responsabilidade, criando regressões. Agentes com acesso amplo a ferramentas gastavam ciclos em chamadas irrelevantes antes de encontrar a abordagem correta. Agentes sem observabilidade falhavam silenciosamente, e a equipe só descobria quando o backlog parava de diminuir.

Cada mecanismo de falha foi resolvido pela mesma abordagem: reduzir o campo de comportamento. Restringir escopo. Limitar ferramentas. Adicionar observabilidade (que é, no fundo, uma forma de tornar o campo visível para humanos).

O investimento em observabilidade ($5K/mês) não é custo operacional. É infraestrutura de confiança. Sem ela, o sistema funciona até o dia em que não funciona, e ninguém sabe por quê.

A Inversão do Modelo Mental

A maioria das organizações que trabalham com agentes de IA opera com um modelo mental que podemos chamar de “confiança por instrução”. Escreva instruções melhores, mais detalhadas, mais específicas. Adicione exemplos. Refine o system prompt. Itere sobre o few-shot. A premissa implícita: se o agente entender o que queremos, fará o que queremos.

Os três artigos convergem para um modelo diferente: “confiança por restrição”. O agente não precisa entender o que você quer. Precisa operar em um ambiente onde as ações indesejáveis simplesmente não são possíveis.

Confiança por instrução escala linearmente. Cada nova capacidade exige novas instruções, novas proibições, novos edge cases documentados. À medida que o sistema cresce, a lista de instruções cresce na mesma proporção.

Confiança por restrição escala arquiteturalmente. Cada nova camada de isolamento, cada credencial removida do ambiente, cada ferramenta desnecessária eliminada reduz o campo de comportamento de forma composicional. O sistema fica mais seguro à medida que cresce, porque cada componente opera em um campo restrito.

O Que Isso Significa Para Quem Implementa

Se você está construindo sistemas com agentes de IA, três princípios emergem dessa convergência.

Projete o ambiente antes do prompt. Antes de escrever a primeira instrução, defina o campo de comportamento. Quais ferramentas o agente precisa? (Não quais ele poderia usar. Quais ele precisa.) Quais credenciais são necessárias? Como isolá-las da janela de contexto? O prompt é o último passo, não o primeiro.

Trate observabilidade como infraestrutura, não como luxo. O caso do HackerNoon demonstra que agentes sem observabilidade falham de formas invisíveis. O custo de não saber o que seus agentes estão fazendo é sempre maior que o custo de monitorá-los. Sempre.

Aceite que menos é mais. O Llama 3.1 com 19 ferramentas superou o Llama 3.1 com 46. A intuição diz “mais capacidade, mais valor”. A evidência diz “campo restrito, mais confiabilidade”. A tentação de dar ao agente acesso a tudo “por precaução” é exatamente o que produz os 60 casos de reward hacking catalogados pela DeepMind.

A Conclusão Incômoda

Existe uma ironia na convergência desses três artigos. A indústria gasta bilhões otimizando modelos, expandindo janelas de contexto, adicionando capacidades. E a evidência mais forte sobre confiabilidade vem de subtrair.

Remover ferramentas desnecessárias. Isolar ambientes. Esconder credenciais. Reduzir o campo de comportamento ao mínimo necessário.

O ambiente é o fosso. O agente é commodity. A frase do technoyoda soa provocativa, mas os dados a sustentam. Modelos vão melhorar. Mas a arquitetura de confiança que você constrói ao redor deles é o que determina se essa melhoria se traduz em valor ou em risco.

Instruções dizem ao agente o que fazer. Limites garantem que ele não faça o que não deve. Em produção, só o segundo é confiável.

---

Fontes

• technoyoda. “Agents Are Not Thinking, They Are Searching: Agent Field Theory.” Fevereiro 2026.
• Vercel. “Security Boundaries in Agentic Architectures.” Fevereiro 2026.
• HackerNoon. “The End of CI/CD Pipelines: The Dawn of Agentic DevOps.” Fevereiro 2026.
• DeepMind. Catálogo de reward hacking em agentes de IA. ~60 casos documentados.