The previous post defined the Execution Mandate. This post builds the layer that makes it 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. The system that makes it real has four working parts.
- Mandate service: owns mission state as an authoritative, independently revocable artifact evaluable throughout the execution lifecycle
- Continuous authority evaluation: a policy layer that asks whether execution should continue, not just whether a specific request is permitted
- Cross-domain mandate propagation: portable mandate authority that crosses organizational and trust boundaries with verifiable chain of custody
- Orchestration-layer enforcement: authority governance embedded in how workflows manage execution lifecycle, not only at access gates
They are not independent improvements. The mandate service creates the state owner. Continuous evaluation consumes it. Cross-domain propagation extends it. Orchestration enforcement lands it.
Each primitive addresses a different failure mode. The first two enforce mission authority. They ask whether the mandate’s purpose, conditions, and lifecycle remain valid. The third enforces delegation authority across organizational boundaries. The fourth lands both at the execution layer. Together they make it possible to delegate authority to autonomous systems with the same confidence you delegate it to humans, with defined scope, revocation rights, and a clear end.
📋 Mandate Service
The mandate service is what turns the Execution Mandate from a document into an enforced constraint. What follows covers its architecture and integration, lifecycle and revocation, authority and delegation, and hardening as critical infrastructure.
🏗️ Architecture and Integration
The mandate service is an architectural pattern that can be deployed as 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.
The 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. Both feed into the mission record the mandate service holds, which can terminate execution independently of whether the token remains valid. Enforcement can sit at the orchestration layer, an authorization sidecar, or a gateway. The integration point is not where authentication happens but where execution continues.
Clarity about which component owns which question matters. The IdP answers questions of identity. The authorization server answers whether a token grant is valid. The policy engine answers whether a specific request is permitted under current policy. The orchestrator answers what an agent is doing at any given moment. The mandate service answers whether the mandate behind a request is still valid and whether that execution should continue. Each is authoritative in its domain. None substitutes for the others.
Mandate governance is a distinct concern from the two systems it sits between. Workflow state tracks what is happening in execution right now. Policy engines evaluate whether a specific request is permitted under current policy. Mandate governance asks whether the mission behind those requests should continue at all. That question cannot be derived from workflow state or from policy decisions. It requires a separate artifact that holds mission authority as a first-class, independently revocable record.
The trust directions within that architecture matter as much as the boundaries. The policy engine reads from the mandate service as a context source. The mandate service does not defer to policy decisions or to the orchestrator’s local execution state. Business systems emit terminal events and the mandate service owns the revocation decision. Writes to the mandate service are restricted to the granting principal and explicitly authorized policy administrators. Mission state authority is held by the mandate service alone. The others enforce, inform, or execute. None governs.
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, with the Policy Enforcement Point (PEP) querying the mandate service as part of its decision inputs and the PDP evaluating mandate state alongside identity claims and resource policy. This allows mandate governance to integrate with Open Policy Agent (OPA), Cedar, or OpenID AuthZen deployments as a context source 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.
🔒 Lifecycle and Revocation
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, recording 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.
Three authority questions govern the mandate lifecycle. The mandate is issued by the granting principal through the consent flow. The mandate service owns its ongoing state. Revocation rights belong to the granting principal, delegated administrators, and the terminal events defined in the mandate’s lifecycle conditions. Business systems report what happened. The mandate service decides whether it constitutes a terminal condition.
🤝 Authority and Delegation
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, including 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.
When an agent needs to delegate to a sub-agent, the mechanics of attenuation are worth making explicit. The delegating agent cannot self-issue a child mandate. It submits a delegation request to the mandate service, declaring the sub-agent’s identity, the scope it requires, and the conditions that should apply. The mandate service validates that the requested scope is a strict subset of the parent’s scope, that the requested expiry falls within the parent’s lifecycle, and that the parent mandate explicitly permits further delegation. The mandate service records the parent-child relationship, which is what makes cascade revocation possible when the parent mandate terminates.
This is where the tradeoff between online and offline attenuation surfaces. Offline attenuation (the Biscuit and Macaroons pattern, where the agent adds caveats directly to its own token without a round-trip) enforces strict-subset semantics structurally and is useful for latency-sensitive cross-domain calls. The cost is auditability. The mandate service has no record of what was delegated, to whom, and under what conditions, which makes cascade revocation across unknown chains unreliable. For deployments where auditability and cascade termination are first-class requirements, online attenuation through the mandate service is the right model. For teams starting with JWT-based mandates, conditions live outside the token and attenuation requires a service round-trip rather than in-token caveats. Those constraints are real and worth understanding before choosing a format.
Mandate issuance is the point at which Separation of Duties (SoD), dual control, and break-glass requirements must be explicitly modeled. A mandate cannot confer authority the granting principal is themselves prohibited from exercising under SoD policy, and SoD conflicts that emerge during execution should be expressible as conditions evaluated continuously, not only at issuance. High-value mandates may require co-authorization at the consent flow. Break-glass access should be modeled as a separate, time-bounded, heavily audited emergency mandate rather than a silent widening of an existing one, keeping the governance record intact and the deviation visible.
🛡️ Critical Security Infrastructure
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. Hardening requirements mirror those of authorization servers. Artifacts must be signed so enforcement points can validate mandates without a live callback. Fail-closed behavior is required so that an unavailable mandate service halts execution rather than defaulting to open. Operational policy must define explicit cache staleness bounds, local verification of signed artifacts to reduce live-callback dependency, and revocation lag tolerance calibrated to the risk profile of the actions governed. Every mandate issuance, amendment, and revocation is a first-class security event with a full audit record.
🔄 Continuous Authority Evaluation
Getting issuance right is necessary. It is not sufficient. 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 made this precise in 2004. Continuity obligations must hold throughout an ongoing action, not only at access time. The insight did not translate to deployment. Request-scoped controls were sufficient when humans were managing execution and closing the continuity gap themselves. Agents remove that assumption. CAEP and Zero Trust provide continuous access evaluation, re-evaluating whether a specific credential or request is still valid as conditions change. Behavior-bounded trust models add a third layer, tracking whether each action aligns with the stated objective and consuming a finite trust budget rather than relying on a static grant. The mandate layer provides continuous mission evaluation. It asks whether the execution behind those requests should still be running at all.
Continuous evaluation does not mean a synchronous round-trip to the mandate service on every API call. That model does not scale at production volumes 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 is an open problem. The mandate service needs to know what “the contingency program is active” means at runtime, but business vocabulary does not map cleanly to discrete IAM events. Rather than waiting for system events that may never arrive, one promising approach is to maintain a structured, queryable artifact that captures the ongoing state of the world the mandate was issued into (negotiations active, renewal open, procurement program running). The mandate service evaluates conditions against that artifact rather than raw system signals. Context graphs formalize this pattern, making the graph the semantic bridge between business vocabulary and policy-evaluable state.
For conditions that cannot be instrumented against machine-observable signals, the mandate shifts from condition-based to event-based expiry. A mandate can terminate when the CFO approves the disbursement, when the renewal conversation closes, or when the partner organization’s data-processing agreement lapses. The agent stops precisely when the human task completes or the governing relationship changes, without requiring manual security reviews during execution. The re-authorization trigger is the business event, not the clock.
When conditions cannot be instrumented against machine-observable signals, the mandate falls back to hard expiry. That might seem to reduce it to Just-In-Time (JIT) with extra steps. It does not. JIT issues a credential window. A mandate issues a governed mission. Even in the hard-expiry fallback, the mandate carries what JIT cannot. It holds an authoritative mission record 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. As instrumentation improves and event surfaces expand, the condition model grows with it without requiring architectural changes.
The hybrid model surfaces tradeoffs that have no universal answer. Revocation signals via SSF/CAEP are not guaranteed delivery, and stricter fail-closed behavior reduces exposure but creates availability risk. The right balance depends on the risk profile of the actions involved, the reversibility of side effects, and the availability cost the organization will accept when the mandate service is unavailable. What the model requires is that these tradeoffs be made explicitly and policy-defined, not left to ad hoc runtime behavior. A mandate layer that does not specify its failure semantics is not a governance layer.
🌐 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.
The mandate design has cross-domain portability built in. 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, and attenuation semantics ensure each delegation hop can only narrow scope, never amplify it. A receiving system can validate an incoming mandate at its boundary before accepting delegated authority, without requiring shared infrastructure with the sender.
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.
Full cross-domain governance requires infrastructure that current standards do not yet provide. Federated trust hierarchies, distributed revocation via SSF/CAEP across organizational boundaries, and interoperable condition schemas remain open problems. A single organization can issue, enforce, and revoke mandates within its own deployment with no cross-domain infrastructure at all. At the boundary, the portable mandate design described above provides the necessary tools. Signed artifacts enable validation without shared infrastructure. Attenuation semantics prevent scope amplification at each hop. Reference handles keep sensitive context on the correct side of the boundary. OpenID Federation and SSF/CAEP provide the trust and revocation infrastructure the cross-domain case will eventually require. Most deployments can achieve substantial mandate governance before that infrastructure arrives.
⚙️ Orchestration-Layer Enforcement
At the orchestration layer, the three primitives above become operational. When a mandate expires, orchestrators must be able to pause, unwind, or terminate execution, not merely block at the next gate. The saga pattern, which coordinates distributed transactions through compensating actions that undo partial work if a step fails, is a useful analogy here, not a direct implementation model.
What the analogy captures is the key operational requirement: not every in-flight action can be undone, and the orchestrator must know the difference before execution begins. If the vendor sourcing mandate expires while the agent is retrieving a supplier profile, halting the retrieval is straightforward. If it expires after an onboarding workflow has already been initiated, unwinding is not possible without human review. The mandate layer makes this distinction explicit at authorization time, defining which actions within the mission scope are reversible. That is what transforms mandate termination from an access control event into a governed unwinding of execution state.
Reversibility is declared at mandate issuance, not inferred by the orchestrator at runtime. The mandate defines the unwinding contract before execution begins.
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 agent teams, the operational payoff is concrete. 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.
Faramesh (Fatmi, 2026) proposes a complementary research architecture for this enforcement layer. Authority Attestation Bundles bind signed mission authority to each execution step, Continuous Authority Revocation propagates termination signals across execution boundaries, and Decision Artifacts provide the structured record linking each action to the authority that governed it. The primitives align closely with the mandate service components described in this post and represent the closest published academic framework for execution-layer mission governance in AI agent systems.
🔮 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. Long-running workflows and autonomous integrations face the same dynamic. Agents are where it becomes impossible to ignore. The shift is structural. Request-scoped controls answer each boundary correctly and leave the mission ungoverned. The current stack has not needed a mission-scoped layer until now.
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 that holds mission authority as a first-class, independently revocable artifact and governs whether execution should continue, independent of token validity.
The four primitives described above are the components of that layer, each composing with what already exists. The mandate service sits above the authorization server, evaluation feeds existing PDPs, propagation runs over SSF/CAEP rails, and enforcement embeds in existing agent frameworks.
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.
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 the agent should still be acting at all. That is the missing primitive. These are its four components. And that is the next control plane.