You’ve registered your agents as principals in your Identity Provider. You’ve federated workload credentials, deployed Non-Human Identity controls, and tightened scopes. The agent has an identity, its secrets are vaulted, its access is governed. And your CFO’s research agent is still running at 2:05 PM, pulling pre-IPO financials, on a mandate that expired when the board approved the presentation at 2:00 PM.

Check every control: the token is valid, authorization policy permitted the request, Just-In-Time (JIT) provisioning and permissions granted time-based least privilege access, and Continuous Access Evaluation Protocol (CAEP) is publishing revocation events. Every layer shows green. The breach is structurally invisible, not because the stack failed, but because no layer of it was built to ask whether the mission behind the request should still be running.

When an agent acts on your behalf, it does not need your identity. It needs your authority. Those are not the same thing, and enterprise security stacks were built as if they were. Every IAM control in that stack is optimized for a request-scoped question: may this action proceed right now? The question agents expose is different in kind. It is mission-scoped: should this execution still be running at all? No widely adopted IAM pattern owns that question as a first-class concern.

The IAM systems governing enterprise access today were designed around a foundational assumption: humans execute actions. A person authenticates, crosses a boundary, acts, and stops. The security boundary and the execution boundary were the same thing because presence and pacing enforced both.

Agents remove those constraints. They don’t stop when the task ends. Credentials don’t expire when purpose does. The result is ghost execution: an agent executing with valid credentials in service of a mandate that has already expired. NIST’s National Cybersecurity Center of Excellence has identified the gap as an active research area, noting in a concept paper that “existing enterprise practices were not built with AI agents in mind.”

The industry is responding. Market analysis of the emerging agentic identity space maps investment flowing toward centralized brokering, Zero Standing Privileges, JIT provisioning, and intent-aware authorization. Better passports, more precisely stamped. That direction correctly addresses the problem the access layer owns. What agents expose is not a flaw in its design. It is what happens when the human who was implicitly governing mission scope is removed from the loop. Should this execution still be running at all?

🆔 Identity vs. Authority

Agents force a distinction that has always existed, but was easy to ignore:

• Identity: establishes who an actor is at a boundary
• Access: determines whether a specific request may proceed
• Delegation: governs what an actor may do on behalf of another
• Authority (Power of Attorney): governs whether and how an actor may continue to act

A passport lets you cross a border. A Power of Attorney (PoA) lets you act after crossing it. Modern systems have more mature coverage of the first two. Delegation is partially addressed but not standardized end-to-end. Authority, a purpose-scoped, independently revocable right to act on behalf of another principal, has no widely adopted equivalent in current enterprise security stacks. That is the gap agents are exposing.

Throughout this series, these terms carry specific meanings. Authority is the conceptual domain. Mandate is the concrete artifact that carries and enforces it. Power of Attorney is the legal analogy that makes both legible.

🛂 Identity Is Not Authority

Enterprise identity infrastructure is mature at both ends of the principal spectrum. Human identity is well-served by decades of federation, authentication, and lifecycle controls. Workload identity is likewise mature, with services authenticating to each other using cryptographically verifiable identities that require no human in the loop.

When agents arrived, the natural response was to fit them into one of those two boxes. The first approach is impersonation, in which the agent authenticates as, or with a delegated token from, the user it is acting for. If the user has access, the agent acting as the user has access. The second approach is credential vaulting, which involves provisioning the agent as a non-human principal, vaulting and rotating its credentials, and managing its lifecycle through PAM and NHI tooling. Both approaches have real value. Both fail to reach the problem agents actually introduce.

Impersonation conflates identity with authority. The agent does not need to be the user. It needs a bounded mandate to act for the user, scoped to a specific purpose, revocable independently of the user’s credentials, and traceable as a distinct principal in audit logs. Impersonating the user gives the agent the full blast radius of the user’s identity with no representation of the mission that justified the delegation. Audit logs record the action as the user’s. The agent as a distinct accountable principal disappears from access reviews and entitlement audits.

