Quem é o agente? Identity, IAM e Least Privilege para AI Agents Enterprise

IAM clássico responde “quem é a pessoa e o que ela pode”. Agentes quebram o sujeito. Quem autenticou no SSO foi a analista. Quem chamou o SAP foi um workload. Quem decidiu o argumento foi um modelo. Quem publicou a tool foi um publisher MCP. Quem recebeu o handoff foi um agente A2A de um parceiro. Se o log só guarda o Bearer da analista, você não consegue atribuir, revogar nem limitar.

Este artigo trata Agent Identity como peça do harness — a mesma camada Identity & Permissions que o texto de Agent Harness já isolou: identidade do usuário, identidade do agente, credenciais das tools. Sem ela, least privilege é um slide e MCP Security não tem sujeito para revogar.

Três identidades, não uma

• Human identity — Entra ID, Google Workspace, Okta. Origem do consentimento.
• Agent identity — registro primeiro do agente: papel, tenant, autonomia máxima, dono, ciclo de vida. Não é o modelo (GPT-x). É o principal.
• Workload identity — como o runtime se autentica em APIs (SPIFFE/SPIRE, managed identity, OAuth client credentials com rotação). Nunca API key no prompt.

Delegação: OAuth 2.1, OIDC e mandatos

O padrão maduro não é “o agente usa o cookie do usuário”. É o usuário (ou o IdP) emitir um mandato: este agente, estas scopes, este recurso, esta janela de tempo, este propósito. OAuth 2.1 + PKCE no humano; tokens de workload curtos; downscoping na tool. OIDC identifica. OAuth autoriza. O harness guarda o grant. AP2, no comércio, é o primo criptográfico dessa ideia para pagamento (IntentMandate / PaymentMandate). KYA (Visa, Mastercard, Ant, setembro 2026) tenta o mesmo na rede: ligar o agente a um operador validado.

Scopes e least privilege de verdade

Least privilege para agentes é mais fino que RBAC de humano. A analista pode ter leitura ampla no BI. O agente de conciliação precisa de leitura de um conjunto de lançamentos e escrita em um diário específico, só em horário, só até um valor. Scopes por tool, não por “role AgentUser”. Temporary credentials (STS, federated tokens) com TTL menor que a sessão de chat. Se o run dura três dias (long-running), o harness renova — não estica um secret de três dias no container.

1. Uma identidade de agente por papel de negócio, não um “superagente”.
2. Uma credencial de tool por destino, não um PATzinho que abre a org.
3. Deny by default no Policy Engine; o token só prova quem é, não o que pode.
4. Break-glass humano, não break-glass do modelo.

Subagentes e A2A: a cadeia não pode quebrar

Quando o agente A delega ao agente B via A2A, B não herda o universo de A. Herda um mandato derivado, mais estreito. O Agent Card descreve skills; o token descreve permissão. Sem isso, um parceiro com um card bonito opera com o seu IAM. A auditoria precisa mostrar A → B → tool, ou o CISO recusa o desenho — corretamente.

Audit chain: o artefato que o regulador pede

• subject humano (sub OIDC)
• agent_id e versão de política
• grant_id / mandate_id
• workload_id
• tool, args redigidos, decision (allow/deny/HITL)
• trace_id
• quando humano aprovou, quem foi

Isso é o que liga Identity ao Observability. Sem os campos, o trace é anônimo. Sem o trace, a identidade é um cadastro morto.

type ActionContext = {
  human: { sub: string };
  agent: { id: string; maxAutonomy: string };
  grant: { scopes: string[]; expiresAt: string };
  workload: { iss: string; aud: string };
  tool: { name: string; requiredScope: string };
};

function authorize(ctx: ActionContext) {
  if (Date.now() > Date.parse(ctx.grant.expiresAt)) return "deny";
  if (!ctx.grant.scopes.includes(ctx.tool.requiredScope)) return "deny";
  if (risk(ctx.tool.name) === "financial") return "require_approval";
  return "allow";
}

Anti-padrões que eu recuso em enterprise

• API key de serviço no header de todas as tools MCP.
• Agente usando a sessão interativa do funcionário para RPA disfarçado.
• Um único service principal “ai-agent-prod” com Contributor na subscription.
• Revogação só da pessoa no IdP — o agente continua com o refresh token.
• Identity do modelo (“sou o GPT”) no lugar da identity do principal.

EmerAgents como dono do principal

Na fábrica, cada agente de orquestração é um principal registrado: dono, escopos, autonomia por ação, integração com o IdP do cliente. EmerAgents não “impersona o SAP”. Ele apresenta workload identity e pede HITL quando o mandato não cobre a escrita. Isso é o oposto de bot de tela e o oposto de admin key no chat.

Conclusão

Quem é o agente? Se a resposta for “o LLM” ou “o usuário”, o desenho ainda é de 2023. A resposta de 2026 é uma cadeia: humano, agente, mandato, workload, tool, recurso — com least privilege e audit. Sem isso, MCP, A2A e AP2 só aceleram ações sem sujeito. Com isso, o Policy Engine do harness finalmente tem o que avaliar.