À medida que agentes deixam de apenas responder e passam a executar ações, a pergunta “qual modelo estamos usando?” deixa de ser suficiente. Também é necessário saber quem está agindo, em nome de quem, com qual permissão e por quanto tempo.
Em setembro de 2026, a Blueprint Alliance, liderada pela Okta e por empresas de identidade, segurança, dados e IA, propôs tratar cada agente como uma identidade de primeira classe. O princípio é simples: autonomia sem identidade verificável transforma integração em acesso compartilhado e torna difícil conter erros.
Por que uma chave de API não é identidade?
Uma chave prova que alguém possui um segredo. Ela raramente explica qual agente fez a chamada, quem o autorizou, para qual tarefa ou até quando. Quando vários fluxos compartilham a mesma credencial, revogar um agente pode interromper todos os demais.
Identidade inclui contexto e ciclo de vida: registro único, proprietário humano ou equipe, finalidade, sistemas permitidos, políticas, credenciais temporárias, histórico e estado ativo ou revogado.
O agente é um novo tipo de usuário
Usuários humanos trabalham em ritmo limitado e costumam acessar sistemas por telas. Um agente pode fazer milhares de chamadas, delegar a subagentes e operar continuamente. Por isso, copiar a conta de um funcionário não é uma solução adequada.
Ao mesmo tempo, agentes não devem receber uma conta “superadministradora” para evitar falhas de integração. Quanto maior o acesso permanente, maior o impacto possível de um erro, prompt injection ou comprometimento.
Quatro elementos de uma identidade segura
1. Identidade única e inventariada
Cada agente em produção deve ter identificador próprio, finalidade, versão, responsável, ambiente e lista de integrações. Agentes esquecidos ou criados fora do processo formam o chamado shadow AI.
2. Privilégio mínimo
Um agente de cobrança pode ler faturas vencidas e registrar contatos, mas não alterar dados bancários. Permissões devem corresponder às ferramentas e campos necessários.
3. Acesso temporário e por tarefa
Em vez de credenciais permanentes, o agente recebe um token curto associado à tarefa, ao usuário e ao escopo. Quando a execução termina, o acesso expira.
4. Delegação rastreável
Se um agente principal chama um subagente, a cadeia precisa preservar quem iniciou, quem delegou e qual limite foi herdado. Um subagente nunca deve ganhar mais poder do que o delegante.
Agir em nome do usuário
Há diferença entre um agente corporativo que executa uma rotina e um agente que age por solicitação de uma pessoa. No segundo caso, a autorização deve combinar a identidade do agente com a do usuário.
Se uma atendente não pode conceder descontos acima de 10%, o agente usado por ela também não pode. A integração precisa aplicar as políticas do usuário e as restrições próprias do agente — prevalecendo sempre o limite mais restritivo.
Exemplo: agente conectado ao CRM e WhatsApp
Um agente recebe uma conversa, consulta o cadastro e atualiza uma oportunidade. Sua identidade permite ler cliente e histórico, criar tarefa e enviar mensagem aprovada. Ela não permite exportar toda a base, excluir oportunidades ou alterar permissões.
Para aplicar desconto, o agente solicita autorização temporária a um gestor. O token vale para aquela oportunidade, dentro do limite e por poucos minutos. A trilha registra usuário, agente, regra, aprovação e efeito produzido.
OAuth, contas de serviço e tokens curtos
OAuth permite delegar acesso sem entregar a senha do usuário. Contas de serviço representam automações corporativas. Tokens de curta duração reduzem o tempo disponível para abuso. A escolha depende do sistema, mas a regra é evitar segredos permanentes e compartilhados.
Integrações antigas podem exigir credenciais tradicionais. Nesse caso, use cofre de segredos, rotação, proxy de acesso e isolamento. O agente não precisa conhecer a senha; ele precisa receber uma capacidade limitada.
Política baseada em intenção
Funções e grupos continuam importantes, mas agentes exigem contexto mais específico. Uma política pode considerar ação, recurso, valor, horário, ambiente, risco, usuário delegante e confiança da execução.
Por exemplo: “permitir criar pedido de reposição até R$ 2 mil para fornecedores aprovados; acima disso, exigir confirmação”. A intenção de negócio fica separada da escolha do modelo.
Descoberta e ciclo de vida
- Descobrir: localizar agentes, chaves, contas e integrações existentes.
- Registrar: atribuir identidade, finalidade e responsável.
- Autorizar: aplicar escopo mínimo e duração.
- Monitorar: observar uso, delegações e anomalias.
- Revisar: confirmar periodicamente se o acesso ainda é necessário.
- Conter: suspender rapidamente agente, token ou ferramenta.
- Desativar: remover credenciais e dependências ao encerrar o fluxo.
Checklist para colocar em produção
- todo agente possui dono e finalidade documentados;
- não há credencial humana compartilhada;
- permissões são específicas por ação e recurso;
- tokens expiram e podem ser revogados;
- delegações preservam o limite original;
- ações críticas exigem confirmação;
- logs identificam agente, usuário e versão;
- existe contenção sem desligar toda a plataforma;
- acessos são revisados após mudanças de processo.
Identidade complementa observabilidade e governança
Observabilidade mostra o que aconteceu; identidade explica quem podia fazer; governança define por que e sob quais regras. As três camadas se reforçam. Um log detalhado não compensa acesso excessivo, e uma boa política não ajuda se todos usam a mesma chave.
Integrações preparadas para agentes
O crescimento dos agentes exige revisar APIs, gateways, OAuth, contas de serviço e permissões dos sistemas atuais. O projeto não termina no prompt: segurança e identidade precisam fazer parte da arquitetura.
A ProativaIA desenvolve agentes e automações com IA, cria integrações empresariais e sistemas sob medida. Podemos estruturar identidades, permissões, delegações e aprovações para que os agentes atuem com o acesso necessário — e nada além dele.