No artigo anterior sobre autonomia e autoridade, explorei a diferença entre permitir que um agente escolha os próximos passos de uma tarefa e conceder a ele autoridade para produzir efeitos externos. Usei o Controlled Autonomy Lab como exemplo: o modelo podia decidir quais evidências consultar, mas as ferramentas disponíveis e os limites da execução continuavam definidos pela aplicação.
O texto terminou com uma questão que merece ser examinada separadamente: se uma ação depende de autorização, qual identidade está efetivamente exercendo essa autoridade?
A resposta parece simples quando existe apenas um usuário autenticado, uma aplicação e uma API. A situação muda quando a solicitação passa por um orquestrador, é delegada a outro agente por A2A e termina numa ferramenta exposta por MCP.
Cada componente pode estar corretamente autenticado e ainda assim, a arquitetura permitir uma operação que o usuário não estava autorizado a realizar. Isso acontece quando a identidade de quem solicitou o trabalho, a identidade do serviço que executa a chamada e as permissões efetivamente concedidas deixam de ser tratadas como coisas diferentes.
Uma solicitação, várias identidades#
Imagine um assistente corporativo recebendo de um usuário autenticado a seguinte solicitação:
“Consulte os pagamentos pendentes da minha empresa, verifique quais vencem nesta semana e prepare os que precisam de aprovação.”
O assistente principal identifica a intenção e delega a análise a um especialista financeiro remoto por A2A. Esse especialista utiliza um servidor MCP para consultar os pagamentos e outro serviço para preparar as solicitações de aprovação.
A topologia parece relativamente simples, mas existem identidades distintas. O usuário possui uma identidade corporativa, associada às empresas, contas e operações que pode acessar. O assistente principal executa sob uma identidade de workload, usada para autenticar seu serviço nas integrações. O especialista remoto possui sua própria identidade de workload. Já o MCP Server precisa identificar o principal autorizado para a operação solicitada e aplicar os controles correspondentes antes de acessar os sistemas financeiros.
Ampliar ↗A identidade da workload prova qual componente está chamando o serviço. Ela não demonstra, por si só, que aquele componente possui autorização para agir em nome de determinado usuário.
Essa distinção fica importante porque autenticação entre serviços e autorização sobre dados de negócio podem funcionar em camadas diferentes. Um token obtido com Client Credentials, por exemplo, normalmente representa uma aplicação atuando em nome próprio. Ele não passa automaticamente a representar o usuário que iniciou a conversa.
O risco aparece quando um token de serviço com permissões amplas acaba funcionando como substituto dessas verificações. Se o especialista utiliza uma credencial capaz de alterar pagamentos de qualquer empresa, mas a solicitação legítima envolve apenas uma delas, existe uma diferença entre o alcance técnico da credencial e a autoridade da operação.
Se o isolamento entre empresas depender apenas de um parâmetro company_id gerado pelo LLM, a fronteira de segurança estará particularmente frágil. O modelo pode selecionar a empresa errada, interpretar incorretamente o contexto ou receber instruções maliciosas em uma fonte consultada. O servidor precisa associar o recurso solicitado ao principal autenticado e autorizado. O identificador enviado como argumento da ferramenta é um dado a validar, não prova de permissão.
Delegar uma tarefa não deveria transferir todas as permissões#
A2A oferece um mecanismo para agentes descobrirem capacidades e trocarem mensagens, tarefas e resultados. Sua especificação prevê requisitos de autenticação anunciados no Agent Card, com esquemas que podem utilizar OAuth, OpenID Connect e outros mecanismos de segurança.
Isso resolve parte da comunicação. O agente principal descobre como se autenticar perante o agente remoto, e o servidor A2A identifica o chamador. A autorização continua sendo responsabilidade de quem recebe a requisição. O protocolo não determina que um agente herde automaticamente todas as permissões de quem delegou o trabalho.
Eu trataria a chamada entre o orquestrador e o especialista como uma primeira fronteira. O serviço A2A validaria a identidade do chamador e sua permissão para solicitar aquela capacidade. A chamada seguinte, do especialista para o MCP Server, atravessaria uma segunda fronteira: a identidade e as permissões apresentadas precisam ser apropriadas ao recurso protegido.
Não reutilizaria indiscriminadamente o mesmo access token em toda a cadeia. Um token destinado ao serviço A2A não deveria ser aceito pelo MCP Server apenas porque ambos pertencem à mesma plataforma. Tampouco a credencial para consultar pagamentos deveria, por extensão, autorizar transferências.
A RFC 8707 define Resource Indicators, mecanismo pelo qual um cliente informa ao authorization server o recurso para o qual solicita acesso. A propriedade desejada é que cada recurso aceite apenas credenciais destinadas à sua fronteira de segurança, com permissões apropriadas.
Quando é necessário preservar quem iniciou a solicitação e qual workload está agindo em seu nome, a RFC 8693, sobre OAuth 2.0 Token Exchange, oferece outro mecanismo. Ela especifica trocas de tokens e distingue delegação de impersonation. Em perfis que utilizam essa semântica, sub pode identificar o sujeito original e act, o ator delegado.
Ampliar ↗Não significa que qualquer provedor OAuth ofereça o fluxo. Emissão de tokens compostos, política de delegação e suporte a token exchange dependem do authorization server. Quando ele não existe, uma operação app-only com autorização específica pode ser apropriada, desde que a identidade da aplicação não seja apresentada como se equivalesse à do usuário.
Também evitaria confundir delegação com impersonation. Quando o serviço downstream enxerga apenas o usuário, pode perder a informação sobre qual workload efetivamente atuou. Essa distinção importa para investigação, segregação de funções e responsabilização.
O MCP Server precisa autorizar a ferramenta no momento da chamada#
Desenvolvi dois templates open-source para explorar a fronteira de autenticação entre cliente e servidor MCP: mcp-client-auth-template e mcp-server-auth-template. São implementações de referência com OAuth/OIDC, validação de tokens, separação de permissões e verificações negativas, como rejeição de audience incorreta.
Uma decisão importante nos templates é separar a admissão do transporte da autorização de cada operação. Um access token válido ajuda a identificar o principal, mas o serviço ainda precisa verificar as permissões e as restrições de negócio relevantes à solicitação.
No exemplo financeiro, o servidor MCP poderia expor list_pending_payments, prepare_payment e execute_payment. A primeira permite consultas no escopo das empresas autorizadas. A segunda prepara uma solicitação pendente de aprovação. A terceira produz efeitos financeiros e atravessa uma fronteira distinta.
Eu não atribuiria as três operações ao mesmo nível de permissão apenas por pertencerem ao mesmo domínio. Uma política pode permitir consultas automaticamente, preparar pagamentos em certas condições e exigir autorização explícita vinculada à operação concreta antes da execução.
Ampliar ↗O MCP Server faria a verificação antes do despacho. A API financeira, por sua vez, continuaria responsável por controles próprios de autorização, limites transacionais e consistência. Um proxy MCP não torna automaticamente segura uma API que aceita indiscriminadamente a credencial técnica de seu intermediário.
Na especificação HTTP de autorização do MCP, o cliente utiliza OAuth e deve solicitar tokens destinados ao recurso adequado; o servidor valida que o token foi emitido para ele. As considerações de segurança proíbem o repasse direto de tokens de entrada para APIs downstream.
Também diferenciaria erros de autenticação e autorização. Credencial ausente ou inválida normalmente implica 401. Um token autenticado sem permissão suficiente pode resultar em 403 insufficient_scope. Isso pode disparar um fluxo de autorização adicional, mas não significa que o agente deva ampliar silenciosamente seus privilégios sempre que uma ferramenta negar acesso.
A possibilidade técnica de solicitar mais scopes não é justificativa para concedê-los. A decisão continua condicionada à política, ao recurso e, quando necessário, à interação do usuário.
O limite precisa sobreviver ao próximo agente#
Agora imagine que o especialista financeiro recebe a lista de pagamentos e delega a conferência dos documentos a um terceiro agente. Esse agente precisa consultar comprovantes e notas associadas, mas não necessita acessar saldos de outras contas, alterar favorecidos ou executar transações.
A delegação deveria manter o trabalho possível sem ampliar desnecessariamente os privilégios. Eu representaria a tarefa num contrato com capacidade solicitada, recursos permitidos e restrições. Esse contrato não seria, sozinho, uma credencial de segurança: seus atributos precisariam estar vinculados a uma autorização verificável.
Ampliar ↗Uma role genérica chamada financial_agent pode fazer sentido como parte da política, mas não determina o que o agente pode fazer numa execução específica. Valores, contas, beneficiários, empresa, finalidade e momento da operação exigem decisões mais contextuais.
Uma implementação pode separar a decisão de autorização em um componente de política (PDP) e a aplicação do resultado num ponto de enforcement (PEP), seja no gateway, no MCP Server ou na API. A localização depende da arquitetura, mas cada fronteira precisa ter responsabilidades claras.
Existe ainda uma consequência para tarefas longas. Um agente pode receber uma autorização no início e tentar concluir a operação horas depois. Nesse intervalo, o usuário pode perder acesso, a política pode mudar ou uma aprovação pode expirar. A emissão de um token por troca não garante automaticamente que uma revogação posterior no token original alcance a credencial já emitida.
Em operações sensíveis, eu exigiria revalidação da autorização no momento do efeito, duração limitada das credenciais e mecanismos de revogação adequados. Autoridade concedida no início do processo não deveria ser considerada permanente.
Uma execução auditável precisa identificar quem pediu e quem agiu#
Nos artigos anteriores sobre identidade de execução e observabilidade distribuída, tratei identificadores como execution_id, delegation_id e trace_id. Eles ajudam a reconstruir a trajetória entre componentes, mas não representam identidades de segurança.
Uma solicitação pode atravessar orquestrador, A2A e MCP em um único trace e ainda assim executar uma operação não autorizada. Um histórico técnico coerente não comprova, sozinho, que o principal tinha permissão sobre o recurso acessado.
Para operações relevantes, eu registraria uma evidência de autorização correlacionada à execução: sujeito que originou a requisição, workload que agiu, ação solicitada, recurso, política aplicada, decisão, instante da avaliação e referência ao efeito externo, quando houver.
Ampliar ↗Isso permite distinguir uma operação executada por uma credencial técnica legítima de uma operação legitimamente autorizada para determinado usuário e conta. A investigação precisa enxergar tanto o percurso quanto a legitimidade do efeito.
Ao mesmo tempo, evitaria registrar tokens, secrets ou payloads financeiros completos na telemetria. Identificadores opacos, hashes apropriados e referências de decisão normalmente oferecem um caminho mais seguro, desde que acompanhados de retenção, custódia e controle de acesso definidos.
Os templates MCP exercitam essa separação entre identidade, autorização e observabilidade. Isso demonstra propriedades do caminho implementado, mas não significa que uma arquitetura A2A montada ao redor deles já possua delegação de autoridade ponta a ponta resolvida.
Onde eu colocaria a fronteira#
Para o caso financeiro, manteria a liberdade do agente para consultar informações, selecionar especialistas e preparar análises dentro de um escopo autorizado. A passagem para uma operação que altera o estado financeiro exigiria outra verificação.
O especialista poderia produzir uma proposta estruturada de pagamento. Um componente fora do caminho de raciocínio do modelo verificaria o solicitante, as restrições da conta, a validade da aprovação e a correspondência entre o que foi autorizado e o que será efetivamente executado.
Se alguma verificação falhar, a ação não avança. Também não consideraria aceitável recorrer silenciosamente a uma credencial de serviço mais privilegiada para contornar a negativa.
Em algumas arquiteturas, o agente nem precisa receber a ferramenta de execução. Ele prepara a solicitação, e um serviço transacional separado, com identidade, políticas e controles próprios, produz o efeito. Isso introduz complexidade: identidades por workload, tokens vinculados a recursos, autorização contextual e evidências operacionais criam dependências. Uma ferramenta interna somente leitura pode não precisar da mesma estrutura de um serviço que movimenta dinheiro ou acessa dados de várias empresas.
Quando agentes atravessam múltiplas fronteiras de segurança e podem gerar efeitos de alto impacto, porém, essa complexidade já existe no processo de negócio, ainda que uma arquitetura simplificada tente escondê-la.
Ao integrar agentes por A2A e ferramentas por MCP, eu começaria identificando cada fronteira de confiança. Em todas elas, o sistema precisa conseguir demonstrar quem está chamando, em nome de quem, com quais permissões e para produzir qual efeito. O agente pode escolher a ferramenta ou delegar parte do trabalho; a infraestrutura precisa continuar capaz de verificar se aquela identidade possui autoridade para a ação solicitada.