Identidade do chamador no tráfego de agentes e ferramentas

A identidade do chamador é a origem da chamada, e não a credencial que a transportou. Quando dois times compartilham o mesmo agente, o gateway reconhece a credencial e não reconhece a pessoa: cota, rastro e autorização viram uma coisa só. O NIST publicou a SP 800-63-4, em julho de 2025, para separar autenticar uma credencial de afirmar a identidade.

As três fronteiras que a empresa acredita ter somem juntas. A fatura chega depois.

O que exatamente se perde quando a credencial é compartilhada

Um gateway que só vê a credencial perde três coisas ao mesmo tempo, e a empresa trata cada uma como um problema separado. Perde a cota, porque o teto passa a valer para o grupo inteiro. Perde o rastro, porque o rastro registra a chave e não o time. E perde a autorização, porque o escopo concedido ao vizinho vale para quem estiver por perto.

Os três vêm da mesma causa. A credencial é um objeto compartilhado, e objeto compartilhado não tem dono. O time de engenharia abre uma chave para um agente de triagem, o time de suporte descobre que ela funciona, o time de receita pluga o mesmo agente no próprio fluxo. Ninguém fez nada de errado e ninguém decidiu nada. A fronteira simplesmente sumiu, e o primeiro lugar onde isso dói não é a fatura.

A fatura é um documento agregado. Ela não é falsa, ela é insuficiente para responder à pergunta que o financeiro faz. Quem gastou. Em quê. Com autorização de quem. Uma fatura que soma quatro times em uma linha responde "a empresa gastou", e essa resposta já era conhecida antes de a fatura chegar.

Por que o teto por chave não é um teto por unidade de negócio

O orçamento de IA por equipe parte de uma premissa explícita: a chave é o time. O teto por chave, o alerta em 80% e o rastro por chamada funcionam quando essa premissa é verdadeira. O problema é que ela deixa de ser verdadeira no momento em que o segundo time usa o mesmo agente, e nada no sistema avisa que isso aconteceu.

A diferença é de modelagem, e não de configuração. Um teto por chave responde à pergunta "quanto esta credencial consumiu". Um teto por unidade de negócio responde "quanto o time de receita consumiu, em qual modelo, e quem responde por isso". São perguntas diferentes, e a segunda não é obtida dividindo a primeira.

A quinta linha é a que decide o valor da modelagem. Um teto por chave não falha de forma visível quando a premissa quebra. Ele continua funcionando exatamente como projetado, somando o que enxerga, e o que ele não enxerga é a diferença entre o consumo real da área e o consumo que aparece na conta dela. O erro não produz alarme, produz número.

Identidade do chamador: a cadeia completa, e onde ela se rompe

Identidade do chamador é o atributo que responde quem originou a chamada, e ela precisa sobreviver do usuário final até o servidor de ferramenta. A cadeia completa tem cinco elos: o usuário final, o agente, a credencial que o agente usa, o gateway por onde a chamada passa e o servidor de ferramenta que a executa. A identidade morre quando um desses elos carrega apenas a credencial e não a origem. O primeiro elo é o que não tem mecanismo por padrão, e não um salto garantido. A identidade do usuário só entra na cadeia se o host do agente a autenticou e a repassou adiante. A chave estática não a carrega, e é por isso que a ruptura da entrada é a mais comum.

Há três pontos de ruptura, e nenhum deles é exótico. O primeiro é a entrada: o agente autentica com uma chave estática e o humano por trás dele nunca chega ao gateway. O segundo é a delegação: um agente chama outro agente, ou um subagente, ou um servidor de ferramenta que dispara uma chamada nova, e a origem não é propagada na segunda perna. O que se perde ali não é só a propagação, e sim a re-autorização. Um sujeito que chega à segunda perna sem escopo reduzido carrega a identidade sem reduzir a autoridade, e esse é um modo de falha pior do que simplesmente perder a origem, porque o rastro aponta para a pessoa certa com a permissão errada. O terceiro é a saída: a ferramenta recebe a chamada sem saber em nome de quem ela está sendo executada, então aplica a permissão da credencial.

Legenda: a identidade do chamador precisa sobreviver da origem até a ferramenta; três pontos de ruptura colapsam cota, rastro e permissão.