Credential vaulting addresses a genuine vulnerability. Standing, unrotated credentials are a real risk. But it addresses the wrong layer. What the agent holds is not the problem. The problem is that the credential carries no connection to the purpose that justified issuing it. PAM and NHI controls govern the credential. Nothing governs the mission.

Neither model fits because agents combine properties that span both categories in ways neither was built to accommodate. They operate under delegated human authority, but the access layer records consent without the mission context that makes it meaningful. They discover resources dynamically, which makes pre-enumerated permissions either too restrictive to be useful or too broad to be safe. They chain across principals and trust domains, passing authority in ways the original grantor never explicitly authorized. And they must remain governable for the duration of a specific mission, not just at the moment a token was issued.

The question is not what kind of principal an agent is. It is what kind of execution model it requires.

👤 Why Treating Agents as Humans Fails

The first instinct is to provision agents as human users. That pattern is widespread across enterprise deployments. Cloud Security Alliance Non-Human Identity guidance documents service accounts managed with human-oriented controls across enterprise environments. It is also structurally wrong, and the failure mode reveals something important.

The human was not merely the subject of identity controls. The human was the governance layer those controls never had to model. A person authenticates, acts within the scope of their current intent, and stops when the task is done. Sessions terminate because humans close their laptops. Behavioral baselines calibrate to human-paced access patterns. Access reviews reflect what a person needs right now. The controls held not because they were particularly sophisticated, but because the human brought presence, pacing, and natural scope-limiting that the controls never had to formally represent.

Agents provide none of that. They do not stop when the mission ends. There is no closing-the-laptop signal for a completed task. Behavioral baselines calibrated to human access volumes generate constant noise or, worse, learn to ignore agent activity entirely, removing the last behavioral fallback. When an agent spawns sub-agents, access passes implicitly and in full with no concept of attenuation. Human identity systems were never designed for principals that chain. Provisioning an agent as a human transfers the entitlements without the presence, pacing, or accountability those controls were built around.

Agents remove that dependency and make the gap visible. A better human control does not close it. An explicit mandate does.

⚙️ Why Treating Agents as Workloads Fails

The workload model extends this instinct. Govern the agent’s credential lifecycle through PAM and NHI tooling, assign it a service identity such as a SPIFFE SVID, and enumerate its permissions in advance. It trades one set of assumptions for a different set of failures. Workload identity systems assume you know every system the workload will call before it runs.

Agents operate in open worlds. Given a destination rather than a track, an agent discovers tools, APIs, and data points that were unknown when the mission started. That creates a paradox: restrict it to pre-mapped resources and it cannot do the job it was built for. Give it broad credentials to navigate freely and the exposure scales with every action it takes.

You cannot rely on pre-authorization alone to solve an open-world problem.

And even when dynamic policy bridges the discovery gap by evaluating each newly discovered resource against context and purpose at request time, the agent still has no mission object. It knows what it is permitted to do. Nothing tells it when to stop. The discovery problem and the lifecycle problem are separate: solving the first does not solve the second.

Identity was designed to answer a different question. Authority requires a different primitive.

🔐 Access Is Not Authority

Modern security stacks have deep access-layer coverage. Identity providers, authorization servers, and resource servers govern whether an actor may cross a boundary and whether a request is permitted at that point. What happens after falls outside their scope, including how long execution runs, under what conditions, and whether it should continue.

Three structural gaps explain why tightening these controls does not resolve the problem:

• Access tokens capture access, not purpose. They determine whether a request is accepted at a boundary. They do not carry why execution was initiated or when it should end.
• Credential lifecycle is not mission lifecycle. Credential rotation and token refresh reset the credential clock. The mission clock does not reset with it.
• JIT governs credential windows, not mission state. JIT credentials and JIT privileges reduce standing exposure. The time window estimates how long the mission will run. When the mission ends before the window closes, or runs longer than expected, the mismatch is invisible to the access layer.

