Zero-Trust Identity for AI Agents: Who Did the Agent Just Act As?

When an autonomous agent deletes a record, moves money, or opens a pull request, a security team has to be able to answer one question instantly: who did the agent just act as, and was it allowed to? For a human, that answer is routine — a named account, a role, an audit log. For AI agents, it is too often a shrug. The agent ran under a shared service account, or an API key baked into a container, or the developer's own credentials. The action happened; the actor is a blur.

That blur is an enterprise non-starter. Agents that take real actions need first-class, scoped identities — the same way people and workloads do, and arguably more so, because agents act autonomously, delegate to each other, and can rewrite their own behavior. This post makes the case for zero-trust identity at the agent layer: why agent identity is its own category, the risks of getting it wrong, and how scoped identity plus per-action verification gives you a provable answer to "who acted?" every single time.

Agent identity is not user identity — or a service account

The instinct is to reuse what we already have. It fails in both directions. An agent is not a user: it acts continuously and autonomously, at machine speed, without a human clicking "confirm" on each step — so borrowing a person's credentials means every action the agent takes is falsely attributed to that person, and the person's full access becomes the agent's blast radius. An agent is also not a traditional service account: service accounts were built for one long-lived workload with a fixed job, whereas agents spin up and retire quickly, hold goals and memory, and fan work out to other agents.

So agent identity is its own category — a non-human identity that is autonomous, short-lived, delegating, and mutable. The design consequences follow directly: identity must be per-agent (never shared), scoped to the specific task and least-privilege for it, verifiable at the moment of action rather than assumed from a network position, and traceable through delegation so that when one agent hands work to another, the chain of "who authorized whom" survives. This is the identity pillar of the SPHR model in practice — covered alongside the other dimensions in the seven pillars of production-ready agentic AI.

AI agents are non-human identities (NHIs)

Zoom out and agent identity is one instance of a bigger 2026 problem: non-human identities — service accounts, workloads, bots, and now autonomous agents — already outnumber human identities in the enterprise by a wide margin. KPMG's 2026 cybersecurity report puts the ratio at roughly 80 to 1, and industry surveys find that while about 92% of leaders say governing AI agents is critical, only around 44% have implemented any policy to do it (KPMG, 2026). That gap is exactly where ungoverned agents live. Agents are the fastest-growing and hardest NHI class, because — unlike a static service account — they acquire permissions at runtime, spawn sub-agents, and act on their own, so the blast radius of one leaked credential is whatever the whole chain can reach. Treating each agent as a first-class NHI with its own scoped, revocable identity is the entry point to everything below.

The risks of getting agent identity wrong

OWASP named this directly. In the Top 10 for Agentic Applications, ASI03 — Agent Identity & Privilege Abuse describes an agent acting with more privilege than its task needs, or under a shared or ambient identity, so actions cannot be attributed and least-privilege cannot be enforced. It is not an exotic edge case; it is the default failure mode when you skip identity design. Three concrete failures show up again and again:

• Identity abuse. A prompt injection or a hijacked goal steers the agent into actions it was never meant to take — but because it runs under a broad, shared identity, those actions are permitted, and the log shows only the service account, not the real cause.
• Privilege creep. To make the agent "just work," someone grants it wide scopes once and never revokes them. Over time the agent accumulates access far beyond any single task, so a single compromised credential exposes everything it can reach.
• Untraceable delegation. The agent calls another agent, which calls a tool, which calls an API. If identity does not propagate, each hop looks like a fresh, anonymous request. When something goes wrong, you cannot reconstruct who authorized what — the delegation chain is a dead end.

These map to more than one risk in the OWASP list — identity abuse touches ASI03, poor delegation touches insecure inter-agent communication, and unbounded scope amplifies everything downstream. We walk the full list, each mapped to a concrete control, in the OWASP Agentic Top 10 production checklist.

Zero-trust identity, applied to agents

Zero-trust has one rule — never trust, always verify — and agents are exactly the workload it was built for. The shift is to stop treating identity as something established once at login and start treating it as something re-verified at the point of action. Every meaningful thing an agent does is an action: read this file, call this API, delegate to that agent. Attach a verifiable identity to each action and check its scope before execution, and "who acted, with what authority?" always has an answer. The mental model is simple:

Agent identity  →  Verify + scope check  →  Allow / Deny  →  Audit log

Microsoft's open-source Agent Governance Toolkit is a concrete example of that pattern. Its Agent Mesh gives each agent a cryptographic identity via decentralized identifiers (DIDs) signed with Ed25519, so an agent proves who it is rather than borrowing a human's credentials. It layers a dynamic trust score — a 0-to-1000 scale with behavioral tiers — on top, so an agent's standing reflects how it has actually behaved. Paired with per-action policy evaluation and capability sandboxing that bounds what each action can reach, this is zero-trust identity operating at the action layer. Because the toolkit is framework-agnostic, the same identity model governs a coding agent, a local agent, or a LangChain pipeline alike — which is why SPHR builds model-agnostic and multi-cloud: the engine should be swappable, the identity controls should not.