O segundo ponto merece atenção porque é o menos visível. A camada de controle do tráfego de ferramentas estabeleceu o gateway como ponto único de inspeção e nomeou autenticação e auditoria como funções dele. Reconhecer a credencial, porém, não é reconhecer o chamador, e a diferença aparece justamente na delegação. Um fluxo que chama três ferramentas em sequência registra três linhas de log com o mesmo identificador de credencial. A pergunta que a auditoria faz, qual usuário acionou essa cadeia, não tem resposta em nenhuma das três.

O log mostra a chave. Não mostra a pessoa.

O custo e o acesso quebram na mesma causa

Chamar de problema de custo é subestimar o defeito. A credencial compartilhada é um vetor de autorização, e o over-permission que ela produz é estrutural, não acidental. Um time que só precisava ler passa a poder escrever porque a credencial do vizinho permite, e ninguém concedeu essa permissão por decisão, ela foi herdada pelo compartilhamento.

O modo de falha é sempre o mesmo. O agente pertence a uma área, a ferramenta pertence a outra, e o escopo é o mais amplo dos dois porque ninguém declarou o menor. O time de suporte ganha escrita no sistema financeiro porque o agente de triagem foi autorizado a registrar nota e a chave é a mesma. O primeiro indício não é o estouro do teto: é um registro alterado que ninguém reconhece como próprio.

Uma conta responde por duas áreas.

A especificação de autorização do Model Context Protocol trata desse ponto de forma direta. Ela exige que o cliente inclua o parâmetro de recurso na requisição e que o servidor valide que o token foi emitido especificamente para ele, rejeitando tokens que não o nomeiem como destinatário. A vinculação por audiência só prende quando o servidor de autorização honra esse parâmetro, então é uma pergunta a fazer ao fornecedor, não um padrão que se assume. A mesma seção proíbe que o servidor repasse para a API a jusante o token que recebeu do cliente, que é o token passthrough. O motivo é o confused deputy, um padrão antigo de falha de autorização: um intermediário com credencial ampla age por quem não tem, e o sistema a jusante confia nele. O passthrough é uma das rotas para esse estado.

O gateway de LLM é a única posição da arquitetura que vê os dois lados desse fluxo. É por isso que a correção fica ali e não em cada aplicação.

O que o gateway precisa carregar para a identidade sobreviver

Um gateway resolve o problema quando carrega sete coisas, e nenhuma delas é opcional. A lista abaixo não é uma configuração, é o contrato mínimo entre a identidade que o sistema afirma ter e a identidade que ele consegue provar por chamada.

1. Sujeito de origem. O identificador do usuário final viaja na chamada, e a sessão do navegador não basta. Sem ele, o gateway autentica a máquina e ignora a pessoa.
2. Contexto de autorização por chamada. A decisão de permitir é recalculada a cada execução, com escopo declarado por ferramenta, em vez de concedida uma vez na criação da credencial.
3. Atribuição por unidade de negócio. Cota, política e rastro apontam para a área responsável, e a área é um atributo de primeira classe, não um rótulo aplicado depois.
4. Propagação na delegação. Quando um agente chama outro, ou um subagente, ou um servidor de ferramenta que dispara chamada nova, a identidade de origem sobrevive à segunda perna.
5. Rastro completo por chamada. Cada execução registra sujeito, área, chave, ferramenta, modelo, tokens e custo, e a auditoria da chamada de LLM consegue reconstruir a cadeia inteira a partir de qualquer ponto dela.
6. Menor privilégio efetivo. O escopo da chamada é a interseção entre o que a área pode e o que a ferramenta exige, e o excesso é negado por padrão em vez de tolerado.
7. Teto na dimensão certa. O limite de gasto por chave de API continua válido como proteção de caixa, e o teto que responde à área é um segundo controle, aplicado sobre a mesma chamada.

A ordem importa pouco. A ausência de qualquer um deles, porém, reabre o defeito. As sete não estão no mesmo estágio de maturidade: o sujeito de origem na chamada é entrega corrente, e a propagação na delegação ainda é rara no ferramental de produção. Do lado do fornecedor, a pergunta prática é qual dessas sete propriedades o gateway já entrega hoje, e é no gateway de LLM na empresa que a lista é conferida.

Quatro arranjos de compartilhamento: o que se perde em cada um

