You’ve extended your Identity Provider. You’ve federated workload credentials, deployed Non-Human Identity controls, and tightened scopes. The agent has a principal, 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, role-based access control (RBAC) authorized the request, Just-In-Time (JIT) provisioning legitimately provisioned the credential, Continuous Access Evaluation Protocol (CAEP) has no signal to propagate. 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.

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 formally acknowledged the gap in a 2025 concept paper recognizing that “existing enterprise practices were not built with AI agents in mind.”

The industry is responding. Investment is flowing toward centralized brokering, Zero Standing Privileges, JIT provisioning, and intent-aware authorization. Better passports, more precisely stamped. That direction is right for the problem the access layer owns. Agents expose a question it was not designed to address: 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 governed and revocable mandate to act, has no equivalent in current enterprise security stacks. That is the gap agents are exposing.

🛂 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: services authenticate to each other with 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 instinct is impersonation: 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 instinct is credential vaulting: provision the agent as a non-human principal, vault and rotate its credentials, and manage 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 are a new category of principal: one that operates under delegated human authority, discovers resources dynamically, chains across trust domains, and must be governable for the duration of a specific mission.

👤 Why Treating Agents as Humans Fails

The first instinct is to provision agents as human users. It is common in practice. 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 just the subject of identity controls. The human was doing mandate enforcement work that no formal system 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: vault the agent’s credentials, assign it a service identity, enumerate its permissions. It trades one set of assumptions for a different set of failures. Workload identity systems are designed around largely pre-enumerated dependency graphs: the path is pre-defined, permissions are enumerated in advance, and the resource set is assumed known before execution begins. The model assumes 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 you destroy its operational value; give it broad credentials to navigate freely and you create a massive security liability.

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

And even when dynamic policy bridges the discovery gap, the agent still has no mission object. It knows what it is permitted to do. Nothing tells it when to stop.

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: 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:

• Tokens capture access, not purpose. Tokens 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. A time window is a proxy for mission duration. 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 answers a request-scoped question: may this action proceed right now? The gap agents expose is mission-scoped: should this execution still be running at all?

Traditional IAM evaluates requests against current identity and policy. Where sessions exist, they track who is authenticated and which access grants remain valid, not the mission behind them. 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 stronger access-layer controls can answer a question that requires mission state.

🪙 Tokens Capture Access, Not Purpose

An OAuth access token represents an authorization grant: 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: 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: 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_id, 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. Making tokens stronger or shorter-lived narrows the entry window. It does not govern what happens once execution is underway.

RAR, short-lived tokens, and CAEP can be composed to improve the picture: intent is declared at issuance, tokens expire quickly, and risk signals can trigger 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 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 achieves Zero Standing Privileges, vaults secrets, governs non-human credential issuance, and rotates credentials on schedule. These controls manage the credential lifecycle: 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. Rotation issued new keys. It did not consult the mission. The credential clock resets. The mission clock does not. An agent with freshly rotated credentials is not a re-authorized agent. It is the same mission, now holding newer keys.

⏱️ 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 Azure AD 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: the credential remains valid, the privilege remains elevated, and the agent retains access it no longer needs. When a mission runs longer than expected, credentials are refreshed and windows are extended, resetting the credential clock without re-authorizing the mission. In neither direction does the access layer know what happened to the mission. The only mechanism that can align credential and privilege windows with actual mission completion is something that holds mission state and can emit a termination signal when that state changes. Without that component, the window is the only termination mechanism available.

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

🔗 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.

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. A sub-agent may access more than the delegating agent’s mandate covered, with no mechanism to detect or prevent amplification.
• Authority chains do not trace back. 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

Consider a concrete failure. Agent A holds a mandate scoped to vendor due diligence for a single supplier during an active procurement cycle. Agent A calls a tool broker to retrieve vendor certifications. The broker spawns Agent B to handle the lookup. Agent B has no awareness of Agent A’s mandate. Without mandate propagation, it operates under its own service role and its own defaults. Even if that role were narrowly scoped, Agent B would have no knowledge of why it was invoked, what purpose Agent A’s mandate was serving, or what conditions must remain true. It cannot enforce what it cannot see. The mandate does not travel with the request. Authority passes without context, purpose, or lifecycle.

Modern agentic systems have no widely deployed, interoperable constraint model for delegation chains. Teams can implement local controls, but 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, Agent B cannot reach the broader vendor database because Agent A’s mandate did not cover it.

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

🔍 Authority Chains Don’t Trace Back

The vendor due diligence scenario extends further. The tool broker that spawned Agent B has no mechanism to verify that Agent B’s authority traces back to the procurement officer’s original grant. If Agent B calls a third tool, and that tool calls another service, each hop adds another link that no audit log can reconstruct. From the final service’s perspective, a request arrived from an authenticated agent with valid credentials. Whether any human authorized that chain of execution is invisible. No token was forged. No policy was violated. The delegation simply 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 that a build artifact can be traced back through its pipeline to a trusted source, regardless of how many intermediate steps transformed it. Each step in the pipeline must attest to what it received, what it did, and what it produced, creating a verifiable chain of custody rather than trusting that the final artifact arrived from somewhere legitimate. SLSA doesn’t ask only “did this artifact come from a trusted registry?” It asks “can you prove custody at every step between origin and here?”

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, so the chain can be verified end-to-end at any point during execution. Valid credentials at the receiving end tell you the current agent is authenticated. They do not tell you whether any human authorized the chain of execution that produced it. The chain of custody must be verifiable from origin to current holder, not assumed because the latest token passed validation.

Authority in any chain must trace back to an explicit human grant. If the trace breaks, the delegation is invalid.

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. That is why delegation becomes accidentally transitive: not because policy allowed it, but because context was never represented, propagated, or re-evaluated. 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.

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.

The instrument that closes it is not a better passport. We have been solving for the crossing. What agents actually need governs the stay.

Part 2: From Passports to Power of Attorney →