Delegation chains: proving which agent acted as whom

Multi-agent systems make identity harder in a specific way: work moves. A planner hands a subtask to a researcher, which asks a tool-runner to hit an external API. If each hop re-authenticates as an anonymous or shared identity, you have lost the thread the moment the first handoff happens. The fix is to make delegation a first-class, bounded event rather than a silent re-login.

• Propagate identity, don't reset it. Each delegated action should carry the originating identity plus the delegating agent's, so the record reads as a chain — human or system → planner → researcher → tool-runner — not a series of disconnected requests.
• Narrow scope on the way down. Delegation must never widen authority. A sub-agent should receive a subset of the caller's scope, scoped to the subtask; it can never end up with more privilege than the agent that called it.
• Keep the chain verifiable. The scope chain should be cryptographically attributable at each hop, so an auditor can reconstruct exactly who authorized whom, and revoke a single link without tearing down the whole system.

The Agent Governance Toolkit approaches this with its inter-agent trust protocol and scope chains across delegation hops — bounded, traceable authority instead of privilege that quietly escalates as it passes from agent to agent. Notice the pattern is the same one that makes audit work: because identity is enforced at the action layer, the record of who acted is a byproduct of enforcement, not a separate logging effort. We go deeper on that reconstructible evidence in the self-improving agent's audit problem.

An agent identity-readiness checklist

Before you let an autonomous agent act on a real system, walk this list. If you cannot answer "yes" to all five, you have an actor you cannot account for — which is another way of saying you have an incident waiting to be attributed to the wrong person:

• Per-agent identity. Does every agent have its own first-class identity — not a shared service account, not a baked-in API key, not a human's credentials?
• Least privilege. Is each identity scoped to exactly what its task needs, with no standing access that outlives the task?
• Verify before acting. Is identity and scope checked before each action executes, at the action layer, rather than assumed once at startup?
• Delegation is bounded and traceable. When one agent delegates to another, does authority narrow rather than widen, and does the scope chain stay verifiable across every hop?
• Revocable and attributable. Can you revoke a single agent's identity without disruption, and can you prove, after the fact, which agent took any given action and under whose authority?

None of these are about how smart the agent is. They are controls in the layer around it — the difference between a demo and a system you can hand to a regulator.

How SPHR helps

SPHR builds production agentic AI for enterprises across the USA, Brazil, Australia, and Japan. We help security and IAM teams give their agents first-class, scoped identities, enforce least-privilege and verify scope before each action, and keep delegation chains bounded and provable — so "who did the agent just act as?" always has an answer. As an Anthropic partner working model-agnostic and multi-cloud, we design the identity layer to outlast any single agent framework you adopt. If you are weighing how to give your agents an identity your CISO can defend, we'd love to talk.

Frequently asked questions

Why can't an AI agent just use a service account?

A shared service account collapses many actors into one identity, so you cannot tell which agent did what, and you cannot scope permissions to a single agent's task. When ten agents share one credential, the blast radius of that credential is the sum of everything all ten are allowed to touch, and the audit trail says only that the service account acted. First-class, scoped per-agent identity is what makes actions attributable and least-privilege enforceable.

What is OWASP ASI03 and how does agent identity relate to it?

ASI03 is Agent Identity and Privilege Abuse in the OWASP Top 10 for Agentic Applications. It describes an agent acting with more privilege than its task needs, or under a shared or ambient identity, so its actions cannot be attributed and least-privilege cannot be enforced. Giving each agent its own scoped identity with least-privilege credentials, and checking privilege before each action, is the direct control for ASI03.

How do you prove which agent acted, across a delegation chain?

You carry a verifiable identity with every action and preserve a scope chain across each delegation hop, so the record shows the originating human or system, the agent that acted, and any agents it delegated to. Microsoft's Agent Governance Toolkit models this with decentralized identifiers and an inter-agent trust protocol so delegated authority stays bounded and traceable rather than escalating silently across hops.

Is zero-trust identity for agents different from zero-trust for users?

The principle is the same — never trust, always verify — but agents change the shape of the problem. Agents are non-human identities that act autonomously, spin up and retire quickly, delegate to other agents, and can rewrite their own behavior. So you verify identity and re-check scope before every action rather than once at login, and you treat delegation as a first-class event that must preserve, not widen, the caller's scope.

Does per-agent identity and per-action verification slow agents down?

It should be negligible. Identity checks and policy evaluation happen at the action layer, and modern runtime policy engines such as the Microsoft Agent Governance Toolkit report p99 policy-evaluation latency under 0.1 ms, so every tool call can be verified without noticeable overhead. The real cost of zero-trust identity is design effort up front — issuing, scoping, and rotating credentials — not runtime speed.

The agent identity and delegation model here draws on Microsoft's open-source Agent Governance Toolkit and the OWASP Top 10 for Agentic Applications (ASI03). We've framed both for enterprise AI delivery.