This is Part 3 of a four-part series. Part 1 established the structural gap in enterprise IAM. Part 2 introduced the Execution Mandate as the missing primitive. What follows builds the control plane that makes mandate governance operational.

A Power of Attorney document sitting in a filing cabinet grants nothing. The document establishes the authority. The system that issues, enforces, propagates, and terminates it is what makes that authority real.

The Execution Mandate is the document. What follows builds the system.

That system is not a single component. It is four primitives working together:

1. Execution Mandate as a first-class artifact: an authoritative mission state record, independently revocable, evaluable throughout the execution lifecycle
2. Continuous authority evaluation: a policy layer that asks whether execution should continue, not just whether a specific request is permitted
3. Cross-domain mandate propagation: portable mandate authority that crosses organizational and trust boundaries with verifiable chain of custody
4. Orchestration-layer enforcement: authority governance embedded in how workflows manage execution lifecycle, not only at access gates

Each primitive addresses a different failure mode. Together they make it possible to delegate authority to autonomous systems with the same confidence you delegate it to humans: defined scope, revocation rights, and a clear end.

📋 Execution Mandate as a First-Class Artifact

The mandate layer is an architectural pattern, not a prescribed product or deployment topology. The mandate service can be a standalone component, a capability added to an existing authorization server, or a module embedded in the orchestration layer. What matters is the function: authoritative mission state ownership with clear enforcement integration points.

A mandate service does not replace existing Identity and Access Management (IAM) infrastructure. It sits above it. The Identity Provider (IdP) establishes identity. The authorization server governs token issuance. The mandate service holds the mission record that both feed into, and that can terminate execution independently of whether the token remains valid. Enforcement sits wherever execution control decisions are made: the orchestration layer, an authorization sidecar, or a gateway. The integration point is not where authentication happens but where execution continues.

For teams with existing policy infrastructure, the mandate service does not need to replace the Policy Decision Point (PDP). It can function as a context source: the Policy Enforcement Point (PEP) queries the mandate service as part of its decision inputs and the PDP evaluates mandate state alongside identity claims and resource policy. This makes mandate governance composable with Open Policy Agent (OPA), Cedar, or OpenID AuthZen deployments rather than requiring a separate enforcement path. The enforcement timing is fixed regardless of architecture: mandate checks must happen before tool invocation and before any irreversible action. A post-action check is not enforcement.

The mandate service is the authoritative system of record for mission state. It owns whether a mandate was issued, under what terms, and whether it remains valid. Business systems are the sources of terminal events: a procurement platform signals a program was cancelled, a CRM records a renewal conversation closed, a ticketing system marks a task complete. Those signals flow to the mandate service, which evaluates them against lifecycle conditions and triggers revocation when they match. Every revocation is a first-class security event: who revoked, when, under which terminal condition, which child mandates cascaded, and what in-flight actions were halted. That record is reviewable independently of the underlying access logs and survives the token rotation cycles that would otherwise erase execution history.

Mandate payloads may carry sensitive business context. In cross-domain scenarios, downstream enforcement points do not always need the full payload to enforce it. A mandate can carry a reference handle in place of the full purpose description, with the authoritative record held by the issuing domain’s mandate service. Sensitive fields can be audience-restricted so only designated enforcement points can inspect them.

Like any authoritative control-plane component, the mandate service must be treated as a high-value target. Compromise of the mandate service is compromise of execution governance across every agent it controls. This means the mandate service requires the same hardening applied to authorization servers: signed artifacts so enforcement points can validate mandates without a live callback, defined fail-closed behavior so that an unavailable mandate service halts execution rather than defaulting to open, and audit logging of every mandate issuance, amendment, and revocation as a first-class security record.

Policy authority over mandates is not held by the agent. It belongs to the granting principal, the human who authorized the delegation. Organizations may extend this authority to additional parties: security teams, compliance officers, and designated administrators, each with defined scope over issuance, amendment, and revocation. When mandates conflict, the more restrictive constraint governs. Conflicts that cannot be resolved by scope intersection require human escalation before execution continues.

🔄 Continuous Authority Evaluation

A mandate that is checked only at issuance is not a mandate. It is a declaration. The authority layer must ask not is this request permitted? but should this execution still be running?, evaluated against current context at runtime, not only at the moment a token was issued or a gate was crossed.

