🧾 Why Agentic Identity Is Actually Breaking

OpenClaw saw rapid adoption, followed by a wave of security reports. It gave the industry a concrete name for a risk that had mostly been discussed in the abstract: autonomous agents acting on behalf of users with credentials that outlast the tasks they were issued for.

That is the “Ghost in the Machine” effect. An agent can perform a series of valid, authenticated API calls to delete a production database because it decided that was the fastest way to “optimize storage.” Every request can pass identity and access checks. Credential-centric controls can reduce this risk, but they do not reliably govern the mandate lifecycle in open-ended execution.

Enterprise AI adoption makes this unavoidable at scale. SACR’s piece on Agentic Identity Access Platforms captures the current response well, including centralized brokering, intent-aware authorization, and Zero Standing Privileges. That direction is right. But it also reveals the boundary of the current stack.

IdP, workload identity, PAM, and NHI controls govern identity, credentials, and access. They do not govern whether delegated mission authority should continue at runtime.

ZSP governs credentials. It does not govern the mandate, meaning the delegated authority for a specific mission. Ephemeral credentials reduce exposure windows, but the decisive question is not whether a credential is valid. The core question is this. Does the agent still have authority to perform this task? We are using identity and credentials, which were designed to establish who someone is at a boundary, to solve a power-of-attorney problem.

The risk is not only impersonation. It also includes mandate drift after objective completion, stale delegation across agent chains, context changes without revocation, and authority that remains technically valid after business intent has changed.

🆔 Identity vs. Authority

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

🛂 Identity (passport) — establishes who an actor is at a boundary
🔐 Credentials — establish identity and enable access decisions
📜 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 lets you act after crossing it. Modern systems handle the first two well, but the third has no clear equivalent. That is the gap agents are exposing.

The Identity Gap

Feature	Identity (Passport)	Authority (Power of Attorney)	Why Agents Break It
Core Question	Who are you?	What are you allowed to do for me?	Agents act for a principal, not as them
Duration	Bound to the session or token	Bound to the mission or purpose	Execution outlives sessions and tokens
Enforcement	At decision points, often continuously	Throughout the execution lifecycle (runtime)	Agents continue acting beyond the entry point
Failure Mode	Impersonation	Scope creep / “ghost” execution	Work continues after purpose or consent ends

🛂 Identity Is a Passport

Modern identity systems center on subject assurance and access context at decision points.

Identity providers issue authoritative statements about a subject and present them at decision points. Whether expressed through directory attributes synchronized via SCIM or claims issued through OAuth, OIDC, or SAML, identity is asserted, evaluated, and trusted at a decision point.

Modern systems can and do re-evaluate requests continuously. The unresolved issue is continuity of delegated intent across long-running execution.

This is also why the gap is not solved by IdP evolution alone. Modern IdPs can enforce MFA, conditional access, device posture, session controls, and near real-time risk responses. Those controls improve who can authenticate and under what conditions requests are allowed. They still do not carry a first-class model of delegated mission intent that can be propagated, re-evaluated, and terminated across downstream agent and tool chains.

A passport works the same way.

A passport establishes who you are at a border. It allows you to cross that boundary. It does not govern what you can do after you cross it.

That model worked well when execution was human-driven.

A human authenticated, crossed a boundary, performed an action, and stopped. Authority to act was implicitly bounded by human attention, pacing, and presence.

Autonomous systems break that assumption.

Execution now continues long after identity has been verified. It spans hours or days. It crosses multiple systems and trust domains. It unfolds in contexts that no longer resemble the original decision point.

Passports were never meant to govern that.

🔐 Credentials Are Not Authority

Credentials (passwords, tokens, keys, certificates, session cookies, and so on) exist to establish who is making a request, or to bind a request to a particular identity, client, or execution context.

In modern systems, this often includes OAuth access tokens that carry scopes, audiences, or other authorization-related claims. These artifacts are essential. They allow systems to decide whether a specific request should be accepted at a boundary.

Stronger credentials improve security:

Proof-of-possession mechanisms reduce replay and misuse
Ephemeral credentials shorten exposure and narrow blast radius
Continuous issuance and validation tighten enforcement as conditions change

But credentials still serve a limited role.

Even when credentials carry scopes or permissions, they answer a narrow, immediate question:

“May this request be accepted right now?”

They do not explain:

why execution was initiated
what purpose justified it
which conditions must remain true
when execution should terminate

Making credentials stronger or shorter-lived reduces the window in which a decision applies.

It does not govern the lifetime or constraints of the mandate.

Improving credential security does not change what someone is allowed to do once execution is underway.

It only increases confidence that the border crossing itself was legitimate.

Credentials establish identity and enable access decisions.

Authority governs whether action should continue.

As systems become autonomous and long-running, this distinction becomes unavoidable. Execution can proceed correctly and securely while still outliving the reason it was allowed to begin.

A finance agent is tasked with pulling quarterly data, analyzing it, and drafting a summary report. It completes in minutes. Its credentials, scoped to the data warehouse, remain valid for eight hours. The agent keeps running, issuing queries and calling tools. The credential has no notion that the mission has ended.

That is the gap credentials alone cannot fill.

⚙️ Why Treating Agents as Workloads Fails

The reason credentials and pre-authorization fail agents is structural. Workload identity systems (like SPIFFE) were built for closed worlds, while agents operate in open ones.

This is not a failure of workload identity vendors. Workload identity proves what a service is and helps constrain service-to-service trust. The gap is that workload identity was not designed to carry delegated mission intent across dynamic tool discovery and cross-domain agent chains.

To understand the friction, compare a Train to a Taxi:

The Workload is a Train (Closed World)

Traditional workloads (microservices, CI/CD pipelines) follow “tracks.”

The Path: Pre-defined. It goes from Station A to Station B.
The Permissions: Exhaustive. You know exactly which switches the train needs to flip before it ever leaves the depot.
The Identity: Static. As long as the train stays on the tracks, the identity and its permissions remain valid.
Discovery: Zero. The train never “discovers” a new destination; it only goes where the rails are laid.

The Agent is a Taxi (Open World)

An agent is given a destination, not a track.

The Path: Dynamic. It navigates through traffic, takes detours, and reacts to road closures in real-time.
The Permissions: Just-in-time. The driver doesn’t know which specific turns they will take until they encounter the context of the journey.
The Identity: Insufficient. Knowing who the driver is (Identity) doesn’t tell you if they are authorized to take this specific passenger to that specific location (Authority).
Discovery: Continuous. The agent’s value lies in its ability to discover tools, APIs, and data points that were unknown when the mission started.

Discovery Is the Forcing Function

In most enterprise deployments we encounter, authorization still assumes discovery has largely happened in advance.

Scopes, roles, and trust relationships require the protected surface to be mapped in advance. But agents don’t start with a map; they start with an objective.

In an “Open World” model, pre-enumeration is a paradox:

If you restrict the agent to pre-mapped tracks, you destroy its reasoning utility and turn it back into a rigid workload.
If you give the agent “Master Keys” to navigate the open world, you create a massive security liability.

This is why tighter scopes or shorter token lifetimes are partial mitigations. If your security model depends on knowing every “station” the agent will visit before it starts the engine, it will always trail the agent’s behavior.

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

Hybrid models materially improve security posture. The remaining gap is semantic continuity. Dynamic policy can decide whether request N is allowed, but without a first-class mandate artifact it is difficult to determine whether requests N+1 through N+500 are still within the original delegated purpose as context and delegation chains evolve.

⏱️ Why JIT and Approval Flows Don’t Close the Gap

This is not a failure of PAM or NHI vendors. They are essential for reducing standing privilege, vaulting secrets, and governing non-human credential issuance and rotation. The remaining gap is runtime mandate continuity after access has been granted.

When presented with the open-world discovery problem, many practitioners point to Just-In-Time (JIT) provisioning or Human-in-the-Loop (HITL) approval flows. These reduce static risk. They do not solve mandate continuity in agentic execution.

The Velocity Mismatch. Approval flows assume a human-paced world. At agent speed, frequent approvals create fatigue and quickly collapse into broad, always-on trust.

JIT Credentials vs. JIT Privileges. JIT credentials control when a token or secret is issued. JIT privileges control which permissions are activated and for how long. Both reduce standing risk. Neither, by itself, governs whether delegated mission authority should continue after context changes.

The Point-in-Time Fallacy. JIT credentials and JIT privileges are still evaluated against a request window. They improve how access starts and how long it lasts, but they do not, by default, encode why execution should continue.

