Agent Identity Is the New Enterprise AI Security Boundary

Why every production AI agent needs its own identity, permissions, and audit trail

Part 3 of a six-part series on the Enterprise Agentic AI Control Plane.

Part 1 explained why enterprises need an Agentic AI Control Plane. Part 2 laid out how to build one. This post goes deep on the foundation that everything else rests on: agent identity.

Here is the shift. For decades, the security question was which user made this request? In agentic systems that is no longer sufficient. You also need to know:

• Which agent acted?
• What was it allowed to do?
• Was it acting on behalf of a user — and which one?
• Did the action stay within its approved scope?

If you can't answer those, you can't authorize, audit, or contain anything.

Five identities, not one

A single agent action quietly involves several distinct identities. Collapsing them into one is where governance breaks.

• User identity — the human ultimately accountable for the request.
• Application identity — the app or service the agent runs inside.
• Agent identity — this agent, with its own role, permissions, and lifecycle.
• Tool identity — the downstream system the agent is calling (which has its own access model).
• Session identity — this run, for this task, bounded in time.

Most stacks today flatten all of these into one bearer token and call it a day. That token says "this is user X," and the agent inherits everything user X can do. That is not identity. It is impersonation with extra steps.

User permission is not agent permission

This is the single most important idea in the post, so it gets its own heading.

A user being allowed to access something does not mean every agent acting for that user should have the same access.

A finance analyst can legitimately pull payroll data and initiate a payment. It does not follow that a scheduling assistant acting on that analyst's behalf should be able to touch either. Yet if the assistant carries the analyst's token, it can — and a single poisoned calendar invite is enough to make it try.

This is the classic confused deputy: a privileged component tricked into misusing authority it was loaned. It is already happening in the wild — in one documented ChatGPT Operator exploit, injected web content steered the agent into a page where it was already authenticated as the user and exfiltrated data. The agent wasn't breached. It was correctly using the identity it had borrowed.

OWASP's agentic threat catalog names this family directly: Identity Spoofing & Impersonation and Privilege Compromise. The fix is to stop letting agents borrow blanket user authority, and instead give them their own scoped, verifiable identity.

What agent identity has to express

A production agent identity is more than a name. It has to carry:

• Acting-on-behalf-of — a verifiable link from agent to the user who authorized it, so accountability is never lost.
• Roles and permissions — what this agent is for, and the bounded set of things it may do.
• Agent-to-tool authorization — which tools and APIs it may call, independent of what the user could call.
• Agent-to-agent authorization — when one agent hands off to another, the second doesn't silently inherit the first's power; the delegation is explicit and scoped.
• Task-scoped permissions — access granted for this task, not standing forever.
• Temporary credentials — short-lived, expiring tokens instead of long-lived secrets the agent carries around.
• Delegated access — a chain you can read: user U authorized agent A, as app P, with scope S, until time T.
• Audit trails — every action attributable to a specific agent identity and session.
• Non-human identity management — agents are non-human identities and belong in the same lifecycle (issuance, rotation, deprovisioning) as service accounts and workloads.
• Kill switches and revocation — the ability to instantly revoke an agent or session when it misbehaves, without taking down the human's account.

The building blocks already exist: workload identity systems like SPIFFE/SPIRE give non-human components attested, short-lived identities, and OAuth's on-behalf-of flows already model "service acting for user with scope." Agents are the case that needs all of it at once — and the standards are racing to catch up, from the IETF's WIMSE work on agent identity and NIST's concept paper on agent identity and authorization to research systems like SAGA, where agents register for cryptographic, scoped tokens. None is settled yet.

Assertion is not identity

This is exactly where most first cuts fall short — including the reference implementation for this series. Today it decodes a signed token into an actor whose agent_id and allowed_tools are claims the token asserts about itself. Whoever minted the token declared what the agent is and what it may touch. That is an assertion, not a verified identity — and naming the gap is the point. The upgrade path is concrete: from a self-declared claim to a verifiable delegation, and from a static permission list to a short-lived, revocable scope.

Making agent identity verifiable, scoped, and revocable — rather than self-asserted — remains an open problem in production agentic systems. It's the one I take on directly in the capstone, where the reference implementation moves from decoded JWT claims to a verifiable delegation chain with short-lived, revocable scope. A control plane is only as trustworthy as the identity it keys decisions off, so this is the foundation to harden first.

What this looks like in practice

The same principle, across four very different agents:

• A sales assistant agent can draft proposals and read the CRM — but it has no business touching HR records, even when the salesperson using it technically could.
• A support agent may read customer tickets, but issuing a refund requires approval — reading and acting are different privileges.
• A DevOps agent may open incidents and gather diagnostics, but modifying production requires explicit authorization it does not hold by default.
• A finance agent may prepare a payment workflow, but executing it autonomously is off the table — preparation and execution are separated on purpose.

In each case the agent's identity is narrower than the user's. That narrowing is the whole point.

Why identity is the foundation

Agent identity is not one feature among many. It is the base the rest of the control plane is built on:

• Authorization needs to know which principal is acting before it can decide.
• Accountability needs every action tied to a responsible identity.
• Auditability needs that identity recorded on every event.
• Least privilege is meaningless if you can't tell which agent to scope.
• Incident investigation needs to trace exactly which agent and session did what.
• Policy enforcement keys every rule off the acting identity.

Get identity wrong and all five degrade quietly. Get it right and the rest of the control plane has something solid to stand on.

What comes next

Identity tells the enterprise who is acting. It does not, by itself, decide what that identity is allowed to do. A perfectly identified agent can still be steered into a catastrophic action — if it has the tools.

In Part 4 — Tool Governance: Where Agentic AI Becomes Risky, we move from identity to capability: why tools are the point where agents stop responding and start acting, and how the control plane governs every tool call.

Tags: Agentic AI, Identity Security, AI Governance, Enterprise Security, Non Human Identity