A mandate that is checked only at issuance is not a mandate. It is a declaration.

Park and Sandhu’s UCON model established the theoretical basis in 2004: continuity obligations must hold throughout an ongoing action, not only at access time. What agentic systems add is not new theory but inescapable deployment urgency.

Continuous evaluation does not mean a synchronous round-trip to the mandate service on every API call. That model does not scale and creates a single point of failure. The operational approach is hybrid: high-value or irreversible actions trigger a synchronous mandate check before execution; high-volume low-risk calls assume the mandate valid until a revocation signal arrives via Shared Signals Framework (SSF)/Continuous Access Evaluation Protocol (CAEP). The mandate service pushes revocation when a terminal event fires, and ghost execution stops at enforcement points without gating every API call. Which action type applies should be policy-defined by risk and reversibility, not left to ad hoc runtime behavior.

The semantic substrate for continuous evaluation (how the mandate service knows what “the contingency program is active” means at runtime) is an open problem. Context graphs represent one promising direction: capturing the state that justified a decision as a queryable artifact that the mandate service evaluates conditions against, rather than waiting for discrete IAM events that may never arrive.

For conditions that cannot be instrumented against machine-observable signals, the mandate shifts from condition-based to event-based expiry: “valid until the CFO signs the envelope,” “valid while the renewal conversation is open.” The agent stops precisely when the human task completes, without requiring manual security reviews during execution. The re-authorization trigger is the business event, not the clock.

A mandate can only evaluate conditions it can observe: semantic context changes that generate no machine-observable signal remain a harder problem. When conditions cannot be instrumented, the mandate falls back to hard expiry. That fallback might seem to reduce the mandate to JIT with extra steps. The distinction lies in what the mandate carries even in the fallback case: an authoritative mission record that the rest of the security stack can query, a cascade revocation chain that fires when the mandate terminates, attenuation semantics that govern every delegation hop, and an audit trail that attributes execution to a specific delegated purpose rather than a credential issuance. JIT issues a credential window. A mandate issues a governed mission. Even when it terminates on a fixed expiry, the mandate is not JIT. As instrumentation improves and event surfaces expand, the condition model grows with it without requiring architectural changes.

🌐 Cross-Domain Mandate Propagation

The two primitives above describe what governance looks like within a single deployment. Agent chains do not stay within one. Model Context Protocol (MCP) servers are third-party. Agent-to-Agent (A2A) protocols cross organizations. Tool ecosystems span multiple vendors and trust domains. A centralized mandate service per organization can govern what it can see. It cannot govern what happens when authority crosses a boundary it does not control.

This is not a reason to abandon the mandate model. It is a reason to design the Execution Mandate as a portable artifact from the start. A mandate structured as a signed JSON Web Token (JWT, RFC 7519) or Biscuit token can be verified at any enforcement point without a callback to the issuing authority. Each domain validates the mandate at its boundary before accepting delegated authority, rather than trusting that the upstream caller has already validated it. The mandate travels with execution. Enforcement is distributed by design.

Four properties are required for cross-domain mandate governance to hold:

Federated trust. Trust bundles establish which domains are authorized to issue or extend mandates, analogous to SPIFFE (Secure Production Identity Framework for Everyone) trust domains or OAuth federation. A receiving domain verifies the full mandate chain before accepting authority. An unverifiable chain is an invalid chain.

Attenuation at every boundary. Each domain’s enforcement point applies the mandate’s attenuation rules as authority crosses in. The receiving domain is responsible for verifying that the incoming mandate is a strict subset of what the sender holds. Scope cannot amplify at a domain boundary any more than it can within one.

Distributed revocation via SSF/CAEP. The propagation infrastructure for cross-domain revocation signals already exists. The missing piece is an authoritative emitter in each domain. A per-domain mandate service provides that. Revocation originates at the issuing domain and propagates outward. Receiving domains that have subscribed to mandate-expiry signal types can enforce termination without a synchronous callback.

Interoperable mandate schemas. Mandate conditions that reference domain-specific state do not translate across organizational boundaries without shared vocabulary. The Workload Identity in Multi-Service Environments (WIMSE) working group and emerging agent protocol standards need to address cross-domain condition semantics as a first-class requirement, not an afterthought.