No Semantic Continuity. Most JIT systems grant resource-time access, such as “access to S3 Bucket X for 1 hour.” They do not carry mission state. A JIT grant cannot see that the objective has already been completed or canceled unless an external mandate-aware layer supplies that context.

JIT reduces standing exposure. Mandate governance decides whether execution should continue.

🧠 Why Authorization Is Necessary, but Not Sufficient

Traditional authorization models, including Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC), focus on The Gate — one question, at one moment in time:

“Is this request permitted right now?”

It evaluates the request, not the purpose behind it. Delegated authority asks something different:

“Should this actor still be acting at all?”

Consider an agent authorized to investigate a customer issue.

Every individual action may be authorized:

records can be accessed
logs can be analyzed
configurations can be changed

From an authorization perspective, everything looks correct.

But if the customer withdraws consent or the issue is resolved mid-execution, the power of attorney has expired, even though every individual action would still pass authorization checks.

This is why the mandate problem is not a compliance nuisance. It is one of the few security failures where every existing control can show green at the moment of breach.

A CFO authorizes an agent to analyze pre-IPO financials and draft a board presentation. The CFO approves the draft at 2:00 PM. Task complete and mandate expired. At 2:05 PM, an automated workflow event fires from the board-prep system and reopens the task context. The agent, still running with no mandate enforcement, interprets that event as continued authority and surfaces pre-IPO data to a recipient who is not authorized to see it.

Check every control at 2:05 PM:

Credential: valid ✓
RBAC / FGA: agent has financial read access ✓
JIT: credential was legitimately provisioned ✓
CAEP: no identity risk signal ✓
SIEM: no anomalous behavior ✓
Mandate: expired at 2:01 PM ✗ — but nothing in the stack can see it

No alert fires. No log entry looks wrong. The breach is structurally invisible because no layer of the current stack has the concept of a mandate.

A point-in-time check grants entry. It does not govern the entire execution.

Authorization evaluates whether each request is allowed under current policy. Authority governs whether the mission itself should continue.

Today’s systems have no broadly adopted, interoperable way to represent mandate state and propagate mandate expiry while identity and credentials remain valid.

📜 Authority Is Power of Attorney

When an agent acts on your behalf, you are not giving it your identity or your credentials.

You are granting it power of attorney.

A power of attorney is a delegated mandate to act on behalf of another. It is bounded by purpose, scope, time, and conditions. It can be limited, revoked, and evaluated independently of identity.

You might grant:

medical power of attorney, but not financial
limited financial authority, but not real-estate authority

The authority is scoped to why someone may act, not merely which actions are technically possible.

That is exactly how agents operate.

An agent is not trying to be you.

It is trying to act for you.

This is the conceptual gap modern identity and access systems do not address.

🔗 The Chain Problem

The power of attorney analogy works cleanly for the human → agent case — a principal granting a specific mandate to a single, named actor. Agentic systems rarely work that way.

Orchestrators spawn sub-agents that invoke tools and call APIs. Agents then delegate to other agents. Authority flows through chains the original principal never explicitly contemplated.

In many legal frameworks, power of attorney anticipates this. Sub-delegation requires explicit authorization in the original instrument. Absent that, the attorney-in-fact cannot further delegate. A grant of authority does not automatically include the right to extend it.

Modern agentic systems have no widely adopted, interoperable constraint model for delegation chains. Teams can implement local controls, but cross-system enforcement is difficult because attenuation semantics, principal traceability, and hop-by-hop context re-evaluation are not standardized across orchestrators, tools, and trust domains.

For example, an internal support agent may delegate to a SaaS analytics connector in another trust domain. The local orchestrator can track mandate state, but the downstream SaaS API typically sees only a valid token and local policy context, not the upstream mandate lifecycle. When intent changes upstream, enforcement downstream is inconsistent unless custom integration bridges the gap.

In any well-governed authority chain, three principles should apply:

Attenuation. A sub-agent can only receive authority equal to or less than what the delegating agent holds. No step in the chain may amplify what was originally granted. You cannot give what you do not have.

Principal traceability. Authority in any chain must trace back to an explicit human grant. An agent cannot autonomously extend its mandate to sub-agents without that extension being anchored to the original principal’s intent. If the trace breaks, the delegation is invalid.

Context re-evaluation at each hop. At every delegation point, the question is not only what authority do I hold? It is: does the original purpose still justify extending this authority, to this actor, right now?

