The series above makes the case for an Execution Mandate layer. What follows maps how to get there from where you are: what each component of your existing stack already covers, how the mandate layer composes with it, and what a minimum viable path to implementation looks like. It stands on its own and is not required reading for the main argument.

You have already built most of what matters. PAM governs credential lifecycle. JIT limits standing access. CAEP propagates risk signals. Fine-grained authorization evaluates context per request. The stack is working.

The mandate layer does not replace any of it. It sits above it. The sections below map where each component’s scope ends and where mandate governance picks up, then trace a minimum viable path to getting there from where you are.

🔐 PAM and NHI Controls

What they solve: Privileged Access Management (PAM) and Non-Human Identity (NHI) tooling achieves Zero Standing Privileges, vaults secrets, governs non-human credential issuance, and rotates credentials on schedule. When a PAM vendor adds agent identity support, it means the agent is a known, managed principal with vaulted secrets and governed lifecycle. That is necessary work.

Where the mandate problem begins: PAM governs the credential. It does not govern the mission. A scheduled rotation fires at 3 AM regardless of whether the mission was cancelled at 2 PM. The agent now holds fresh, properly governed credentials in service of a mandate that no longer exists. Credential lifecycle and mission lifecycle are separate clocks. PAM aligns the first. Nothing in the PAM model aligns the second.

How it composes: When a mandate expires or is revoked, the mandate service can signal PAM to rotate or destroy the agent’s credentials, aligning the credential clock with the mission clock. PAM governs the credential. The mandate service governs when that credential should cease to represent active authority. Together they close both clocks.

🏗️ Workload Federation and SPIFFE/SVID

What they solve: Workload federation and SPIFFE (Secure Production Identity Framework for Everyone) establish cryptographic identity for non-human principals through SVIDs (SPIFFE Verifiable Identity Documents). This agent is a known, authenticated workload running as a specific principal with a verifiable identity. That eliminates a class of impersonation and identity spoofing vulnerabilities that matter in agent systems.

Where the mandate problem begins: Identity answers who the agent is. The mandate problem is whether the execution should continue. An authenticated agent with valid workload credentials and an expired mandate is still a ghost. The authentication layer has no concept of mission state, and there is no SPIFFE extension that carries one.

How it composes: SPIFFE establishes who the agent is. The Execution Mandate establishes what it is authorized to do and for how long. Both are presented at each enforcement point: the SVID verifies identity, the mandate verifies mission authority. A receiving service that validates both can distinguish an authenticated agent acting within an active mandate from one whose mandate has expired, a distinction SPIFFE alone cannot make.

🎯 Fine-Grained Authorization (OPA, Cedar, FGA)

What they solve: Policy engines like Open Policy Agent (OPA), Cedar, and fine-grained authorization platforms can evaluate rich, structured attributes per request, including purpose, context, relationship, and resource type. They are not limited to role-string matching. A well-designed policy can encode mission-relevant attributes and evaluate them on every call.

Where the mandate problem begins: Per-request attribute evaluation is not mission state ownership. The question is not whether the policy engine can check an attribute. The question is who holds the authoritative, queryable source of mission state that the attribute is checked against. Without a mandate service, that authoritative source does not exist. The policy engine evaluates what the request presents. If no upstream component owns “is this mission still active?”, the policy engine has nothing authoritative to evaluate it against. The enforcement capability is present. The authoritative state source is not.

How they compose: Once a mandate service exists, OPA and Cedar don’t need to be replaced; they become the enforcement layer that queries mandate state as a context source. The Policy Enforcement Point (PEP) queries the mandate service alongside identity claims and resource policy; the Policy Decision Point (PDP) evaluates mandate validity as one input among several. The mandate service is what the policy engine was waiting to query.

The mandate service is what the policy engine was waiting to query.

💡 Intent-Aware Authorization and RAR

What they solve: OAuth Rich Authorization Requests (RFC 9396) allow clients to declare structured purpose at authorization time: not scope=finance:read but purpose=quarterly_financial_analysis, resource=finance/q3-2025, authorized_by=cfo@example.com. The authorization server issues a token scoped precisely to that declared intent. This is meaningful progress: a token that carries declared purpose is better than one that carries only a scope string.

Where the mandate problem begins: RAR’s declaration is made once, at the moment of the request. It is not a living record. The authorization server issues the token with the declared purpose; it does not track whether that purpose remains valid as execution unfolds. “Intent at issuance” and “authority throughout execution” are different things. The CFO scenario illustrates the gap precisely: the RAR token was issued correctly with the right declared purpose. The board approved the presentation at 2:00 PM. Nothing in the authorization server’s record of the RAR declaration knows the purpose has concluded.