A tabela abaixo cruza quatro arranjos reais de compartilhamento com as três fronteiras, e mostra onde cada uma cai. A coluna da cota colapsa primeiro em todos eles, e é por isso que o problema é diagnosticado como custo quando a causa é identidade.

A primeira linha é a configuração que funciona, e ela não é a mais comum. A segunda é a que aparece com mais frequência nas empresas que cresceram rápido, porque compartilhar o agente é a decisão barata e ninguém mede o custo dela no dia em que é tomada.

A quarta linha explica um sintoma específico: um gasto em produção que ninguém consegue reproduzir em teste, porque o teste usa a chave de produção e o consumo de ambos cai na mesma linha. Quando o time finalmente separa as chaves, o gasto de produção parece cair, e na verdade ele só ficou visível.

Teste e produção não se separam sozinhos.

Onde isso dói primeiro, e por que não é a fatura do mês

O primeiro lugar onde a ausência de identidade do chamador causa dano real não é o fechamento mensal. É a renovação do contrato de software, quando alguém precisa justificar o que foi comprado e não consegue atribuir consumo a área nenhuma. A fatura do mês é um problema de caixa. Caixa se resolve. A renovação sem atribuição é um problema de crédito interno, e esse não se resolve com pagamento.

Existe ainda a leitura regulatória, e ela tem prazo. O NIST publicou a revisão final das Digital Identity Guidelines em julho de 2025, substituindo a SP 800-63-3, e a série trata justamente da diferença entre autenticar uma credencial e afirmar a identidade de um sujeito a um serviço.

Nenhuma delas obriga uma empresa privada a nada. O NIST não regula o comprador, regula o vocabulário. O padrão que eu vejo sendo cobrado em contrato, em questionário de fornecedor e em auditoria interna pergunta quem, nunca só se. A leitura é esta, e não um dado medido. A SP 800-63C, o volume de federação, exige que a asserção seja restrita a um destinatário específico a partir do FAL2, que é a mesma propriedade que o teste abaixo procura no gateway. A empresa que só consegue responder "a credencial" fica com uma lacuna que ninguém assina embaixo.

O argumento contrário, na versão mais forte

A objeção séria não é que a identidade do chamador seja irrelevante. É que gerenciar identidade por chamada custa caro e adiciona um ponto de falha no caminho crítico. O gateway passa a depender de um serviço de identidade, o serviço cai, o tráfego para. Simplicidade operacional tem valor, e a chave única é simples.

A resposta é que a objeção descreve o custo de fazer e ignora o custo de não fazer, que já está sendo pago. Cada incidente que exige reconstruir quem alterou um registro no sistema financeiro consome dias de engenharia, e um punhado deles no ano já passa de uma semana de trabalho parado. Cada renovação sem atribuição consome uma renegociação. O custo não é criado pela identidade do chamador, ele passa a ser visível.

E há uma razão de arquitetura para o serviço de identidade ser menos frágil do que a objeção supõe. A especificação do MCP recomenda o token de curta duração, e torna obrigatórios o parâmetro de recurso do lado do cliente e a validação de audiência do lado do servidor. Ela também obriga a rotação do refresh token para clientes públicos, que é o que fecha a janela de um vazamento. O gateway que respeita esse contrato depende de tokens que expiram e não de sessões longas, o que reduz o impacto de um vazamento em vez de ampliá-lo.

Como testar se o gateway reconhece o chamador antes de assinar

O teste cabe em uma tarde. Ele não exige tráfego de produção nem um agente sofisticado, e a resposta que importa aparece na primeira pergunta já na primeira hora.

1. Registre duas chaves distintas e atribua cada uma a uma área diferente, com o mesmo agente rodando nas duas.
2. Dispare a mesma cadeia de chamadas de ferramenta pelas duas chaves, incluindo um fluxo com duas pernas em que um agente chama uma ferramenta que dispara outra chamada.
3. Leia o rastro como o financeiro leria. A chamada de cada área aparece separada, com o identificador do usuário de origem e o custo por modelo?
4. Verifique a segunda perna da delegação. A origem sobrevive quando a chamada é repassada, ou o log da segunda ferramenta só mostra a credencial?
5. Tente negar com a chave do vizinho. Dê a uma área uma chave com o escopo mais amplo do vizinho e dispare, como usuário dessa área, uma ferramenta que o escopo dela não cobre. A recusa tem que vir do chamador, não da chave. Se o pedido passa porque a credencial autoriza, o gateway aplica política na chave e ainda não conhece o chamador.