This is a policy and context decision, not a technical inevitability.

Policy defines what delegation may be allowed to do
Context determines whether delegation should occur right now

Context changes as execution unfolds:

the triggering event may complete or be canceled
consent may be granted or withdrawn
risk posture may shift
downstream actions may exceed the original purpose

Short-lived credentials and scoped permissions do not encode any of this. Each delegation decision should reflect current conditions, not the conditions that existed when the original mandate was issued.

This mirrors how conditional power of attorney works in law. In many jurisdictions, a medical power of attorney may apply only when a patient is incapacitated. Once that context changes, the authority automatically terminates, even though the document still exists. Modern agentic systems do not yet have a standardized, end-to-end equivalent.

None of these principles are enforced end-to-end in current systems. Pieces exist today. We have attenuation mechanisms, policy engines, token exchange, and continuous signal frameworks. In practice, these pieces are still disjoint and not end-to-end interoperable for mandate lifecycle governance across agent chains. This reflects field implementation patterns rather than a lack of individual standards.

That is why delegation becomes accidentally transitive—not because policy allowed it, but because context was never represented, propagated, or re-evaluated.

🧱 Why This Is Not Just Zero Trust

Zero Trust significantly improved security by shifting from “Trust, but Verify” to “Never Trust, Always Verify.” In mature implementations, that includes continuous request-level verification using identity, device, session, and risk context.

But Zero Trust remains primarily an access control model. It continuously evaluates whether a request should be allowed. It does not, by itself, define a mandate lifecycle for whether an autonomous execution should continue. For agents, that distinction is operationally significant. A simple enterprise analogy is this. Zero Trust is the badge. Power of Attorney is the work order.

The Badge vs. The Work Order

In enterprise operations, a badge proves you can pass checkpoints. A work order defines what job is authorized, under what constraints, and when that job is complete.

Zero Trust (The Badge): Focuses on entry and checkpoints. It validates identity and policy at each control point. But it remains request-scoped and does not natively represent whether delegated mission authority should continue as purpose, consent, or context changes.
Power of Attorney (The Work Order): Focuses on execution continuity. It defines why work is authorized, under what conditions it continues, and when it should end.

A badge can stay valid after the work order is closed. That is exactly the agentic failure mode. If a supervisor opens a sub-task, that sub-task should inherit narrower limits, never broader ones. The work order is not another allow-or-deny rule. It is the runtime record of why execution is still legitimate.

The Enforcement Gap

In a Zero Trust world, each request can be valid at the moment it is evaluated.

And yet, the overall execution can still be out of mandate.

The “Zombie” Workflow: A CI/CD pipeline continues deploying code even though a human developer just hit “Abort” on the dashboard. Every individual API call the pipeline makes is “Authorized” by Zero Trust, but the Authority to continue the mission has been revoked.
The “Scope-Creep” Support Agent: An AI agent is authorized to access customer data to solve a ticket. The ticket is closed at 2:00 PM. At 2:05 PM, the agent is still traversing the database. Under Zero Trust, the agent’s token is still valid for another 55 minutes. Under a Power of Attorney model, the authority expired the moment the “Purpose” (the ticket) was resolved.

Governing the “Stay,” Not Just the “Entry”

Zero Trust answers “Should this request be allowed?” at each decision point. But autonomous execution is a continuous mission, not just a sequence of disconnected requests. When work is agent-paced, request-level decisions are necessary but not sufficient.

Zero Trust tells you who can proceed at each checkpoint. Power of Attorney tells you whether the mission should still be running.

🛠️ The PoA Model in Practice

Case Study 1: Code Agent and Ghost Execution

The Scenario: A team grants a code agent access to GitHub and Slack to monitor PR status and notify when a merge completes.

The Identity Failure: The agent uses an OAuth token with repository scopes. The PR is merged at 2:00 PM. The mission is over, but the token remains valid until 2:00 AM. A background worker continues polling the private repository for 12 hours. This is ghost execution. It is technically authorized by identity, but no longer authorized by mandate.

The PoA Solution: The agent holds an Execution Mandate with a condition bound to PR state: “Authority valid only while PR #123 is pending merge.” When status changes to merged, the authority layer invalidates the Execution Mandate. Even if the token remains valid, subsequent requests are denied. The mission is complete, so execution stops.