How it composes: RAR’s structured authorization details at issuance map directly to the mandate’s authorization_details and purpose fields. A mandate service can ingest a RAR request as the source of declared intent, creating the mandate artifact from the same structured data the authorization server already processes. RAR carries the intent in. The mandate holds it as a living record throughout execution.

📡 CAEP and Shared Signals

What they solve: The Continuous Access Evaluation Protocol (CAEP) and Shared Signals Framework (SSF) provide the propagation infrastructure for security-relevant context changes across trust domains. When a risk event occurs (credential compromise, session anomaly, policy change) CAEP can propagate that signal to resource servers that have subscribed, triggering re-evaluation without waiting for the next token expiry. This is the right rail for distributing revocation signals.

Where the mandate problem begins: CAEP can carry a mandate-expiry signal once a signal type is defined and an authoritative emitter produces it. Today, neither exists. No component in the standard stack owns mission state, so there is nothing to emit. A board meeting conclusion, a vendor program cancellation, a PR merge: none of these are signal types that existing CAEP emitters know about. CAEP is the right propagation infrastructure. The mandate service is the missing emitter. These are complementary, not competitive. CAEP becomes more powerful once there is an authoritative source of mission state to emit from.

How it composes: The mandate service becomes the emitter CAEP was built for. Once mandate-expiry is defined as a signal type, each mandate service subscribes downstream resource servers and orchestrators to the signals it emits. When a terminal event fires, the mandate service pushes a revocation signal via SSF; receiving systems enforce termination without a synchronous callback. The propagation infrastructure is already in place. The mandate service is what makes it useful for mission governance.

🗂️ IGA and Entitlement Lifecycle Fields

What they solve: Identity Governance and Administration tooling governs what permissions are assigned to a principal, when those permissions should expire, and how they are reviewed. Adding a mission lifecycle field to an entitlement catalog records when a permission should end, a step toward aligning entitlement records with operational intent.

Where the mandate problem begins: A field in a catalog and an evaluable artifact that runtime systems check before each action are not the same thing. Entitlement management governs what permissions are assigned. It does not create a runtime enforcement point that evaluates expiry during execution. The catalog might say “this entitlement expires when the project closes.” Nothing in IGA sends a revocation signal to the agent’s orchestrator when the project closes. The gap is between governance record and runtime enforcement.

How it composes: Entitlement records can reference the mandate IDs under which access was granted. When a mandate expires, the expiry becomes a first-class event visible to IGA’s access certification workflow: reviewers can verify not only that a permission was assigned but that it was exercised within an active mandate and terminated when the mandate did. The mandate record gives IGA the temporal governance context that entitlement records currently lack.

⚡ JIT Provisioning

What they solve: Just-In-Time provisioning reduces standing access exposure by issuing credentials or activating privileges only when needed and for a bounded time window. A 30-minute JIT window is better than a persistent standing credential. This is genuine security improvement.

Where the mandate problem begins: JIT provisions access for a time window estimated to match mission duration. When the window closes, the credential expires. When the mission ends early, nothing happens. The window remains open. When the mission runs long, credentials are refreshed, which resets the credential clock without re-authorizing the mission. The timer and the mission are separate clocks. Aligning them requires something that knows when the mission actually ended, and without a mandate service, no component does.

How it composes: The mandate’s terminal events replace JIT’s estimated time window as the credential lifecycle signal. Instead of provisioning a fixed window and hoping the mission fits, the JIT system issues credentials bound to the mandate’s lifecycle: active while the mandate is active, revoked when the mandate’s terminal events fire. JIT and mandates together make credential windows event-bounded rather than time-bounded.

👤 Human-in-the-Loop Approval Flows

What they solve: Human-in-the-Loop (HITL) approval gates require human authorization before sensitive or irreversible agent actions proceed. They maintain human oversight over high-stakes execution steps and provide a natural checkpoint for context validation.

Where the mandate problem begins: Approval flows assume a human-paced world. At agent speed, the volume of approval requests creates fatigue. In practice, teams respond by broadening grants or reducing approval frequency, which reintroduces the standing access problem the gates were meant to prevent. More fundamentally, HITL addresses individual actions, not mission lifecycle. A human approving each tool call does not constitute a human governing whether the mission behind those calls should still be running.