A quinta pergunta separa a aplicação de política no chamador da aplicação de política na credencial. Um sistema que nega apenas o que a chave não permite está registrando tráfego com escopo, e não governando quem chamou. Vale dizer o que o teste não prova sozinho: uma recusa isolada é compatível com um gateway que só olha a chave, e é por isso que a variação acima inverte a pergunta em vez de repeti-la.

FAQ

O que é identidade do chamador em um gateway de LLM? É o conjunto de atributos que responde quem originou uma chamada, e a credencial que a transportou é só um deles. Ela precisa sobreviver do usuário final até o servidor de ferramenta, e cobre pelo menos o sujeito de origem, a unidade de negócio responsável e o contexto de autorização daquela execução específica.

Por que um teto por chave não resolve o orçamento por unidade de negócio? Porque o teto por chave mede o que a credencial consumiu, e a credencial deixa de representar uma área quando dois times passam a usar o mesmo agente. O número continua correto. E inútil. O teto por unidade de negócio exige que a área seja um atributo da chamada, não uma inferência feita a partir da chave.

Compartilhar a credencial do agente entre times é sempre um erro? Não é sempre, mas é sempre uma decisão que precisa ser registrada. Em ambiente de teste, com dado sintético e teto baixo, o compartilhamento é aceitável e econômico. Em produção, com dado de cliente e ferramenta transacional, ele mistura cota, acesso e rastro em uma única linha que ninguém consegue separar depois.

Como a identidade sobrevive quando um agente chama outro agente? Ela sobrevive quando a identidade de origem é propagada como parte da chamada delegada, e não substituída pela credencial do segundo agente. Na prática, isso significa que o gateway precisa emitir um contexto de autorização para a execução encadeada que preserve o sujeito original e restrinja o escopo à ferramenta de destino.

Identidade do chamador é o mesmo que autenticação da chave de API? Não. A autenticação da chave responde se quem chamou pode chamar. A identidade do chamador responde quem é, em nome de qual área e com que autorização. Um gateway pode autenticar todas as chamadas com sucesso e ainda assim não saber responder quem alterou um registro específico.

Quanto disso o Nexforce Router já cobre? O Router governa o orçamento por chave, por agente e por projeto, com consumo em tempo real de tokens por sessão e por agente, regras de roteamento por chave e o rastro completo de cada chamada. É a camada onde cota, política e rastro vivem no mesmo ponto de controle, e é por isso que a modelagem por unidade de negócio começa ali. Quem está escolhendo a ferramenta pode partir dos critérios de avaliação de um gateway de LLM e aplicar as perguntas do teste acima a cada candidato.

Referências e Leitura Complementar

• MCP gateway: a camada de controle para o tráfego de ferramentas dos agentes de IA
• Orçamento de IA por equipe: governança com rastreabilidade
• Rastreio da chamada de LLM: como auditar requisição e token
• Como avaliar e escolher um gateway de LLM
• Model Context Protocol, especificação de autorização e boas práticas de segurança: modelcontextprotocol.io/specification/2026-07-28/basic/authorization
• NIST, Digital Identity Guidelines, SP 800-63-4, publicada em julho de 2025: pages.nist.gov/800-63-4

Quem responde pela chamada é uma decisão de arquitetura

A identidade do chamador não é um recurso de observabilidade que se liga depois. É uma decisão sobre quem responde pelo que a IA fez, tomada no momento em que o primeiro agente passa a ser compartilhado, e silenciosamente revertida cada vez que uma chave é copiada para o time ao lado.

O teste custa uma tarde. A resposta é binária. Ou o gateway consegue nomear a área e o usuário de origem por chamada, ou a empresa está operando com três fronteiras que existem apenas no organograma. A cota, o acesso e o rastro caem juntos, e voltam juntos quando a identidade volta a sobreviver até o servidor de ferramenta.

É nessa camada que o Nexforce Router opera. Uma API única, uma chave, 300 ou mais modelos, com orçamento por chave, por agente e por projeto, consumo em tempo real de tokens por sessão e por agente, regras de roteamento por chave, guardrails de segurança e o rastro completo de cada chamada em observabilidade centralizada. A cota, a política e o rastro ficam no mesmo ponto de controle, no lugar onde a chamada já passa.