This is Part 2 of a four-part series. Part 1 established why identity, access, and delegation controls cannot govern whether a mission should still be running. What follows demonstrates that gap concretely, then names the instrument that closes it.
Identity, access, and delegation controls govern the crossing. Agents expose the stay.
Identity controls verify who arrives: they establish a cryptographic principal, confirm the claim is legitimate, and issue the token that carries it. Access controls determine what entry permits: they evaluate whether a specific request is allowed under current policy, checking identity claims and resource permissions at the moment the call is made. Delegation controls record who may act for whom: they capture the consent that authorized one principal to act for another and encode the scope of that grant. Each answers its question correctly. None of their questions is whether the mission behind those requests should still be running.
The solution is not a better passport. It is the document you give someone when you need them to act on your behalf, bounded by purpose, scope, and a clear end.
⚠️ The Enforcement Gap
Identity, access, and delegation controls each answer their question correctly. None of their questions is: should this execution still be running? The structural reason is architectural: current enforcement sits at Policy Decision Points (PDPs): components that evaluate each request against identity claims and resource policy. PDPs evaluate the request in front of them, not the mission behind it. No standard PDP receives mandate context, because no upstream component holds mission state to provide.
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 is the badge. Power of Attorney is the work order.
The badge can stay valid after the work order is closed. Zero Trust re-evaluates every request against current identity and policy. That continuous verification is architecturally request-scoped. It has no concept of the mission behind the requests. The same failure appears in any scenario where a business event terminates the mandate but generates no IAM signal:
- The “Failed Acquisition”: Company A’s due diligence agent continues analyzing Company B’s confidential supplier contracts over the weekend after Company B’s board votes Friday evening to terminate discussions. The token is valid. The scope is authorized. No anomalous behavior is detected. A board vote is not an IAM event. Nothing in the stack can see it.
- The “Renewal Declined”: A customer success agent continues pulling behavioral telemetry and support history after the customer declines renewal and the AE closes the Salesforce opportunity. The token is valid. The scopes are unchanged. A Salesforce note is not an IAM event. Nothing in the stack can see it.
Authorization is a decision mechanism. Role-based access control (RBAC), attribute-based access control (ABAC), policy-based access control (PBAC), and relationship-based access control (ReBAC) evaluate whether a specific request is permitted under current policy. They can encode context and purpose attributes. But each decision is local to a single request. The question they cannot ask is: “Should this actor still be acting at all?”
Consider a CFO who authorizes a research agent to access pre-IPO financial data to analyze board exposure and prepare a presentation. The board approves the draft at 2:00 PM. The mission is complete. Check every control five minutes later:
- Token: valid ✓
- RBAC / fine-grained authorization (FGA): agent has financial read access ✓
- Just-In-Time (JIT): credential was legitimately provisioned ✓
- Shared Signals Framework (SSF)/Continuous Access Evaluation Protocol (CAEP): no identity risk event to propagate ✓
- Security Information and Event Management (SIEM): no anomalous behavior ✓
- Mandate: expired at 2:01 PM ✗. 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.
This is one of the few security failures where every identity and authorization control can show green at the moment of breach.
The breach also leaves a clean audit trail. Every request was authorized. Every control showed green. Post-incident, the access logs contain no evidence of what the agent’s mission was, when it was supposed to end, or which actions exceeded it. The failure is invisible not just at the moment it occurs but in the reconstruction.
A mandate record changes this. Every action executed under a mandate is attributed to a specific delegated purpose, the grant that authorized it, and the agent instance that executed it. Mandate expiry is a first-class event in the audit log. An investigator can ask: was this action taken while the mandate was valid, or after it expired? That question has no answer in today’s access logs. It is the difference between a record of what happened and a record of what was authorized to happen. Those two things diverge the moment a mission ends and the agent keeps running.
CAEP can propagate mandate-expiry signals once a signal type is defined and adopted. The harder problem is upstream: no component in the current stack owns mission state. Without an authoritative source, there is nothing to propagate, nothing to query, and no signal for the rest of the stack to act on. Business context changes without generating anything a signal framework could observe.
The composability instinct (combine RAR for declared intent, CAEP for propagation, OPA for per-request evaluation) does not resolve this. Each component answers a question about the current request. None of them owns mission state. Composing tools that each lack an authoritative source of mission state does not produce one. The gap is not a missing enforcement mechanism. It is a missing state owner.
The gap manifests across every dimension of agentic execution:
| Failure Mode | Current Stack | With a Mandate Layer |
|---|---|---|
| Mission Completion | Agent continues acting while token and policy checks pass | Authority expires when the objective is met, independently of token validity |
| Tool Discovery | Either block the agent or grant broad credentials | Scoped, one-time authority derived from the active mission |
| 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 agent’s credentials | Attacker is constrained to the active mission’s scope |
📜 Authority Is Power of Attorney
We have been issuing passports. The right instrument has always been Power of Attorney.
A passport establishes who you are and authorizes you to cross a boundary. A visa goes further: it declares a purpose and a duration. But even a visa governs the entry, not the stay. It does not evaluate whether the purpose that justified the entry remains valid. It doesn’t know the conference ended, the deal collapsed, or the project was cancelled. When the context changes, the visa doesn’t. It was the right instrument for a world where the entity crossing the boundary would stop when the task was done.
It is the wrong instrument for an agent that will keep running until something tells it to stop.
The industry has responded to agent security by building better passports and better visas: tighter scopes, shorter lifetimes, faster rotation, more precise intent declarations at issuance. These are improvements. They are improvements to the wrong instrument.
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 (PoA) 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. You might grant limited financial authority, but not real-estate authority. The authority is scoped to why someone may act, not merely which actions are technically possible.
The same dimensions apply directly to agents. An agent authorized to source a backup logistics vendor holds authority for a specific purpose (vendor sourcing under pre-approved terms), a specific scope (that vendor market and contract templates), a defined time window (the active contingency program), and under conditions (the program remains active). When any dimension changes, the authority terminates, regardless of whether the agent’s token remains valid.
Mandates originate in human decisions. In the simplest case, the consent moment looks similar to an OAuth authorization flow: the principal reviews the agent’s declared purpose, scope, and conditions before approving. The difference is what gets recorded. An OAuth grant records that consent was given. A mandate grant records the purpose, the conditions under which it holds, and the events that will end it. The richer record is what makes the mandate evaluable throughout execution rather than only at issuance.
This distinction has roots in capability-based security. Object-capability systems addressed what Norm Hardy called the confused deputy problem in 1988: a program that misuses authority granted for one purpose to serve another. The agent mandate problem is the temporal extension of that failure. A confused deputy acts outside its sanctioned purpose in the moment. An agent without a mandate continues acting outside its sanctioned purpose over time, across hops, and across systems.
The foundational principles of least privilege and separation of protection from use, articulated by Saltzer and Schroeder in 1975, apply directly: authority should be explicit, bounded, and unforgeable by the actor holding it. What is new is the execution context: delegated authority across dynamic agent chains rather than static program-to-resource relationships.
The theoretical grounding for continuous authority evaluation comes from Park and Sandhu’s Usage Control (UCON) model (2004), which distinguished between conditions evaluated at the moment of access and conditions that must remain true throughout an ongoing action (what they called continuity obligations). The Execution Mandate operationalizes that distinction: conditions are not checked once at grant time, they are evaluated per action throughout the mission lifecycle. What UCON established as a theoretical property, agentic systems make a deployment requirement.
UCON remained largely unimplemented at enterprise scale because the deployment context didn’t demand it. In a world of request-response services operated at human pace, the human provided continuity enforcement implicitly: sessions ended when the task ended, and behavioral anomalies surfaced before they compounded. Agents remove both. The theory was right in 2004. The urgency is new.
👻 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 Access Layer 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: technically authorized at the access layer, 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.
Enforcement can sit at the orchestrator (the agent runtime checks mandate state before issuing calls), at an authorization sidecar (a policy engine evaluates mandate validity per request), or at a gateway layer (an intermediary enforces mandate state before requests reach the resource). The placement is an architectural decision; the point is that mandate state is an explicit, evaluable artifact rather than an implicit assumption. 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 Access Layer 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 tokens and permissions to take actions far beyond the original sourcing task.
The PoA Solution: The agent is governed by its mandate. 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 endpoint, scoped to one resource, one action, for the duration of that call. The sub-agent cannot further delegate, because its mandate is derived from the original mission scope and cannot exceed it. If the procurement program is cancelled, the parent mandate is revoked and the sub-agent’s authority terminates with it, regardless of whether any individual credential remains valid.
📋 The Execution Mandate in Practice
Both case studies share a common set of requirements. For mandate governance to hold, 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 concrete form of that authority is an Execution Mandate: a signed, inspectable record that runtime systems can evaluate and revoke independently of whether the underlying token remains valid.
At minimum it should carry:
- principal: who granted it
- agent: who holds it
- purpose: why it exists
- scope: what it covers
- conditions: what must remain true
- lifecycle: when it ends
- delegation: how authority passes to sub-agents
- delegation_chain: provenance
Offline attenuation, verifiable at any enforcement point without a callback, is technically feasible today. Capability-based formats prove the point from different angles: Macaroons through Hash-based Message Authentication Code (HMAC)-chained caveats, Biscuit through Datalog-based logic that expresses richer conditions directly in the token. Structured as a signed JSON Web Token (JWT, RFC 7519), the mandate can be verified at any enforcement point and attenuated at each delegation hop without a round-trip to the issuing authority.
For the mandate to be enforceable rather than advisory, it must be cryptographically bound to the token it governs, either by embedding a mandate reference in a token claim or by including a token hash in the mandate, so that presenting a valid mandate alongside an unrelated token is detectable at any enforcement point.
Crucially, this authority must remain anchored to the initial grant. An agent operating in an open world will inevitably discover new tools and data, but it must never be allowed to self-authorize into new permissions. The mandate can be amended only by authorized policy authorities: the granting principal or explicitly delegated administrators. The agent executing under it has no amendment rights.
An agent that can rewrite its own mandate has no mandate at all.
🎫 What the Mandate Carries That a Token Cannot
For the procurement agent in Case Study 2, a mandate structured as a signed JWT would look like this:
| |
The specific field names are illustrative. The structural requirements are what matter:
| Field | What it carries that an access token cannot |
|---|---|
principal | The human identity that authorized this execution: traceable, auditable, independent of the agent’s own identity |
agent | The specific agent instance holding this mandate: a distinct principal in audit logs, not the user it acts for |
purpose | Evidence traceable to a human grant: objective and business context, not a scope string |
authorization_details | Typed resource objects with per-resource actions and constraints, not scope strings |
conditions | Checks evaluated per action throughout execution; if the contingency program is cancelled, execution suspends before the next call |
lifecycle.terminal_events | Business milestones that end the mission, not only a timer |
delegation | Attenuation rules every child mandate must satisfy: strictly less scope, strictly sooner expiry, no further delegation |
delegation_chain | The full chain of mandate grants from the original human authorization to this agent, inspectable at any point during execution |
A mandate record also transforms the audit trail. Every action is attributed to a specific delegated purpose, the expiry of that purpose is a first-class event, and post-incident review can distinguish authorized access from authorized access after mandate expiry, a distinction invisible in today’s access logs.
Defining the Execution Mandate artifact is the foundation. Building the layer that issues, evaluates, propagates, and enforces it is what makes it operational. That requires four components working together, and that is where the next phase of enterprise security must go.