How it composes: Human approval gates become mandate amendment events. When an agent encounters a sensitive or irreversible action requiring human authorization, the approval creates an auditable amendment to the mandate: the scope is extended to cover that specific action, authorized by a named principal, at a recorded timestamp. Human oversight is preserved and attributed: not as a per-action log entry but as a governance event in the mission record.

🤖 Agent Frameworks and Orchestration Lifecycle Tracking

What they solve: Agent frameworks can track lifecycle state locally, recording when a mission was started, what actions were taken, and when the task completed. This gives the orchestration layer awareness of execution state that raw Identity and Access Management (IAM) infrastructure has no visibility into.

Where the mandate problem begins: Well-designed orchestration systems can track mission lifecycle locally: when a workflow started, what actions were taken, when it completed. That local awareness is real and valuable. The gap is not in what the orchestrator knows. The gap is in what that knowledge can reach. Local state is not visible to IAM, audit, enforcement, or revocation infrastructure outside the framework. An orchestrator that knows the mission is over has no mechanism to propagate that fact to the authorization server, the access logs, or downstream agents operating in other trust domains. The result is execution awareness without security governance: the orchestrator’s knowledge is isolated, unable to signal revocation to downstream systems, unable to produce an audit trail that IAM tooling can interpret, and unable to cascade termination across delegation chains that cross organizational boundaries. Better orchestration closes the execution gap within a single runtime. The mandate closes the governance gap across the full security stack.

How it composes: The orchestrator’s local lifecycle state becomes the input channel for the mandate service rather than a siloed record. When the orchestrator detects mission completion, it emits a terminal event to the mandate service; when the mandate is revoked externally, the mandate service pushes a signal back to the orchestrator. Local execution awareness and security governance operate on the same state rather than in parallel, and the agent framework becomes the runtime arm of mandate enforcement.

🔬 Emerging Protocol Standards

MCP, A2A, OpenID AuthZen, AAuth

Model Context Protocol (MCP) defines how agents and tools communicate. A2A defines agent-to-agent interaction patterns. OpenID AuthZen defines PEP/PDP API contracts. AAuth is an early-stage proposal extending OAuth with URL-based agent identity and explicit multi-hop delegation. Each of these advances the agent security stack in important ways.

None defines a mandate lifecycle primitive or a cross-session mission state record. These protocols operate at the boundary layer: what a request carries and how an authorization decision is returned. Mandate governance is the layer above them: what mission state authorizes the request in the first place. The right relationship between these standards and a mandate layer is composition: agent protocols carry mandate references, authorization servers issue mandates alongside tokens, and enforcement points validate mandate state as part of the AuthZen decision flow.

UMA 2.0 (User-Managed Access) addresses delegated authorization with explicit resource owner control and is relevant to scenarios where the granting principal needs fine-grained control over what agents may do on their behalf. UMA’s resource owner authorization model is closer to the mandate consent flow than standard OAuth, and a mandate implementation that builds on UMA’s delegation semantics would be a natural fit for resource-owner-centric deployments.

✅ What the Stack Gets Right

The controls described in this post are not wrong. They are right about everything they were designed to govern. PAM governs credentials correctly. JIT reduces standing exposure correctly. CAEP propagates risk signals correctly. FGA evaluates per-request attributes correctly. The stack is working.

The mandate gap is not a gap in execution. It is a gap in scope. Every control was built to answer a request-scoped question at a specific enforcement point. The question agents expose (should this execution still be running?) is mission-scoped and stateful. It requires a component that owns mission state, evaluates it continuously, propagates it across trust boundaries, and terminates execution when that state changes.

That component does not exist in the current stack. Vendor implementations are approaching it from different angles: Microsoft Entra’s agent identity capabilities add lifecycle governance for non-human principals; AWS IAM session policies allow purpose tags to constrain session scope; Google Cloud Workload Identity Federation supports attribute conditions that can encode mission context. Each narrows the gap in a specific dimension. None yet provides an authoritative, independently revocable mission state record that runtime systems can query and that cascades revocation across delegation chains.

Building the full layer does not require discarding what works. It requires adding a state owner above what OAuth-based delegation was designed to provide.

🌱 The Bootstrapping Question

Every mandate originates in a human decision, but that raises a practical question: who issues the first mandate, and how does trust get established?

The consent flow borrows from OAuth: the principal reviews the agent’s declared purpose, scope, and conditions before approving, and the mandate service records the result as a signed artifact. What gets recorded is different: purpose, lifecycle, and conditions alongside consent. But the interaction pattern is familiar. This is a more demanding interaction than OAuth scope approval: the principal must specify not just what the agent may do but when it should stop, which requires translating business intent into terminal events and conditions at authorization time. That is the primary adoption barrier the mandate model has to clear.

