AI Agent Governance: Identity, Delegation & Permissions in Practice | RootCX Blog

BlogAI Agent Governance: Identity, Delegation & Permissions in Practice<br>ai-agentsgovernanceagentic-identitysecurityrbaccomplianceauthentication<br>AI Agent Governance: Identity, Delegation & Permissions in Practice<br>Your AI agents need governed identity. Not shared API keys. Not the dev's credentials. A principal with bounded authority, delegation from humans, and an audit trail that answers "who authorized this" in 5 seconds.<br>Sandro Munda<br>May 27, 2026

Under what identity does your AI agent do its work?

Most teams never ask. They make it work. The agent gets a key, the key works, ship it. 6 months later nobody can explain who authorized what.

Three options. Two of them are wrong.

The impersonation trap

"The user triggers the agent, the agent acts as the user."

The agent inherits ALL the user's permissions. A support rep triggers an agent to look up an order. The agent now has access to financial reports, HR records, admin settings. Not because it needs them. Because the human has them and you passed the human's full identity to the agent.

Prompt injection? The attacker gets the user's full scope. Every API the user can reach, the agent can reach.

The audit trail says "bob@company.com modified 500 records." Bob was at lunch. His agent decided to do it. You cannot tell the difference.

Your SIEM is lying to you.

The service account trap

"Fine. Give the agent its own static token."

Better. Individual identity. Revocable. But who is accountable when it acts at 3am? A service account cannot be fired. Cannot be questioned in an incident review. Cannot appear on a responsibility matrix with a name attached.

Your cron fires every hour. The engineer who set it up left 4 months ago. The agent keeps running. Its permissions have not been reviewed since onboarding. You do not know why it has access to the payments table. Nobody does.

NIST SP 800-207 has a name for this: "implicit trust granted based solely on ownership." The perimeter model applied to workloads. Zero trust says no. Every interaction starts untrusted. Trust is computed from identity, context, and policy. On every request.

Delegation: the model that holds

The agent has its own identity. It acts on behalf of a human. Both identities are preserved. Permissions are the intersection of what the agent is allowed to do AND what the delegating human can do.

effective_authority = agent_role ∩ delegator_permissions

The intern triggers an admin-capable agent? Intern-level results. The admin triggers a narrow agent? The agent's narrow scope. Neither side escalates the other. Not trust. Math.

Red Hat calls this "verify and never trust." NIST SP 800-207 calls it "authentication and authorization as discrete functions performed before a session to an enterprise resource is established." Same principle, applied to AI agents instead of network sessions.

Every other approach fails here. This one holds. Here is what makes it work.

Identity is the anchor

Not a shared account. Not the builder's token. A permanent, stable identifier for this specific agent. Same identity system as your humans. Same directory. Same lifecycle. Same revocation path.

When you onboard an employee, you create their identity first. Everything else hangs off it. Access, permissions, audit. Same for agents. The identity is not a convenience. It is the anchor every other property depends on.

An agent without its own identity is a ghost in your system. It acts but cannot be named. It mutates but cannot be revoked. It breaks but cannot be investigated.

The ceiling and the floor

Two boundaries. Both enforced on every action.

The ceiling is the agent's role. Set by the admin, not the agent, not the developer. The maximum the agent may ever use. An invoice agent with read and create on invoices can never touch salary data. Not because you trust the LLM. Because the platform cannot execute the call. The check runs outside the agent's process, outside its prompt, outside anything a prompt injection can modify.

The floor is the delegator. The human whose authority the agent borrows for this action. If the human has only read access, the agent gets only read access. If the human is offboarded, the agent gets nothing.

The effective authority is always the intersection. The narrower of the two wins. Always.

Agent role<br>Delegator<br>Result

Narrow<br>Admin<br>Narrow

Admin<br>Narrow<br>Narrow

Anything<br>Offboarded<br>Deny

This is what contains prompt injection. A compromised agent cannot exceed the intersection scope. The blast radius is bounded by math, not by hope.

The agent knows nothing

Critical design choice. The agent carries no tokens. Checks no permissions. Knows nothing about the delegating user.

All authorization happens at the platform level. Outside the agent's code. Outside its prompt. Outside anything an attacker can reach.

If the auth check lived inside the agent, a compromised agent could disable its own...