O que significa autorização de agentes
Autorização de agentes é a decisão sobre o que um agente de IA pode fazer: quais routes ele pode chamar, quais dados ele pode ler, quais ações ele pode executar e em que volume. Isso é अलगo da identidade do agente, que trata de estabelecer qual agente, ou qual agente de um operador, está fazendo a request.
Os dois conceitos são fáceis de confundir porque muitas vezes chegam juntos. Uma request assinada informa quem a enviou. Ela não informa se esse remetente deve poder alterar uma conta, fazer um pedido ou exportar dados. Identidade é evidência; autorização é policy. Nosso artigo sobre o que requests assinadas de agentes de IA comprovam, e o que não comprovam detalha essa diferença.
Por que a distinção importa
Aplicações já separam autenticação de autorização para usuários humanos: fazer login comprova quem você é, e funções e permissões definem o que você pode fazer. Agentes precisam da mesma separação, com uma camada extra de cuidado:
- A identidade pode ser forte enquanto a permissão está ausente. Um crawler com uma assinatura de mensagem HTTP perfeitamente válida não tem direito inerente de chamar um endpoint de escrita.
- A permissão pode existir sem identidade forte. Um agente usando a API key de um cliente está autorizado por essa key, mesmo que nada identifique qual software de agente está a carregando.
- A pessoa por trás do agente importa. Quando um agente age em nome de alguém, a questão passa a ser se essa pessoa lhe concedeu autoridade (veja autoridade delegada).
Juntar tudo isso em uma única verificação leva a dois modos de falha: bloquear automação legítima porque ela não tem login humano, ou confiar a um agente bem identificado ações que ele nunca deveria executar.
Como a autorização costuma ser expressa
A maioria das aplicações autoriza agentes com mecanismos que já possuem:
- Credenciais e scopes. API keys ou tokens de OAuth 2.0 com scopes limitados ao que a integração precisa. MCP servers usam o mesmo modelo: a especificação de autorização do MCP trata um server protegido como um resource server OAuth 2.1.
- Policy por route. Routes apenas de leitura abertas para agentes conhecidos; routes de escrita exigindo uma credencial vinculada a uma conta.
- Níveis de risco. Ações de baixo impacto permitidas amplamente, ações de alto impacto exigindo credenciais mais fortes, confirmação ou revisão.
- Limites de taxa e cotas por operador, por credencial ou por route.
Evidências de identidade do agente entram nessas decisões como um insumo. Para uma abordagem prática, veja como desenhar policies no nível da aplicação para humanos e agentes de IA. Isso permite tratar um operador verificado de forma diferente de um cliente anônimo, mas a permissão em si ainda vem da sua policy.
Equívocos comuns
- "Agente verificado significa autorizado." A verificação atribui uma request. Sua policy ainda decide o que essa parte atribuída pode fazer.
- "Agentes devem ser bloqueados a menos que provem ser humanos." Muitos agentes são participantes legítimos. A pergunta melhor é o que cada tipo de ator deve poder fazer, route por route.
- "A autorização pode ser inferida pelo comportamento." O comportamento pode aumentar ou reduzir a confiança sobre que tipo de ator está presente. Ele não deve conceder permissão por si só.
Como o Proof of Actor trata isso
Proof of Actor responde à questão de evidência: que tipo de ator está presente, com base em quê (Verified, Declared, Inferred ou Unknown), e o que é conhecido e o que não é conhecido. Ele deliberadamente não decide permissão. Um resultado de Agent, mesmo verificado, nunca implica autorização. Em Route, sua aplicação combina o resultado do ator com suas próprias credenciais, scopes e níveis de risco para permitir, adaptar, challenge, review ou limitar cada interação, começando em modo de observação para que você possa verificar os resultados antes de aplicar qualquer enforcement.
Saiba mais sobre como as decisões se encaixam na sua aplicação, veja os casos de uso de APIs e MCP servers, ou solicite acesso antecipado.
Fontes
- RFC 6749: The OAuth 2.0 Authorization Framework: tokens com scopes para clientes
- MCP specification 2026-07-28: Authorization: autorização baseada em OAuth para MCP servers
- RFC 9421: HTTP Message Signatures: o que uma request assinada estabelece