A camada de contexto que ninguém construiu

Quase todas as conversas sobre agentes são conversas sobre modelos. Qual raciocina melhor, qual é mais barato, em qual normalizar. É o sítio natural para onde olhar, porque o modelo é a parte que parece nova.

Só que o modelo raramente é o que determina se um agente é útil dentro da sua empresa. Um agente vale o contexto que consegue alcançar, e o seu contexto não vive no modelo. Vive espalhado pelas suas pessoas, processos e sistemas: o CRM, o core, o repositório documental, a fila de tickets, a pessoa que conhece a única exceção que importa. A maioria das organizações nunca construiu a camada que permite a um agente alcançar esse contexto em segurança. Por isso o agente ou não vê o suficiente para ser útil, ou é ligado com credenciais amplas e permanentes que nenhum comité de segurança aprovaria.

Essa camada em falta é a razão silenciosa por que a maioria dos projetos estagna. Não é um problema de modelo. É um problema de interoperabilidade e de identidade, e é suficientemente pouco glamoroso para quase ninguém lhe reservar orçamento antes de lá bater.

A camada não é canalização de integração

A tentação é entregar isto a uma equipa de integração e chamar-lhe canalização. Resista, porque cada escolha de desenho nesta camada é uma escolha de segurança, e tratá-la como canalização é a forma de os buracos de segurança serem construídos por pessoas a quem nunca foi pedido que pensassem neles.

A camada de contexto tem três partes, e cada uma é onde uma arquitetura séria e uma arquitetura esperançosa divergem.

Parte um: capacidades tipadas, não um monte de chaves de API

Um agente precisa de ler e escrever nos seus sistemas de registo. A forma preguiçosa de conceder isso é um molho de chaves de API e acesso amplo. A forma correta são capacidades explícitas e tipadas.

Pense em cada capacidade como uma porta estreita e com nome: read_dossier, request_document, post_decision_for_review. Ao agente são concedidas as portas específicas de que precisa para uma tarefa específica, e mais nada. Cada porta é registada.

A diferença não é cosmética. Muda a frase que o seu comité de segurança tem de avaliar. "O agente pode tocar nos nossos sistemas" não é auditável, e ninguém devia assinar isso. "O agente pode executar estas sete ações com nome, cada uma registada" é um controlo que um comité consegue aprovar. As capacidades tipadas são o que transforma uma integração em aberto numa superfície delimitada e revisível.

Parte dois: identidade não humana, de curta duração e privilégio mínimo

Um agente não é uma pessoa, e nunca pode usar as credenciais de uma pessoa.

Esta é a forma mais comum de os projetos falharem no comité de segurança, porque o caminho rápido, correr o agente sob o token pessoal de quem o fez com acesso permanente a produção, é exatamente a constatação que trava o projeto. Esse token é uma chave-mestra. Não é delimitado, não expira depressa, e não distingue as ações do agente das da pessoa.

Numa arquitetura correta, cada agente corre sob a sua identidade não humana, com credenciais de curta duração e privilégio mínimo e uma allow-list de saída explícita. Vale a pena dizer a consequência com clareza: uma credencial de agente roubada não vale quase nada. Não há segredo estático para roubar, e a identidade só consegue fazer as poucas coisas para que foi delimitada, para os poucos destinos que pode alcançar. Um destes desenhos passa na homologação. O outro é a constatação que acaba com o projeto.

A identidade é também o que dá sentido ao trilho de auditoria. Quando cada ação leva a identidade própria do agente e as suas capacidades delimitadas, "quem fez isto?" tem resposta precisa, e o registo que os seus auditores inspecionam reconstrói mesmo o que aconteceu.

Parte três: a fronteira de contaminação, onde dados não confiáveis não se tornam privilégio

Esta é a parte que separa uma arquitetura séria de uma esperançosa, e merece cuidado, porque é a forma mais comum de os agentes serem comprometidos em produção.

Um agente lê conteúdo que não escreveu: um email de cliente, um contrato digitalizado, um PDF de um terceiro. Esse conteúdo não é de confiança. Se um documento envenenado contiver texto que se lê como uma instrução, e o agente o tratar como tal, o documento acabou de sequestrar um agente com acesso aos seus sistemas centrais. É a prompt injection indireta, e nenhum prompt, filtro ou definição de configuração a trava com fiabilidade.

A resposta estrutural é uma fronteira de contaminação: dados não confiáveis nunca se tornam privilégio executável. Na prática aplica-se separando os papéis do agente, no padrão conhecido como CaMeL, um desenho dual-LLM. Um planeador privilegiado decide o que fazer e invoca as ferramentas tipadas, mas nunca lê diretamente conteúdo não confiável em bruto. Um leitor em quarentena lê o conteúdo não confiável, mas não consegue invocar ferramentas nem agir. Devolve uma referência, não uma instrução. Perante qualquer ambiguidade, o sistema falha fechado.

Há um custo honesto. Separar os papéis troca uns pontos de utilidade. É esse o negócio: um preço modesto em exatidão por uma garantia estrutural de que um documento não consegue tomar o controlo de um agente ligado aos seus sistemas centrais. Em trabalho regulado, a decisão não é difícil.

Nenhuma camada isolada é considerada suficiente. A fronteira de contaminação vive dentro de uma defesa em profundidade: spotlighting para encolher a superfície de ataque, isolamento CaMeL, guardrails de deteção, e um ponto de decisão de políticas acima de tudo. O spotlighting reduz a superfície de ataque. Não a elimina, e é exatamente por isso que nunca é a única camada.

Porque é que vale a pena construir esta camada nos seus processos reais

Não pode comprar esta camada de prateleira, porque a sua forma vem dos seus sistemas, das suas identidades e das suas fronteiras de dados. Tem de ser construída sobre os seus processos reais, no terreno, no trabalho a sério, e não sobre um diagrama de referência.

É também por isso que é a camada que decide, em silêncio, tudo o que vem a seguir. O melhor modelo do mundo, encaminhado pelo gateway mais portável, governado pela escada de autonomia mais rigorosa, é inútil se o agente não conseguir alcançar em segurança o contexto de que precisa para atuar. Ao contrário, quando a camada de contexto existe, os agentes alcançam apenas o que lhes é permitido, atuam sob identidades próprias de privilégio mínimo, e nunca podem ser enganados a tratar dados não confiáveis como instrução, com um trilho completo que os seus auditores conseguem inspecionar. Todo o resto numa arquitetura agêntica assume que esta camada já existe.

Por isso, o reenquadramento não é "que modelo devem usar os nossos agentes?". É para cada sistema que os nossos agentes têm de alcançar, qual é a capacidade tipada, que identidade detém o agente, e onde está a fronteira entre o conteúdo que lê e as ações que pode executar? Se não consegue responder a isso sistema a sistema, a escolha do modelo ainda não importa. A camada por baixo dele não foi construída.

Se quiser mapear a camada de contexto para um processo crítico, marque uma reunião.