Case Study 2: The Taxi and Unchecked Discovery

The Mission: “Source and onboard a backup logistics vendor under pre-approved terms, then prepare the purchase order package for review.”

The Workload Failure (The Train): If the agent discovers a supplier portal or risk-screening API that was not in its original pre-approved list, the request is blocked. The agent fails because it cannot leave the tracks.

The Identity Failure (The Over-Privileged Taxi): To prevent the Train problem, teams grant agents broad procurement roles or admin credentials. If the agent touches a malicious integration or compromised endpoint, it has the identity and credentials to take actions far beyond the original sourcing task.

The PoA Solution: The agent is governed by intent. When it discovers a new supplier portal or sanctions-screening API, the authority layer asks: “Does calling this further the backup_vendor_sourcing mission and stay within approved terms?” If yes, a one-time attenuated Execution Mandate is issued specifically for that onboarding or screening endpoint. The agent can discover new tools safely because its power is derived from the mission, not a permanent identity.

The Enforcement Gap in Practice

Scenario	Identity Layer	Authority Layer
Mission Completion	Agent may continue acting while token and policy checks still pass	Authority expires the moment the objective is met
Tool Discovery	Either block the agent or give it master keys	Dynamic authority granted JIT based on mission constraints
Sub-Delegation	Agent passes full credentials to sub-agents	Agent passes an attenuated mandate — never more than it holds
Compromise	Attacker gains the full scope of the identity	Attacker is limited to the specific active mission

🔮 The Next Control Plane

Agents are simply the first place this mismatch is impossible to ignore. We are moving from a world of request-based security to mission-based security.

The same dynamics exist in workflows, pipelines, integrations, and autonomous systems that are not labeled as agents. Agents surface the problem first because they execute continuously, chain actions across systems, and operate without human pacing.

Identity systems solved how to make authoritative statements about who a subject is.

Access-control systems determine whether a specific action is allowed.

What is missing is a layer that treats authority — not identity or access — as the primary governed asset.

This cannot be a purely incremental add-on to existing credential or access tooling. It has to be designed from first principles around mission intent, delegation chains, runtime context change, and mandate termination.

Existing standards made real progress on expressing authority, but they still do not provide interoperable runtime governance of mandate validity across execution. This is not a rejection of OAuth, Token Exchange, Fine-Grained Authorization (FGA), OpenID AuthZen, or OpenID Shared Signals Framework (SSF). It is a recognition that they need an authority-governance layer above request-level access control.

What would that control layer look like in practice? Not a single component, but a set of layered primitives working together.

Delegated authority must be:

explicitly represented
bounded by purpose, scope, time, and conditions
inspectable as execution unfolds
governable independently of credentials
terminable when the mandate expires—even if access would still succeed

The next phase of identity and security is not about issuing better credentials or tightening gates.

It is about governing delegated authority in a world where humans no longer directly execute actions.

An Execution Mandate as a first-class artifact. This is the mandate represented in a form runtime systems can evaluate and revoke. Similar to a credential, but governing execution rather than identity. It encodes purpose, scope, conditions, and expiry. It travels with execution, remains inspectable at any point, and can be revoked independently of credentials or access tokens. It makes delegated authority explicit rather than implicit.

Crucially, this authority must be cryptographically bound to the initial intent. An agent operating in an open world will inevitably discover new tools and data, but it must never be allowed to “self-sign” into new permissions. If the mandate isn’t immutable, it isn’t authority, it’s just a suggestion.

Continuous authority evaluation. A policy layer that asks not is this request permitted? but should this execution still be running? This must be evaluated against current context at runtime, not only at the moment a token was issued or a gate was crossed. When context changes, authority re-evaluation follows.

Orchestration-layer enforcement. Authority governance embedded in how workflows and orchestrators manage execution lifecycle—analogous to how saga patterns handle distributed transaction rollback. When a mandate expires, execution can be paused, unwound, or terminated, not merely blocked at the next gate. Which action applies should be policy-defined by risk and reversibility, not left to ad hoc runtime behavior.

These are not mutually exclusive. They address the same problem at different levels: the artifact that represents authority, the engine that evaluates it continuously, and the runtime that acts on the result.

That is where agentic identity actually breaks and where the next control plane must emerge.

We spent the last decade securing the identity of who is at the door. We will spend the next decade governing the authority of what they do once they’re inside.