Governing the stay requires an artifact that no current control provides. For delegated authority to remain trustworthy throughout execution, it must carry four things. The purpose for which it was granted. The conditions that must remain true while it runs. The lifecycle events that end it. And the provenance that traces it back to a human decision.

Identity controls establish who the agent is, not why. Tokens govern what is permitted, not the conditions under which permission holds or the business milestones that close it. Policy engines evaluate each request against current policy but in standard deployments maintain no record of the mission that originated the request, or whether that mission remains valid. Together they answer every question except the one that matters. Should this execution still be running?

No widely adopted primitive holds purpose, conditions, lifecycle, and provenance as a first-class artifact. That is what the Execution Mandate is.

⚠️ The Enforcement Gap

What is missing from the current stack is not an enforcement mechanism. Policy engines can evaluate mandate conditions once the state is present. What is missing is a state owner. No widely adopted control-plane component holds mission authority as a first-class, independently revocable artifact, and without that, every enforcement point in the stack is answering the wrong question.

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 requires that every request be re-evaluated against current identity and policy. That verification is request-scoped. It checks the request, not the mission. The failure takes four forms:

The two cases below are one of each kind, and the subtlest, because in each the mission itself is still running.

• The “Conflicted Reviewer” (Mission Authority Failure): An expense audit agent is authorized by an analyst to review the team’s travel submissions. During execution, the analyst is added as a required approver for one of the expense reports in scope, creating a separation-of-duty conflict that did not exist at issuance. The agent is now auditing a record its principal must approve. The mission is still active. A reviewer assignment is not an IAM event. Nothing in the stack can see it.
• The “Delegated Approver” (Delegation Authority Failure): A legal due diligence agent is authorized by General Counsel to review acquisition target contracts. Midway through the review, GC recuses herself due to a personal conflict of interest and formally delegates her authority to outside counsel. The agent’s mandate traces back to a principal who no longer holds authority over that decision. The mission is still active. The token is still valid. A recusal is not an IAM event. Nothing in the stack can see it.

Authorization is a decision mechanism. Whether role-based, attribute-based, policy-based, or relationship-based, access control models 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:

• Access Token: valid ✓
• 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.

The response to this scenario is often to point to delegation-token chains with depth limits and reduced scope. If the chain is shallow and the token is narrow, surely the blast radius is contained. Even with those controls, the problem persists. A depth limit governs how far authority propagates. A reduced scope governs which resources the agent may access. Neither provides a canonical place to represent that this mission ended at 2:00 PM and to force every enforcement point to converge on that fact. The chain has no concept of the purpose that justified it.

The more sophisticated objection is that existing primitives, composed correctly, could approximate the same result. Rich Authorization Requests (RFC 9396) carry structured purpose declarations at token issuance. Short-lived tokens limit credential exposure. CAEP propagates revocation signals. A fine-grained PDP evaluates contextual conditions per request. Each addresses a real problem. The composition still fails on the same point.

RAR declares purpose at issuance but has no revocation semantics tied to whether that purpose remains valid. Short-lived tokens refresh independently of mission lifecycle. A 15-minute token does not terminate when the mission does. It gets refreshed. CAEP can propagate a mandate-expiry signal, but without a standardized source of mission state there is nothing to propagate. A PDP evaluates whether each request is permitted, not whether the mission that originated the request is still valid.

Composed correctly, these controls close access gaps and reduce blast radius. None of them creates a state owner for mission authority. That is the role that has no current occupant.

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 whether this action was 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.

That distinction matters not just in incident response but in routine governance. A mandate record gives reviewers and auditors what they currently lack. A structured attestation linking every action to a named human grant, a declared purpose, and a defined lifecycle. Compliance reviews can validate not just that access was assigned but that it was used within its authorized scope and terminated when that scope ended.

The gap manifests across every dimension of agentic execution:

📜 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, declaring a purpose and duration, but it still governs only the entry. It does not evaluate whether the purpose that justified the entry remains valid. 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 Execution Mandate is the artifact that carries and enforces it as a signed, independently revocable record.

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 defined conditions (the program remains active). When any dimension changes, the authority terminates, regardless of whether the agent’s token remains valid.

