Pare de Endurecer o Sandbox. Tire a Credencial de Dentro do Agente.

TV
Thiago Victorino
7 min de leitura
Pare de Endurecer o Sandbox. Tire a Credencial de Dentro do Agente.

Em 29 de março de 2026, K. Hartman, do SANS Institute, publicou um draft do IETF chamado Credential Broker for Agents, o CB4A. Ele faz algo que a conversa sobre segurança de agentes vinha tentando fazer sozinha e falhava: nomeia três modelos arquiteturais para manter um segredo fora do processo do agente, atribui a cada um uma classificação de raio de dano e diz qual deles recomenda. Isso converte preferência de design em rubrica. Dá para levar a um fornecedor e perguntar qual letra ele implementa.

A maior parte do orçamento de segurança de agentes vai para outro lugar. Vai para restringir o que o agente faz com uma credencial que ele já carrega: escopo de ferramenta mais fino, prompts de aprovação mais rígidos, um modelo de guardrail lendo a saída atrás de qualquer coisa parecida com uma chave. Tudo isso parte do princípio de que o segredo está dentro do processo e que o trabalho é policiar a saída dele. A pergunta anterior é se ele precisa estar dentro do processo.

Christian Posta resumiu o modo de falha em uma frase: “Prompt injection, exfiltration, and accidental disclosure sound like three different attacks, but they’re just delivery mechanisms for the same failure mode: the bytes of a sensitive credential leave the agent and still work.” Em português: injeção de prompt, exfiltração e vazamento acidental parecem três ataques distintos, mas são só mecanismos de entrega do mesmo modo de falha, o de os bytes de uma credencial sensível saírem do agente e continuarem funcionando. As últimas palavras carregam o peso. A perda acontece quando os bytes saem e continuam válidos.

Por Que Detecção É a Camada Errada

A razão que desqualifica detecção como controle primário é arquitetural, e Simon Willison a enunciou de forma mais direta que qualquer outro: “LLMs are unable to reliably distinguish the importance of instructions based on where they came from. Everything eventually gets glued together into a sequence of tokens and fed to the model.”

Não existe canal privilegiado. Um system prompt, uma mensagem de usuário, o resultado de uma ferramenta e um parágrafo hostil raspado de uma página web chegam ao modelo como a mesma coisa. Qualquer controle que dependa de o modelo hierarquizar corretamente essas origens está construído sobre uma propriedade que a arquitetura não oferece.

É por isso que fornecedor de guardrail citando taxa de detecção está vendendo o número errado. Willison de novo: “in web application security 95% is very much a failing grade.” Em segurança de aplicação web, 95% é nota de reprovação. Uma taxa de escape de 5% diante de um atacante que pode tentar de novo funciona como filtro, e filtros são precificados pela disposição do adversário em bater na porta mais uma vez.

O enquadramento de Posta entrega os três movimentos arquiteturais que de fato mudam o desfecho: “make the credential expire fast, make it non-transferable, or don’t give the agent a credential at all.” Fazer a credencial expirar rápido, torná-la intransferível, ou simplesmente não dar credencial nenhuma ao agente. Estão ordenados por quanto custam e por quanto compram. O terceiro é o interessante, e o CB4A é o que acontece quando alguém o escreve como protocolo em vez de slogan.

Os Três Modelos do CB4A, Ordenados por Raio de Dano

A contribuição do draft está em recusar tratar os modelos como opções equivalentes. Cada um carrega uma classificação explícita de raio de dano.

Modelo A, gateway de proxy. O agente nunca vê a credencial. Ele emite uma requisição ao broker, e o broker anexa o segredo na fronteira de rede antes de a chamada chegar ao provedor. Raio de dano: “minimal”. Os bytes nunca entram no processo do agente, então nenhuma manipulação de contexto extrai o que não está lá. O que uma injeção ainda consegue fazer é provocar uma requisição. Isso é um problema de disponibilidade e abuso, governado por outros controles.

Modelo B, emissão de token de vida curta. O broker entrega ao agente um token escopado para a operação, com tempo de vida curto. Raio de dano: “bounded by the TTL”, limitado pelo TTL. A credencial é real e está no processo, então um vazamento é um vazamento de verdade. Vazamento com validade anexada. O draft nomeia este como seu “recommended primary model”, o modelo primário recomendado, e vale parar aí um instante: a recomendação da via de padronização não é o isolamento mais forte. O draft não dá a razão da escolha, então leia como uma aposta em adotabilidade.

Modelo C, empacotamento de credencial com revogação agendada. O agente recebe a credencial real, empacotada, com revogação agendada depois do fato. O draft o chama de “weakest model”, o modelo mais fraco, e classifica o raio de dano como “full until revoked”, total até a revogação. Se a janela entre comprometimento e revogação é onde mora a sua proteção, você voltou a depender de detecção, uma camada abaixo.