Every control in these sections asks whether a specific action is permitted right now. The gap agents expose asks something different. Should this execution still be running at all?

An Execution Mandate is stateful in a different dimension. It persists mission context across requests, token refreshes, service hops, and delegation chains. No combination of access-layer controls can answer a question that requires mission state, not because the question is unanswerable, but because answering it requires a component that holds mission state as a first-class artifact. No standard access-layer control is that component.

🪙 Access Tokens Capture Access, Not Purpose

An OAuth access token represents an authorization grant. It encodes what the client is permitted to do, on whose behalf, and for how long. Resource servers evaluate those claims (scopes, audience, subject, expiry) to decide whether a specific request may proceed. What access tokens do not carry is mission context. They record nothing about why the authorization was granted, what conditions must remain true throughout execution, or when it should end.

OAuth Rich Authorization Requests (RAR, RFC 9396) allow clients to send structured authorization details at request time, specifying not just scope=finance:read but a specific purpose (quarterly_financial_analysis), resource (finance/q3-2025), and authorizing principal (cfo@example.com). The authorization server can issue a token scoped precisely to that task. That is the intent-aware authorization the industry has been building toward, and it is meaningful progress. But RAR’s declaration is made once, at the moment of the request. It is not a living record of mission conditions across execution.

When a user authorizes an agent, OAuth records the grant: the agent’s client identity, the user’s identity, and the approved scopes. It captures that consent was given. It does not capture why.

Consider a code agent authorized to access a production database to investigate a reported incident. The grant records db:read on the engineer’s behalf. The incident is resolved and the ticket is closed. The grant still shows approval. Nothing in the authorization server knows the ticket was closed. The agent’s next request looks identical to its first: a valid client, an approved scope, a consenting user. The context that made the consent meaningful has no formal representation in the grant record.

Authorization servers can revoke tokens and invalidate grants, but revocation requires something to trigger it. A board meeting conclusion is not a system event. Short-lived credentials reduce reliance on explicit access revocation, and that is genuine value. Mission revocation is a different problem. It still requires an authoritative lifecycle owner that knows the mission ended and propagation semantics that reach every enforcement point. A shorter token window does not change what triggers it to close.

RAR, short-lived tokens, and CAEP can be composed to improve the picture, with intent declared at issuance, tokens expiring quickly, and risk signals triggering re-evaluation. That composition is often proposed as the solution. It is not. Composing components that each answer “is this request currently permitted?” does not produce a component that can answer “should this execution still be running?” RAR captures declared purpose at issuance but does not persist it. Short-lived tokens constrain the entry window but do not track why entry was granted. CAEP propagates signals when events fire but has no standard authoritative source of mission state to emit from.

Tokens enable request-scoped access decisions. Authority governs whether mission-scoped execution should continue.

🗝️ Credential Lifecycle Is Not Mission Lifecycle

PAM and NHI tooling is essential. It enforces Zero Standing Privileges, vaults secrets, governs non-human credential issuance, and rotates credentials on schedule. These controls manage the credential lifecycle. They govern when credentials exist, how long they last, and how they are refreshed.

But the credential lifecycle is not the mission lifecycle. A scheduled rotation fires at 3 AM. The agent now holds fresh credentials for a mission that was cancelled at 2 PM. The credential clock resets. The mission clock does not. PAM governs the credential precisely. Whether the purpose that justified provisioning it still holds is a different question entirely, and no part of the credential lifecycle owns it.

⏱️ JIT and Approval Flows Govern Access, Not Mission State

When practitioners encounter the mandate continuity problem, the instinct is often to reach for Just-In-Time provisioning or Human-in-the-Loop approval flows. Both reduce credential exposure. Neither tracks whether the mission behind those credentials is still active.

