Agentes de IA estão se tornando participantes ativos dos sistemas de software. Eles leem issues, abrem pull requests, consultam bancos de dados, chamam APIs SaaS, agendam tarefas e disparam automações. Isso significa que eles precisam de modelos de identidade e autorização tão bem desenhados quanto os usados para pessoas e serviços backend.
Durante anos, sistemas backend separaram os atores em dois grupos principais: pessoas e serviços. Pessoas entravam com contas de usuário. Serviços usavam chaves de API, service accounts, clientes OAuth ou identidade de workload. Agentes de IA bagunçam essa divisão, porque se comportam como serviços, mas muitas vezes agem em nome de uma pessoa, dentro de um contexto que muda a cada tarefa.
Um agente que resume logs talvez precise apenas de leitura. Cinco minutos depois, o mesmo agente pode tentar criar um ticket de incidente, rotacionar uma credencial ou disparar um deploy. Se o sistema tratar esse agente como uma service account administrativa permanente, cada chamada de ferramenta nasce com privilégio demais. Se tratar como uma sessão comum de usuário, perde a capacidade de separar intenção humana de execução autônoma.
Em 2026, isso deixou de ser um exercício teórico de arquitetura. O NIST lançou uma iniciativa de padrões para agentes de IA focada em ecossistemas seguros e interoperáveis. O NIST também publicou um resumo de respostas sobre segurança de agentes de IA, no qual houve amplo consenso de que agentes criam riscos novos e que práticas tradicionais de cibersegurança precisam ser adaptadas.
Para quem constrói backend, a consequência prática é direta: acesso de agentes não pode ser improvisado. A partir do momento em que um agente tem acesso a ferramentas, suas APIs precisam saber quem é o agente, quem ele representa, o que ele pode fazer e como revogar essa autoridade quando a tarefa acabar.
OAuth é útil porque modela autorização delegada. Um usuário ou sistema concede a um cliente acesso limitado a um resource server. Isso combina bem com fluxos de agentes, desde que a implementação não transforme OAuth em um balde de permissões amplas e duradouras.
Em um fluxo delegado por uma pessoa, o agente normalmente deveria receber um token estreito, temporário e ligado a uma tarefa. Em fluxos de agentes de fundo, client credentials ou workload identity podem fazer sentido, mas ainda precisam de escopos, políticas e rastreabilidade. O ponto é evitar um único "token do agente" capaz de ler e escrever tudo.
Um bom modelo de identidade para agentes registra mais de um ator. Ele deve capturar a pessoa solicitante, a instância do agente, a ferramenta ou servidor MCP usado, a API de destino e a decisão de política que permitiu a ação. É parecido com tracing distribuído: uma requisição passa por vários sistemas, mas o trace mantém a história conectada.
Essa identidade em camadas é essencial em resposta a incidentes. Se um registro do banco foi alterado, o log não deveria dizer apenas "service-account-agent-prod atualizou a linha 123". Ele deveria responder: qual usuário iniciou a tarefa, qual agente gerou a ação, qual permissão foi concedida, qual ferramenta executou e se o resultado bateu com o plano aprovado.
O lugar mais seguro para aplicar autorização de agentes não é o prompt. Prompts podem descrever regras, mas a aplicação real pertence ao código. Um gateway de política fica entre o agente e as ferramentas. Ele recebe chamadas propostas, avalia políticas, pede aprovação humana quando necessário, emite credenciais escopadas e grava eventos de auditoria.
Isso é especialmente importante em ecossistemas de ferramentas no estilo MCP. MCP pode expor capacidades muito úteis aos agentes, mas cada capacidade exposta também vira uma fronteira de permissão. Um servidor MCP de banco de dados não deveria liberar escrita só porque o agente formulou um pedido convincente. O gateway deve decidir se aquela tarefa, ator, ambiente e recurso justificam a ação.
Escopos tradicionais costumam representar permissões amplas de aplicação: ler faturas, escrever tickets, gerenciar usuários. Agentes precisam de escopos mais contextuais. Um escopo em formato de tarefa pode permitir criar um único ticket para um cliente, ler logs de um serviço na última hora ou gerar um pull request em rascunho sem permissão de merge.
| Controle | Padrão fraco | Padrão mais seguro |
|---|---|---|
| Vida do token | Token compartilhado e duradouro para todas as ações do agente. | Token curto, vinculado a uma tarefa ou sessão específica. |
| Design de escopo | Escopos genéricos de administrador, como write:all. |
Escopos limitados por recurso, ação, ambiente e tempo. |
| Aprovação humana | O agente decide sozinho quando uma ação é segura. | A política exige aprovação para chamadas destrutivas ou de alto risco. |
| Auditabilidade | Logs mostram apenas o nome de uma service account. | Logs conectam pessoa, agente, ferramenta, token, requisição e resultado. |
| Revogação | A credencial continua válida depois que a tarefa termina. | O token expira automaticamente e pode ser revogado na hora. |
Para uma implementação prática e com cara de portfólio, eu construiria um gateway de autorização para agentes usando Cloudflare Workers ou FastAPI, com Postgres/Supabase para políticas e auditoria. O agente nunca chamaria APIs sensíveis diretamente. Ele enviaria a ação proposta ao gateway. O gateway validaria a requisição, encontraria a política correspondente, emitiria uma credencial curta ou um token interno assinado e só então faria o proxy da chamada aprovada.
A primeira versão teria: registro de ferramentas, definições de ações escopadas, níveis de risco, estados de aprovação humana, expiração de tokens, logs estruturados e um dashboard pequeno com ações recentes dos agentes. Esse dashboard importa. Segurança de agentes não é só bloquear ataques; é tornar atividade autônoma visível o suficiente para que humanos possam confiar nela.
Sistemas de autorização para agentes falham de formas previsíveis. A falha mais comum é excesso de privilégio: um token amplo é mais fácil de entregar do que um token escopado. A segunda é falta de atribuição: o log mostra que uma API foi chamada, mas não mostra por quê. A terceira é bypass de política: o agente encontra um caminho direto para a API e foge do gateway. A quarta é fadiga de aprovação: humanos aprovam tudo porque o sistema pede confirmação o tempo inteiro.
Um bom desenho reduz essas falhas com políticas default-deny, emissão estreita de tokens, acesso a ferramentas por um caminho controlado, aprovação baseada em risco e dashboards que resumem a atividade em vez de enterrar revisores em logs crus.
Cada ação de agente deve gerar telemetria estruturada. No mínimo: ID do agente, solicitante humano, ID da tarefa, ferramenta usada, recurso alvo, escopos solicitados, escopos concedidos, decisão de política, status de aprovação, latência, resultado e indicação de campos sensíveis mascarados.
Com esses eventos, o sistema passa a responder perguntas úteis: quais ferramentas os agentes mais usam, quais ações exigem mais aprovação manual, quais escopos estão amplos demais, quais prompts geram bloqueios repetidos e quais automações já são seguras o suficiente para ganhar mais autonomia.
Agentes de IA não devem herdar confiança por escreverem bem. Um plano bem redigido não é autorização. Uma chamada confiante de ferramenta não é aprovação. Sistemas de produção precisam de limites aplicáveis: identidade, escopos, política, aprovação, execução, auditoria e revogação.
Essa é a diferença entre um agente apenas conectado a ferramentas e um agente capaz de participar com segurança de operações backend reais.
Artigo sobre identidade e autorização para agentes de IA cobrindo OAuth para agentes, identidade não humana, autorização de APIs, tokens escopados, gateways de política, segurança de ferramentas MCP, logs de auditoria, privilégio mínimo, aprovação humana e arquitetura backend para ações autônomas seguras.