Cascade revocation across a delegation chain requires the mandate service to maintain a registry of child mandates issued under each parent. At issuance, each child mandate records its parent reference. When a parent mandate is revoked, the service walks that index, issues termination notifications to all registered child mandates, and for children held in other domains, propagates the revocation signal via SSF/CAEP. The chain terminates at every hop simultaneously rather than requiring each downstream system to detect the expiry independently.

None of these are solved problems today. But each has analogues in existing standards that can be extended rather than replaced. The minimum viable starting point does not require solving all four. A receiving system that verifies an incoming mandate’s signature and checks that its scope permits the requested action delivers most of the value of federated trust and attenuation without requiring shared revocation infrastructure. That narrow implementation already eliminates the core cross-domain failure: an agent arriving at a downstream system with no verifiable claim about the purpose and scope of its authority.

⚙️ Orchestration-Layer Enforcement

This is where the three layers above land in practice. When a mandate expires, orchestrators must be able to pause, unwind, or terminate execution, not merely block at the next gate. The same model saga patterns use for distributed transaction rollback applies here: execution can be compensated when a mandate terminates mid-flight, with idempotent compensation of partial side effects across service boundaries.

In practice this requires explicit handling for revocation lag, in-flight requests, and compensating transactions. The hybrid evaluation model described above (synchronous checks for high-value actions, signal-based revocation for high-volume calls) maps directly onto orchestration-layer enforcement: the orchestrator knows which actions require a mandate check before proceeding and which can proceed under the assumption of a valid mandate until a revocation signal arrives.

For conditions that cannot be instrumented, the mandate shifts from time-based to event-based expiry. Rather than asking a human to re-approve on a fixed schedule, the system anchors the mandate to a business milestone: “valid until the CFO signs the envelope,” “valid while the renewal conversation is open.” The agent stops precisely when the human task completes, without requiring manual security reviews during execution. The re-authorization trigger is the event, not the clock.

This is where the mandate layer becomes operationally meaningful for agent teams: instead of debating how long a Just-In-Time (JIT) window should be, teams define the terminal events for a mission at authorization time. The security team can audit those definitions. Compliance can validate them against policy. The agent executes until a defined business milestone, not until a timer fires.

🔮 The Next Control Plane

The gap was invisible because humans were closing it. Presence, pacing, and natural scope-limiting were doing governance work that no formal layer had to model. Agents remove all of that. When we hand execution to agents, we inherit the obligation to replace what humans provided implicitly: a governed mandate with a defined purpose, bounded scope, and a clear end.

Agents are not the first systems to create this mismatch. The same dynamics exist in long-running workflows, pipelines, and autonomous integrations. Agents are where it becomes impossible to ignore: they execute continuously, chain actions across systems, and operate without human pacing. The mismatch that was tolerable as edge-case noise in pipeline infrastructure is the default operating mode for agents. We are moving from a world of request-based security to mission-based security.

We are moving from a world of request-based security to mission-based security.

This does not require discarding what works. OAuth, OpenID Connect (OIDC), Zero Trust, and fine-grained authorization all remain foundational. What is missing is the layer above them: one that holds mission state and governs whether execution should continue, independent of token validity.

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

The four primitives described above are the components of that layer. None requires abandoning existing infrastructure. The mandate service sits above the authorization server, not beside it. Continuous evaluation composes with existing PDPs as a context source. Cross-domain propagation uses the SSF/CAEP rails already being standardized. Orchestration-layer enforcement is where existing agent frameworks gain security governance rather than local-only lifecycle tracking.

When this layer exists, agents can be deployed at scale without choosing between control and utility. Authority can be delegated explicitly, constrained to purpose, and terminated cleanly when purpose expires. The blast radius of a compromised or runaway agent shrinks to the scope of its active mission rather than the full reach of its identity.

We spent the last decade building better ways to verify who is at the door. The next decade is about governing what they are authorized to do once they are inside: not at each checkpoint, but for the duration of a defined mission with a clear end.

The security of the agentic enterprise depends on governing the stay, not just the entry. Identity controls establish who the agent is. Access controls govern what it may do at each boundary. The mandate layer governs whether it should still be acting at all. That is the missing primitive. These are its four components. And that is the next control plane.

For a deeper look at how the mandate layer composes with your existing IAM stack and a practical path to getting started, see Evolving IAM to Authority Governance