Approval flows assume a human-paced world. Agents operate at machine speed. A single agent can invoke dozens of tools per minute, each potentially warranting review under a strict gate model. The volume creates fatigue: reviewers either rubber-stamp requests or respond by broadening grants and reducing gate frequency, which reintroduces the standing access problem JIT was meant to solve. Even when approval flows work as intended, they address individual actions, not mission lifecycle. A human authorizing each tool call is not the same as a human governing whether the mission behind those calls should still be running.

JIT credentials and JIT privileges are distinct mechanisms that address different risks. JIT credentials, the PAM and vault pattern, control when a token or secret is issued, ensuring no standing credential exists when the agent is not active. JIT privileges, access activation patterns like Microsoft Entra ID Privileged Identity Management, control which permissions are elevated and for how long, ensuring elevated access is not permanently assigned. Both reduce standing risk. Neither governs whether delegated mission authority should continue after the context that justified it has changed.

Both are bounded by a time window estimated to match mission duration. That estimate is a proxy, not a measure. When a mission ends early, the window stays open. When it runs long, credentials refresh without re-authorizing the mission.

A time window is a proxy for mission duration, not a measure of it.

Behavior-bounded access models go further. Rather than a fixed window, trust becomes a consumable resource that depletes per action, with continuous intent scoring re-evaluating alignment before each request. That is a meaningful improvement over a timer. It is still not a mission clock. A trust budget depletes when actions are taken, not when the purpose that justified those actions has ended. A cancelled procurement program does not register as budget exhaustion. Behavioral monitoring can flag when an agent’s actions diverge from its declared objective. It cannot flag when that objective is no longer valid.

🔗 Delegation Is Not Authority

Getting identity right resolves who the agent is. Getting access right resolves what it may do at any given boundary. Neither addresses the handoff. The moment an agent delegates to another agent or spawns a sub-agent, the context established at the original grant does not travel with the authority. That loss of context at the handoff is the delegation problem.

The mandate addresses this failure across two distinct dimensions. Mission authority asks whether the purpose and conditions that justified the original grant still hold. Delegation authority asks whether the chain from the current agent to the originating human grant is intact and unattenuated. They fail independently. A structurally valid chain can carry a mission that has already lapsed, and a valid mission can be served by a chain whose originating principal has changed. The three gaps below are delegation authority failures.

Standard OAuth delegation defines the first-hop mechanism: a principal authorizes an agent, an authorization server records consent, and a scoped token governs what the agent may do on the principal’s behalf. That establishes what is permitted, not why the grant was made or when authority should end.

The problem compounds the moment that agent delegates further. Orchestrators spawn sub-agents that invoke tools and call APIs, which delegate to other agents in turn. Authority flows through chains the original principal never explicitly contemplated. In any well-governed delegation model, sub-delegation requires explicit authorization in the original grant: a delegate cannot further delegate absent that, and a grant of authority does not automatically carry the right to extend it.

Three structural gaps explain why current systems cannot govern these chains:

• Scope amplifies without attenuation. Authority passes implicitly at each hop. Even where hierarchical token chains and depth limits constrain chain length, they govern privilege inheritance, not mission scope at each hop. A sub-agent may access more than the mission that justified the original grant.
• Authority chains lack standardized traceability. There is no standardized way to verify that authority in a chain traces back to an explicit human grant. If the trace breaks, no system can see it.
• Context is not re-evaluated at each hop. Each delegation point passes authority based on the conditions at the original grant, not current context. The purpose may no longer justify extending it.

🔊 Scope Amplifies Without Attenuation

When a sub-agent is spawned without mandate context, it operates under its own service role and defaults. It has no knowledge of why it was invoked, what purpose the originating mandate was serving, or what conditions must remain true. It cannot enforce what it cannot see.

Hierarchical delegation-token chains with depth limits exist in some frameworks. Even with those controls, the model delegates privileges, not mission intent or execution legitimacy. Cross-system enforcement is difficult because attenuation semantics are not standardized across orchestrators, tools, and trust domains.

Token Exchange (RFC 8693) is the closest existing mechanism for propagating delegated authority across service boundaries. A client presents a token to an authorization server and receives a new one, scoped for a downstream service, with an act claim recording who is acting on whose behalf. The act claim is an advisory record of the delegation chain, not an enforced constraint on what that chain may do or how long it may run. Each exchange is a bilateral transaction between one client and one authorization server. Token Exchange moves authority across a boundary. It does not govern whether that authority should still exist.

A sub-agent can only receive authority equal to or less than what the delegating agent holds. You cannot delegate what you do not have. With that constraint enforced, the sub-agent cannot reach resources outside the parent mandate’s scope.

Without enforced attenuation, every delegation hop is a potential amplification point.

🔍 Authority Chains Don’t Trace Back

Without standardized traceability requirements, each additional hop adds a link that no audit log can reconstruct. From the final service’s perspective, a request arrived from an authenticated agent with valid credentials. The delegation has no memory of where it started.

The problem has a direct analogy in software supply chain security. SLSA (Supply Chain Levels for Software Artifacts) defines provenance requirements so a build artifact can be traced back through its pipeline to a trusted source, with each step attesting to what it received and what it produced. An authority chain has exactly the same requirement. A mandate trace from the current agent to the originating human grant is the identity equivalent of SLSA provenance: every delegation hop attests to the authority it received and what it passed forward. Valid credentials tell you the current agent is authenticated. They do not tell you whether any human authorized the chain of execution that produced it.

Authority in any chain must trace back to an explicit human grant. If the trace breaks, the delegation is invalid. South et al. (2025) address this requirement directly, proposing cryptographic attestation at each delegation hop to make the chain from sub-agent to originating human grant verifiable without trusting intermediate links to have enforced it.

A delegation chain with no traceable human grant is not governance. It is inherited trust.

🔄 Context Doesn’t Travel With Authority

At every delegation point, authority passes based on the conditions that existed at the original grant. The question each hop should ask is not only what authority do I hold? It is does the original purpose still justify extending this authority, to this actor, right now? Short-lived credentials and scoped permissions do not encode any of this. Each delegation decision should reflect current conditions, not those that existed when the original mandate was issued.

Without context re-evaluation, revocation does not cascade. When Agent A’s mandate expires or is revoked, Agent B’s authority continues. The chain outlives its origin. With context re-evaluation enforced, Agent B’s authority terminates when Agent A’s mandate expires. Short-lived credentials limit how long a window stays open. Context re-evaluation ensures authority cannot outlive the purpose that justified it.

Consider the failure in full. A procurement officer delegates a vendor sourcing task to Agent A. Agent A calls a third-party vendor-analysis service, which delegates to Procurement Agent B to retrieve supplier risk scores. The CFO then puts the sourcing program on hold. Agent A’s mandate should expire. Agent B has no visibility into Agent A’s mandate or the condition that ended it. The vendor-analysis service has no knowledge the program was paused. Agent B continues pulling supplier risk scores, authorized at every access layer, acting on a mandate whose originating purpose no longer holds. Each hop amplified scope. Each hop lost a piece of the trace. Each hop passed authority based on conditions that no longer existed.

Delegation without attenuation, traceability, and context re-evaluation is not governance. It is accidental trust propagation.

The gap is not in your controls. The gap is in what your controls were built to govern. Identity, access, and delegation each answer their question correctly, and none of their questions is the one agents expose.

Closing it requires a control that holds four properties as a persistent, independently revocable artifact. The purpose for which authority was granted. The conditions under which it remains valid. The lifecycle events that end it. And the provenance tracing it back to a human decision. Identity establishes who, not why. Access governs the request, not the mission. Delegation carries authority forward but holds no record of the mission that justified it or the conditions under which it should terminate. None of the three owns all four properties. The missing layer must exist as a distinct first-class artifact, not as an extension of any existing one.

We have been building better passports. What agents need is Power of Attorney. That is the artifact the next post defines.