No single existing model covers the full mandate design space. Several together come closest, each covering a different dimension:

The CA model governs issuance structure. Like a Certificate Authority (CA), a mandate service issues signed artifacts verifiable at any enforcement point without a live callback. Like a CA hierarchy, organizations operating multiple mandate services need a trust hierarchy for issuance authority: which services are authorized to issue mandates, under what constraints, and for which principals. Trust anchor questions are answered by trust bundles analogous to CA root stores. The CA analogy holds for structural trust. It breaks down for runtime semantics: certificates are static artifacts; mandates carry dynamic conditions evaluated per action throughout execution, and they expire when business events occur rather than when a timer fires.

Capability tokens govern delegation mechanics. Where the CA model falls short, capability-based formats like Macaroons and Biscuit pick up. Capability tokens enforce attenuation cryptographically: a token holder can only add restrictions, never remove them. Strict-subset-of-parent at every delegation hop is not a policy rule. It is a structural property of the token format. Biscuit’s Datalog-based caveats are the closest existing technical primitive to mandate conditions. These formats handle how delegation mechanics work. They do not have a trust hierarchy for issuance authority or a model for cascade revocation across chains.

Power of Attorney governs runtime semantics. The CA and capability models handle structure and mechanics. What they don’t handle is what the mandate means at runtime: purpose, event-based lifecycle, conditions tied to business state, and authority that terminates when context changes. That is the Power of Attorney (PoA) frame, already the core analogy of this series, and it remains the right one for the runtime semantics that neither the CA nor the capability model can reach.

Transparency logs address the accountability gap the CA and capability models leave open: what happens to mandate provenance once authority crosses organizational boundaries. Certificate Transparency (RFC 6962) demonstrates the key property: every TLS certificate must appear in a tamper-evident, append-only log before it is trusted, making the record verifiable by any party, not just the issuing CA. Applied to mandates, this closes the cross-domain observability problem directly. A receiving organization can require that an incoming mandate appear in the issuing domain’s transparency log before accepting delegated authority. A mandate service granting authority beyond what the principal authorized becomes detectable across trust boundaries, not only within the issuing organization. Every issuance, amendment, and revocation is in the record. A mandate not present in the transparency log is not a valid mandate. The tamper-evident, cross-domain property is what makes federated mandate trust auditable rather than assumed.

ACME (RFC 8555) provides a model for mandate lifecycle operations after issuance. The Automatic Certificate Management Environment solved a practical problem: servers need to renew and revoke certificates continuously, without requiring human intervention each time. Mandate services face the same operational requirement once a mandate is active: orchestrators need a standard protocol to renew mandates when missions extend and trigger revocations when terminal events fire, at the speed agents operate. Mandate issuance is different: it originates in a human decision and cannot be automated the same way. But the renewal and revocation mechanics ACME standardized for the certificate ecosystem are precisely what a mandate service needs for the lifecycle operations that follow issuance.

Together: CA hierarchy for issuance authority, capability tokens for delegation mechanics, transparency logs for accountability, and ACME for automated lifecycle, with Power of Attorney as the conceptual frame that ties the runtime semantics together.

🗺️ What Comes Next

The mandate layer described in this series is not a product that can be purchased today. It is an architectural pattern with a clear requirements surface: a mandate service, a continuous evaluation engine, cross-domain propagation via SSF/CAEP, and orchestration-layer enforcement. Some of these components exist in early form. None are standardized end-to-end.

The standards work that needs to happen is specific:

For practitioners who cannot wait for standards: a mandate service that issues signed artifacts, an orchestrator that checks mandate state before irreversible actions, and a revocation endpoint that downstream systems can subscribe to are enough to eliminate ghost execution, bound blast radius, and produce an audit trail that distinguishes authorized access from authorized access after mandate expiry. That is a meaningful improvement over the current state without requiring a new standard to land.

The path from where most organizations are today to mandate governance is incremental. The controls are present. The integration points are defined. What is missing is the state owner that makes the rest of it governable.

We have the right controls. We have been asking the wrong question.

Companion to the series “You Don’t Give Agents Credentials. You Grant Them Power of Attorney.” Part 1: Agents Don’t Need Your Passport. They Need Your Authority. · Part 2: From Passports to Power of Attorney · Part 3: Governing the Stay, Not Just the Entry