One dimension the PoA analogy surfaces that the access model often obscures is that you can only grant authority you actually hold. In enterprise practice, this breaks down more often than the access layer reflects. A manager who authorizes an agent to process HR records may have read access to those records without owning them. The data governance function that does own them has independent policy interests the delegating principal’s grant does not represent. Resource owner consent and delegating principal intent are distinct inputs to authorization. Treating them as one is a meaningful gap in the consent model, and for sensitive or regulated data the mandate should reflect both.

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 described as the confused deputy problem in 1988. A confused deputy misuses authority granted for one purpose to serve another. The agent mandate problem is the temporal extension of that failure. The mandate layer closes the temporal dimension. It restricts not just what authority may be exercised at any moment but how long that authority runs and under what conditions it remains valid.

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.

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 PR is merged at 2:00 PM. The mission is over, but the token remains valid until 2:00 AM. The agent continues polling the private repository for 12 hours, still authorized at the access layer but no longer authorized by its 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 mandate is invalidated. 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: 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: To prevent this type of failure, 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 two failure modes above are not edge cases. They are the only options the pre-authorization model offers. Restrict the agent to pre-enumerated resources and it cannot execute in an open world. Grant broad credentials and every discovery is an expansion of blast radius. The mandate breaks that binary. Discovery is evaluated against mission scope, not against a pre-approved list. Execution governance is not a more sophisticated form of pre-authorization. It is a different control operating at a different layer.

📋 The Execution Mandate in Practice

Those two scenarios converge on 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: full provenance from the originating human grant to this agent

The mandate can be structured in several formats. Macaroons (NDSS 2014) enforce attenuation structurally through HMAC-chained caveats. Biscuit uses Datalog-based logic to express richer conditions directly in the token. Both are promising primitives for mandate attenuation but have limited enterprise adoption and production track record today. A signed JSON Web Token (JWT, RFC 7519) has the broadest enterprise tooling support and deployment experience, making it the practical starting point for a minimum viable mandate implementation, with online/offline attenuation tradeoffs handled at the control plane layer.

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.

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 the granting principal or explicitly delegated administrators. The agent executing under it has no amendment rights.

Authority over the mandate’s lifecycle is held by the granting principal. The mandate continues until a defined terminal event fires, the granting principal revokes it, or its lifecycle expires. The agent governs none of these.

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

{
  "jti": "mnd-logistics-sourcing-7f2a",
  "iss": "https://mandate.example.com",
  "iat": "2025-10-01T08:00:00Z",
  "exp": "2025-10-15T17:00:00Z",
  "sub": "urn:agent:procurement/vendor-sourcing@3.2",
  "aud": ["https://enforcement.example.com", "https://vendor-portal.example.com"],

  "principal": {
    "sub": "vp-supply-chain@example.com",
    "iss": "https://idp.example.com",
    "grant_ref": "gnt-oauth-c9d3e1"
  },

  "agent": {
    "instance": "inst-7f2a-b8c4"
  },

  "purpose": {
    "objective": "Source and onboard a backup logistics vendor under pre-approved terms",
    "business_context": "Contingency supplier program, primary vendor SLA breach Q4-2025"
  },

  "authorization_details": [
    {
      "type": "vendor_portal",
      "locations": ["https://vendor-portal.example.com"],
      "resource": { "category": "logistics", "region": "north-america" },
      "actions": ["search", "view_profile", "initiate_onboarding"],
      "constraints": {
        "contract_template": "standard-logistics-v3",
        "spend_tier": "pre-approved"
      }
    }
  ],

  "conditions": [
    {
      "id": "program-active",
      "expression": "procurement.contingency_program.status == 'active'",
      "evaluation": "per_action",
      "on_failure": "suspend_and_notify"
    },
    {
      "id": "sod-clear",
      "expression": "principal.conflicted_vendors.contains(request.vendor_id) == false",
      "evaluation": "per_action",
      "on_failure": "halt_and_escalate"
    }
  ],

  "lifecycle": {
    "hard_expiry": "2025-10-15T17:00:00Z",
    "terminal_events": ["vendor_onboarding.completed", "contingency_program.cancelled"],
    "on_expiry": "revoke_and_cascade"
  },

  "delegation": {
    "permitted": true,
    "max_additional_hops": 1,
    "attenuation": "strict_subset_of_parent",
    "cascade_revocation": "immediate"
  },

  "delegation_chain": []
}

The specific field names are illustrative. The structural requirements are what matter:

The payload serves both dimensions. The purpose, conditions, and lifecycle fields govern mission authority. They ask whether the mandate’s conditions and purpose remain valid throughout execution. The principal, delegation, and delegation_chain fields govern delegation authority. They ask whether the chain from this agent to the originating human grant is intact and unattenuated. A mandate can fail on either dimension independently of the other.

A mandate record also transforms the audit trail and the governance record. 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. The same record gives access certifications, compliance audits, and regulatory reviews what they currently lack. A structured attestation linking agent activity to a human decision, a declared scope, and a defined end.

The Execution Mandate is the artifact the existing stack does not yet hold. It is what makes delegated execution governable rather than merely authorized. Building the layer that enforces it is where the next post goes.