Lido contra os três movimentos de Posta, o mapeamento fica limpo. O Modelo C é aproximadamente “expirar rápido” com a expiração colocada do lado errado do comprometimento. O Modelo B é expirar rápido, feito direito. O Modelo A é não dar credencial nenhuma ao agente.

A Ameaça Que o Broker Cria

O padrão traz risco novo, e o crédito é do draft por dizer isso primeiro. Comprometimento do broker, TM-1 no modelo de ameaças, é classificado como “CRITICAL, the only threat at that severity”, crítico, a única ameaça naquela severidade. Todas as outras entradas ficam abaixo.

Esse é o trade honesto. Consolidar credenciais atrás de um broker significa trocar muitos alvos de valor médio por um alvo de valor alto. O argumento para fazer mesmo assim é o mesmo que colocou seus segredos em um cofre em vez de espalhados pelo .env de cada serviço: um componente único, que dá para monitorar, corrigir, rotacionar e auditar, vence uma superfície difusa sem dono. O broker, porém, herda a postura de segurança que o seu pior agente tinha, e herda para todos de uma vez.

Uma observação para quem for citar o draft em revisão de arquitetura: o texto do CB4A diverge de si mesmo sobre quantas ameaças enumera. O resumo e o apêndice divergem, dez em um lugar e onze no outro. É um draft. Cite a severidade do TM-1, que é inequívoca, em vez de um total.

Quanto Isso Custa

Um salto de relay é um salto. A implementação de referência descrita pela WorkOS roteia por cabeçalhos (X-Relay-URL, X-Relay-User, X-Relay-Organization, X-Relay-Provider), encaminha corpos “byte-for-byte up to 5 MB”, byte a byte até 5 MB, fixa o timeout de upstream em 30 segundos e devolve um 402 relay_authorization_required quando o chamador não tem direito à credencial. Esse último item importa mais do que parece: um contrato de erro explícito para “você não tem permissão de usar este segredo” é o que permite ao agente falhar de forma limpa em vez de improvisar.

Sobre latência, a WorkOS afirma diretamente que “we have not published latency numbers for the relay hop”, que não publicou números de latência do salto de relay. Então ninguém, nós inclusive, deveria lhe dizer que o padrão é neutro em desempenho. Ele adiciona um salto de rede no caminho de toda chamada ao provedor, e o teto de 5 MB de corpo mais o timeout de 30 segundos são restrições reais sobre o que consegue passar por ali. Orce os dois.

Mais uma ressalva sobre a cifra que o próprio texto da WorkOS sinaliza. O incidente TeamPCP de março de 2026 aparece citado ao lado desse padrão, com a cifra de mais de 300 GB de credenciais comprimidas afetando cerca de 500 mil identidades corporativas. Essa cifra tem origem na reivindicação de extorsão do próprio agente da ameaça, e não em perícia forense. A mesma divulgação registra que o ator usou um ladrão de credenciais de host genérico e que aquilo não foi um ataque às chaves de provedor armazenadas do LiteLLM. Escrevemos sobre um comprometimento real de cadeia de suprimentos em middleware de IA em outro texto, e os dois casos devem permanecer separados. Justificar um controle com número de extorsão não verificado entrega uma vitória fácil ao cético da sala.

Faça Isto Agora

Escolha um agente que hoje carrega uma credencial de provedor. Não a frota inteira, um agente.

Responda, por escrito, qual modelo CB4A ele roda. Se a credencial fica no processo durante toda a sessão, é Modelo C por omissão, tenha alguém escolhido isso ou não. Depois descubra o que aquela credencial consegue fazer no provedor: o escopo, não a intenção. Nas auditorias que fazemos, o token quase sempre é mais amplo que o trabalho do agente.

Em seguida, leve a pergunta da letra a todo fornecedor de agente do seu stack, em linguagem de compras: qual modelo CB4A vocês implementam, A, B ou C, e qual o raio de dano declarado? Fornecedor que responde com taxa de detecção em vez de uma letra já respondeu C.

O que mudou foi a taxonomia existir. Antes dela, “mantenha segredos fora do agente” era opinião que um arquiteto defendia e outro contestava. Agora é um draft com modelos nomeados, severidades classificadas e uma recomendação citável em revisão de segurança. Isso é um padrão sobre o que um agente tem permissão de ser, e pertence à sua arquitetura de contenção, ao lado de computação, dados, conhecimento e identidade.


Fontes

A Victorino ajuda times de engenharia a auditar onde as credenciais dos agentes realmente vivem e a movê-las para trás de uma fronteira de broker: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa