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_permissionsThe 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 | Delegator | Result |
|---|---|---|
| Narrow | Admin | Narrow |
| Admin | Narrow | Narrow |
| Anything | Offboarded | 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 checks. That is not a security boundary. That is a suggestion.
Same agent code, different effective scopes, different invoker. Support team triggers it: support-level access. Finance team triggers it: finance-level access. No code change. Configuration only.
Autonomous triggers and dead authority
Interactive delegation is easy. The user clicks "run." Their identity is the delegator. Intersection applies.
Cron jobs, webhooks, database triggers. That is the hard part. No human is present when the agent fires.
The rule does not change: no delegation context = deny. No exceptions. No fallthrough.
Every autonomous trigger was configured by a human. That human is the delegator. The system records this at creation time, and re-validates it on every dispatch. Does the delegation still exist? Is it active? Does the delegator still have the permissions?
Any check fails, the agent does not fire.
The engineer who set up the weekly sync left 4 months ago. Without this: the agent keeps running with dead authority indefinitely. With this: offboarded delegator = dead trigger. Instantly. No manual cleanup. No quarterly review catching it 3 months late.
Red Hat frames this as "deperimeterization." Security controls tied not to who set them up or when, but to live, continuously-validated identity. The delegation is not a one-time grant. It is a contract that is re-checked every time it is exercised.
Two names on every action
Every action captures: who performed it and on whose authority.
performed_by: invoice-agent
on_behalf_of: jane.smith@company.com
trigger: cron/weekly-sync
action: create invoiceNot "who." Who for whom through what.
Most teams have this:
user: service-prod
action: INSERT
table: invoicesThe first log answers an incident in 5 minutes. The second takes 3 days of forensics, 2 war rooms, and a regrettable Slack thread.
The audit is captured at the database trigger level. Same transaction as the data mutation. If the write rolls back, the audit entry rolls back. No gaps. No phantom records. The agent process cannot reach the trigger. Cannot suppress it. Cannot alter it.
The token contract
The internal delegated token follows RFC 8693 (Token Exchange):
- Identity-only. No capabilities in the token. Permissions resolved from the database on every check. Revoke a role, it takes effect immediately. Not after token expiry. Now.
- Short-lived. 120 seconds. A stolen token is useless 2 minutes later.
- Audience-bound. Valid for one service. Cannot be replayed against another endpoint.
The token says "this agent acts for this human." Nothing more. The platform decides what that combination is allowed to do. On every request.
How this works in RootCX
Every agent deployed on a RootCX Core gets governed identity from the first invocation. No configuration. No opt-in.
Deterministic identity. Same RBAC as humans. Intersection computed on every tool call from the database. Standing mandates on every autonomous trigger, validated before dispatch. All authorization at the Core, outside the agent process. Dual-identity audit on every mutation, immutable, database trigger-level. Short-lived tokens, audience-enforced, identity-only.
The builder never thinks about governance. The platform handles it the same way Okta handles human auth: invisibly, universally, on every action.
The 8-point check
If you are building this yourself or evaluating platforms:
- Does every agent have its own identity? Not shared. Not the builder's.
- Is there a capability ceiling per agent? Set by admin, not by the agent.
- Is effective authority the intersection? On every action. Not once at deploy.
- Does "no delegator" = deny? No fallthrough. No silent default.
- Is the agent auth-unaware? Platform enforces. Agent cannot bypass.
- Do autonomous triggers carry standing mandates? Re-validated on every dispatch.
- Are tokens short-lived and audience-bound? Minutes, not days.
- Does the audit trail carry both identities? Who performed and on whose authority.
8 out of 8 means governed agents. Anything less means scripts with API keys wearing a trench coat.
Related: