Agents need more than credentials. They need a durable authority record that says what they are allowed to do, why they are allowed to do it, who approved it, and when that authority should stop being valid.

That record cannot be reduced to a token, a policy decision, a final permit result at the commit boundary, or local orchestrator state. It has to live somewhere in the IAM architecture as a system of record for delegated authority. I will call that component the Mission Authority Service (MAS).

If Mission is real, where does it actually live?

Not metaphorically. Architecturally.

If Mission is not just a better scope string, not just an authorization detail in a token request, and not just a local runtime object inside an orchestrator, then it has to occupy a specific place in the stack. It has to be owned somewhere, projected outward in specific ways, and consumed by the systems that enforce policy, manage credentials, and terminate execution.

The Power of Attorney series established the core argument: agents need a Mission, not just credentials. The Mission Shaping series argues that approved intent still has to be shaped into bounded authority before execution begins. The Mission-Bound OAuth series explores one protocol realization of that authority and then asks whether OAuth is even the right long-term home for the model. This post answers the architectural question those arguments create.

This post does not re-argue why Mission matters. It answers the narrower question the rest of the series leaves open: where Mission actually lives in the architecture. The claim is straightforward: Mission is not the token, the policy decision, the commit boundary, or local orchestrator state. It is the control-plane object those systems consume.

The short answer is that Mission lives in a Mission Authority Service: a durable state owner for delegated authority. The next sections explain why that role cannot be collapsed into the token, the PDP, the commit boundary, or the orchestrator.

Once that is clear, the rest of the stack becomes easier to place. Existing IAM controls are not replaced. They compose around Mission as consumers and enforcement points.

To place Mission cleanly in the stack, it helps to separate four related layers that are often collapsed into one:

Most confusion comes from collapsing those four layers into one place. Tokens should carry projections. PDPs should evaluate the authority model. The commit boundary should re-validate current eligibility immediately before effect. Orchestrators should consume decisions and emit runtime events. None of those should become the canonical home of the approved Mission itself.

That distinction matters most at the PDP boundary and at the commit boundary. A PDP can answer “may this request proceed now?” The commit boundary can answer “may this action become real now?” Neither should be expected to reconstruct, own, and lifecycle the underlying authority record that makes those answers legitimate.

One terminological note before going further. The word “scope” carries different meanings depending on context. In OAuth, scope is a set of permission labels that grant access to protocol endpoints or API resources. In the Mission model, the clearer terms are purpose, authority envelope, and constraints. Those may eventually be projected into OAuth scope strings at a protocol boundary, but they are not the same thing. This post uses “scope” only where the surrounding context is already about OAuth scopes, credential scope, or an explicitly narrowed purpose scope.

Mission Is Not the Token

Tokens are projection artifacts.

They exist to carry bounded information across a protocol boundary so that another party can make a decision. That is exactly why they are useful and exactly why they are the wrong home for Mission.

A Mission has properties a token should not have to own.

• it survives across multiple token issuances
• it can change state while previously issued tokens still exist
• it can be suspended, resumed, revoked, or completed by business event
• it can govern multiple downstream projections at once
• it may need richer internal structure than any given protocol surface should expose

If Mission lives inside the token, then every lifecycle change becomes a token management problem. That collapses authority state into transport state, which is precisely the confusion the Mission model is meant to avoid.

OAuth, OIDC, AAuth, or any other protocol may project Mission state at a boundary.

A token can carry a Mission reference or a reduced Mission view. It should not be the place where Mission fundamentally lives.

Mission Is Not the Policy Decision

Policy engines answer decision questions.

May this request proceed? Does this actor satisfy the current conditions? Does this resource operation fall inside current policy?

Those are necessary questions, but a Policy Decision Point (PDP) is not a durable system of record for the purpose, lifecycle, provenance, and delegation history of a Mission. A PDP evaluates context. It does not normally own the authoritative state whose lifecycle must remain coherent across time, systems, and protocol hops.

This is where many architectures blur an important line. Because policy engines can evaluate Mission state, teams are tempted to let them implicitly become the holder of Mission state. But reconstructed context at decision time is not the same thing as a first-class authority record.

Mission must exist before the PDP is called and remain meaningful after it returns. The PDP consumes Mission state; it does not own it.

Mission Is Not the Commit Boundary

Even a correct request-time policy decision is not the same thing as durable authority.

The commit boundary is the last non-bypassable control point before an action commits into real state change, external side effect, or sensitive disclosure. In Power of Attorney terms, it is where the delegated act begins to bind the principal. In Mission terms, it is where approved intent stops being a governed plan and starts becoming governed consequence. A PDP can answer whether a request may proceed. The commit boundary asks whether the action may actually become real, right now, given current authority state and current execution context. Those are different questions asked at different moments.

That final check is essential. It is also not where Mission lives. The commit boundary re-checks current Mission state, actor continuity, approvals, and relevant context immediately before effect, but it is still a consumer of Mission state, not the place that owns Mission.

This distinction matters because teams often let the final enforcement point become the implicit authority system. They wire enough context into the gateway, control plane, or workflow engine that it can deny or permit the action, then assume the architecture has solved authority. It has not. It has only built a better commit boundary. A capable commit boundary is necessary but not sufficient without a state owner behind it.

Mission must exist before the commit-boundary check runs and remain legible after it completes.

Mission Is Not Local Orchestrator State

Orchestrators know the most about execution. The term covers two things: the coordination layer that delegates work across multiple agents, and the agent harness, meaning the runtime environment (LangGraph, AutoGen, or a custom tool-calling loop) that executes a single agent. The orchestrator decides what to delegate. The harness executes it. Neither should be the canonical home of Mission state.

The runtime knows what the agent planned, what tools it called, where it paused, what failed, and when it claims the job is complete. That runtime knowledge is indispensable. It is also not enough.

Local orchestration state does not automatically have the properties Mission needs.

• independent governance outside one runtime
• visibility to IAM and policy systems
• cross-session continuity
• auditable lifecycle
• protocol projection across trust boundaries
• revocation semantics that downstream systems can consume

If the orchestrator is the only place Mission exists, then authority dies with the runtime that happens to be executing it. That makes Mission local execution metadata, not a control-plane object.

The orchestrator is an important producer and consumer of Mission events. It should not be the sole owner of Mission state.

Mission Is Not Defined by Its Protocol Home

Neither the Authorization Server nor the Identity Provider is automatically the right home for Mission, even though both are plausible candidates.

Mission-Bound OAuth made the strongest possible case for putting Mission at the Authorization Server. The AS is the right place if the goal is to evolve an existing OAuth-heavy enterprise stack incrementally and keep authority close to token issuance, token exchange, and introspection.

But the critique in Why Mission-Bound OAuth Might Be the Wrong Answer holds equally. The Authorization Server may be the wrong long-term home if that move overloads it with responsibilities that are broader than protocol transport.

• durable authority ledger
• lifecycle state machine
• approval evidence store
• delegation graph authority
• runtime governance anchor

The same caution applies to the Identity Provider. Authentication may be the right place to bootstrap a Mission when a human is present, but it is not automatically the right place to own Mission thereafter.

So the architectural answer is narrower and more stable than any protocol-specific answer.

Mission is a separate control-plane object that may be implemented inside an Authorization Server, adjacent to it as a dedicated MAS, or behind another governance boundary entirely. The implementation choice can vary. The architectural role should not.

Where Mission Lives Architecturally

Mission lives in a Mission Authority Service (MAS): the system of record for delegated authority.

The MAS owns the authoritative record of:

• who approved the Mission
• for what purpose
• for which agent or workload
• under which constraints
• with which delegation bounds
• in which current lifecycle state
• with which projections issued to downstream systems

Moving Mission outside the AS has a real cost. The token-issuing AS must check Mission state before issuing tokens, which introduces a latency and availability dependency. A separate MAS also adds synchronization overhead that the AS-internal approach avoids.

Those costs are manageable with standard techniques: cache Mission state at the AS with a bounded TTL, design the MAS for the availability tier token issuance requires, and use a signal rail to push state changes rather than polling. The failure mode also has to be explicit. If the MAS is unavailable, the AS needs a defined policy: fail closed and deny token issuance, or fail open and issue without Mission validation. In most security models the answer is fail closed.

The AS-internal approach avoids this coupling at the cost of overloading the AS with governance responsibilities that may not belong there long-term. A separate MAS also creates a new state owner, a new consistency burden, and a possible governance bottleneck if every lifecycle or projection decision funnels through one control-plane component. The right choice depends on whether the deployment is incrementally evolving an existing OAuth stack or building a clean-sheet architecture. The architectural role of Mission remains the same either way.

The naming depends on context. Mission Authority Service is the architectural name used here. Some protocol discussions use Mission Manager for a similar mission-side governance slot, but the mapping is not exact across drafts or systems. In AAuth-style designs, for example, the mission-side governance role sits partly inside the broader Person Server function, as discussed in AAuth Now Has a Mission Layer, and R3 Shows Where It May Go. Mission Control is a useful product or operator-facing name for the administrative surface that reviews, suspends, resumes, or revokes Missions. The names can vary. The role should not.

Using the terminology introduced above, that system should hold both:

• the approved Mission as the durable governance record
• the Mission Authority Model as the machine-evaluable derivative that policy engines, gateways, authorization servers, and other enforcement points can actually consume

Those are related, but they are not the same thing. The approved Mission is the authoritative record. The Mission Authority Model is the compiled or reduced form that lets downstream systems evaluate and enforce that authority mechanically. Protocol projections are narrower still: they carry only the Mission context needed at a specific boundary.

• Mission Shaping explains how approved intent becomes bounded authority
• the MAS holds the approved Mission as a durable object
• the Mission Authority Model expresses that authority in machine-evaluable form
• protocol layers project reduced Mission views at boundaries
• policy and runtime systems consume Mission state during enforcement
• the commit boundary re-validates current Mission eligibility immediately before consequential action

The MAS’s job is not to replace access control. Its job is to own the state access control has been missing.

The MAS is also one of the most sensitive components in this architecture. It owns delegated-authority state that other IAM controls consume, even though it still composes with identity, policy, workload identity, and credential systems rather than replacing them. That makes it a high-value target. Access to create, update, suspend, or revoke Missions must itself be governed through authentication, authorization, and audit. The MAS cannot be a governance authority for agents while having a weaker access model than the systems it governs. Designing the MAS’s own access control is a first-class architectural requirement, not an implementation detail to defer.

The alternative is not “no Mission architecture.” It is an implicit Mission architecture spread across token claims, PDP inputs, orchestrator state, and audit reconstruction. That can work in narrow single-domain deployments. It becomes brittle when authority must survive lifecycle changes, bounded sub-delegation, cross-system enforcement, or cross-domain audit. The argument for a Mission state owner is not that other patterns never work. It is that they stop scaling cleanly once delegated authority has to remain durable, governable, and provable across time and boundaries.

How approved human intent becomes a Mission record in the first place is covered in the Mission Shaping series. What the Mission Authority Model must express and which systems consume it is addressed in the section below. This post focuses on where the resulting objects live in the stack.

Mission-Bound OAuth is best understood as one protocol expression of a deeper architectural object, not the canonical home of that object. That framing preserves what is strongest in the Mission-Bound OAuth model. It keeps the need for a durable Mission object, lifecycle-governed authority separate from token lifetime, and Mission projections at protocol boundaries. It removes the requirement that OAuth itself be the final home of the model.

That is also the line between architectural necessity and standardization necessity. A deployment can benefit from a durable Mission state owner before there is a fully portable Mission Authority Model standard. The architectural requirement is to have a system of record for delegated authority. The harder standardization problem is how to represent, sign, exchange, and evaluate that authority model portably across products and domains.

The implication carries beyond OAuth. Whatever protocol surfaces carry Mission state at authorization boundaries (OAuth and OIDC today, AAuth or something else later), and whatever runtime or agent surfaces consume that state (MCP, A2A, or their successors), the Mission object remains in the same architectural role. Surface changes should affect how Mission is projected or consumed, not whether Mission exists.

The Mission Authority Model

The hard part is the middle object: the Mission Authority Model. The approved Mission is the governance record. The Mission Authority Model is the machine-evaluable derivative that downstream systems consume. A board-packet Mission, for example, may need to express not only which systems are in bounds, but also that releasing the final presentation is blocked until a later approval event.

The MAS may produce that model directly, store a model produced by a shaping service, or assemble it from templates, policy, human approval, and implementation-specific compilation. The architectural point is not that the MAS does every step itself. The point is that the MAS is where the approved Mission and its authority derivative are governed as one lifecycle-bound record.

The model needs to express at least purpose, resource and action constraints, temporal bounds, stage or state constraints, delegation provenance, and attenuation rules. Some of those are structurally decidable. Resource, action, time, and some stage constraints can often be checked as formal subset relations. Purpose is harder. If purpose starts as natural language, the MAS cannot reliably prove semantic containment by structure alone. It can enforce structured purpose categories, require policy review, or route ambiguous changes to a human. That is a governed judgment, not a mathematical proof.

That distinction matters for sub-Missions. The MAS can mechanically check that a child Mission has no broader resource set, action set, or lifetime than its parent if those fields are structured. It can also require that the child’s purpose remains within the parent’s approved purpose. But unless purpose is represented in a constrained vocabulary or other formal model, purpose containment remains a policy decision rather than a portable proof.

Modern policy languages show how parts of this can be made machine-evaluable, especially resource, action, and contextual constraints. They do not, by themselves, solve Mission semantics, attenuation across domains, or portability of Mission Authority Models. The standards gap is the absence of a defined interface contract between the approved Mission and the authority model derivative: what inputs the MAS accepts, what outputs it produces, how those outputs are structured and signed, and what versioning semantics apply when a Mission is extended or modified.

That gap is real, but it is also one of the hardest things to standardize. Deferring a full Mission Authority Model has real adoption benefits: lower standardization burden, easier implementation, less cross-domain disclosure, and less risk of freezing the wrong universal authority vocabulary too early. The cost is weaker portability, weaker bounded delegation, and more implementation-defined meaning.

The absence of a shared Mission Authority Model does not remove complexity. It pushes that complexity outward into MAS heuristics, PDP-local interpretation, repeated human review, and post-hoc audit arguments about what the Mission really meant. Standardizing Mission coordination, lifecycle, and projection first is therefore a reasonable first step, but it should be understood as a foundation rather than a finished answer.

What a Real Deployment Needs

A real deployment does not need every theoretical piece on day one. It does need a recognizable minimum.

A practical Mission architecture usually needs:

1. A Mission Authority Service as the system of record
2. A stable Mission identifier or reference model
3. A lifecycle model with stable states such as pending approval, active, suspended, completed, revoked, and expired
4. Governed lifecycle events such as resume, sub-Mission spawn, scope change, and termination trigger
5. A projection model for tokens, assertions, API decisions, signals, and audit records
6. An explicit commit boundary where authority is re-validated before irreversible action
7. Enforcement hooks at orchestration and policy boundaries
8. A revocation path, whether synchronous, signal-based, or hybrid

Without most of those pieces, Mission governance is likely to be partial and fragile. The system has fragments of Mission context scattered across other components rather than a durable state owner.

The critical shift is not “add more policy.” It is “add a state owner.”

A Practical Migration Path

A real deployment does not need every piece on day one. The architectural role needs to be clear before the first step, but the implementation can be incremental. Many teams will start with a durable Mission record, narrow lifecycle handling, and limited protocol projection, then add stronger attenuation, runtime feedback, and commit-boundary enforcement as operational maturity increases.

Step 1: Introduce Mission as a first-class record

Start with a durable Mission object outside local runtime state and transient token state. The first version can be narrow: purpose, approver, principal and agent binding, lifecycle state, and termination conditions.

Outcome: a canonical Mission record with a stable identifier, lifecycle owner, and approval evidence.
Value: authority stops getting lost inside tickets, prompts, token claims, and orchestration metadata.
Tradeoff: this gives you a state owner before it gives you strong machine-evaluable semantics.

At this stage, the system is still light on machine-evaluable semantics, but it has stopped pretending that runtime state alone is durable authority.

Step 2: Shape enough before you enforce broadly

Turn approved intent into something a control plane can evaluate before treating it as broadly enforceable authority. The MAS can still store an approved Mission record early, even if the Mission Authority Model is initially narrow. The important point is not to pretend informal text alone is a complete enforcement artifact.

Outcome: a narrow but usable Mission Authority Model.
Value: downstream systems can enforce real bounds instead of treating free text as authority.
Tradeoff: teams have to choose where structure is worth the effort and where human judgment still remains.

This is the point where teams should decide which parts of Mission they can structure now and which parts still require human judgment. Resource classes, action classes, time bounds, principal bindings, and some stage constraints are usually the best starting fields. Purpose semantics and open-ended delegation policy are usually harder. The trap is trying to mechanize everything at once. The practical target is narrower: make enough of the Mission Authority Model explicit that downstream systems can enforce meaningful bounds without claiming a portable proof where none exists.

Step 3: Project Mission into existing protocol surfaces

Carry Mission references into tokens, introspection responses, delegated assertions, and audit events. Project only the reduced view the boundary needs.

Outcome: Mission becomes visible at protocol and audit boundaries.
Value: resources and audit systems can correlate actions to Mission without reconstructing authority from fragments.
Tradeoff: every projection choice has to balance usefulness against over-exposing internal Mission state.

Tokens, assertions, and audit records should gain enough Mission context to support correlation, bounded delegation, and downstream decision input, but not so much that every boundary becomes a dump of internal Mission state. A good early test is whether a downstream resource or audit system can answer “which Mission authorized this?” without also learning everything the MAS knows.

Step 4: Feed Mission into current enforcement

Use current gateways, PDPs, sidecars, and orchestrators as Mission consumers. The point is not to replace them. The point is to stop forcing them to reconstruct Mission implicitly.

Outcome: existing enforcement points start making Mission-aware decisions.
Value: authority checks move from inference to explicit evaluation.
Tradeoff: early deployments often cover only a few enforcement points, so coverage will be uneven for a while.

In practice, this usually starts with one or two enforcement points rather than the whole estate. A PDP may consume Mission state during request-time authorization. An orchestrator may require an active Mission before tool execution. A gateway may check Mission lifecycle before forwarding a request. The important shift is that these systems stop inferring authority from identity, token shape, or local orchestration context alone. They begin consuming explicit Mission state instead.

Step 5: Align credential lifecycle with Mission lifecycle

Let Mission state drive JIT activation, PAM teardown, suspension, or re-issuance where appropriate. Credential scope should derive from the Mission Authority Model so the credential clock does not drift away from the authority clock.

Outcome: credential lifetime begins following authority lifetime.
Value: Mission suspension or revocation has operational consequences rather than remaining only a governance event.
Tradeoff: credential types, caches, and broker behavior will still limit how quickly revocation becomes effective.

A suspended or revoked Mission should have visible consequences for token refresh, brokered credentials, and delegated access paths. Not every credential type will support instant teardown, and some enforcement paths will still be cache-bound. That is acceptable. The important change is that credential lifetime is now derived from authority state rather than treated as an unrelated operational concern.

Most deployments can pause here and still have a meaningful improvement: a durable Mission record, bounded protocol projection, explicit enforcement inputs, and credential lifecycle tied to authority state. Cross-domain federation and richer portable semantics can come later.

Step 6: Add signal-driven propagation

Once Mission state is authoritative, emit completion, suspension, and revocation through the rails already used for distributed control, using custom or future Mission lifecycle event types where necessary.

Outcome: Mission lifecycle changes propagate beyond the MAS.
Value: revocation and suspension become distributed control actions, not just local state changes.
Tradeoff: signal rails introduce delivery, ordering, and fallback concerns that local state changes do not have.

Signal-driven propagation is what lets Mission become a distributed control-plane primitive rather than a database row. This is where revocation stops being only “deny the next token request” and starts becoming “tell the rest of the estate that this authority changed.” Early implementations can stay simple: a narrow event set, a bounded list of consumers, and explicit fallbacks where signals are delayed or missed. The point is not instantaneous perfection. It is to create a real propagation path for authority change.

Step 7: Standardize projections incrementally

Only after the internal architecture is stable does it make sense to standardize how Mission is carried across specific protocols and trust boundaries.

Outcome: stable, reusable projection patterns across protocols and trust boundaries.
Value: interoperability starts from settled internal semantics rather than exporting local confusion into a wire format.
Tradeoff: standardization comes later, so early interoperability across products and domains will remain limited.

This sequencing matters. If a deployment tries to standardize protocol projections before it has stabilized the Mission record, the authority model, and the main lifecycle transitions, it will just export local confusion into a wire format. Standardization is most useful once the internal architecture has taught the deployment which fields are durable, which semantics are stable, and which projections different boundaries actually need.

The migration is real when governed actions, delegated credentials, and audit records can all be traced back to a live Mission record without forensic reconstruction.

Reference Sequences

With the minimum architecture and rollout path in view, the stack placement becomes clearer when it is drawn as a set of interactions. These sequences are not a separate architecture or required protocol flow. Read them as reference target flows: Mission is created and lifecycled in the MAS, projected through token and protocol surfaces, consumed by policy, credential, and runtime systems, and preserved for audit.

Mission Creation and Token Projection

The first sequence shows the normal case. The orchestrator proposes a Mission. The MAS creates the durable authority object and machine-evaluable authority model. The Authorization Server then projects a reduced Mission view into a token after checking current Mission state.

The important point is that token issuance depends on Mission state, but the token does not become the Mission. It is one projection of the Mission into a specific protocol boundary. The PDP still does request-time policy evaluation, but the final consequential act is gated again at the commit boundary. That boundary may be implemented inside the resource, a gateway, or a workflow engine. It is a stage in the architecture, not a required standalone product.

This sequence assumes the AS can validate Mission state and projection rules before issuing a token. That can be implemented inside the AS, through a dedicated MAS, or through another governance boundary, but the dependency has to exist somewhere.

Mission Revocation and Downstream Propagation

The second sequence shows why Mission lifecycle cannot be reduced to token lifetime. A business event can terminate the authority that justified execution even while previously issued tokens or credentials still exist.

This sequence is the desired control-plane behavior, not something existing signal standards provide out of the box. Resources still need a way to receive or query current Mission state, token lifetimes and caches still matter, and credential teardown depends on the credential type and enforcement architecture.

CAEP and Shared Signals are plausible rails for this kind of propagation, but current CAEP event types do not define Mission lifecycle transitions. A deployment needs custom event types or future standard event types for suspension, completion, revocation, and forced termination.

Sub-Agent Delegation

The third sequence shows where orchestrators fit. The orchestrator proposes delegation. The MAS validates that the proposed sub-Mission is inside the parent Mission’s authority envelope before any token is issued to the child.

This is the same placement rule in recursive form. The orchestrator is a producer of delegation proposals and a consumer of Mission decisions. It is not the authority that decides whether the child receives delegated authority.

This sequence also assumes the Mission Authority Model has a defined subset or attenuation relation. Without that, the MAS can approve or deny sub-Missions as a policy matter, but it cannot mechanically prove that the child authority remains inside the parent authority envelope.

What the Existing IAM Stack Becomes

What follows is not a replacement map for IAM. It is a placement map: what each existing control becomes once Mission has a state owner. The point of the next few sections is not to survey the whole stack exhaustively, but to show where the main enforcement, credential, propagation, and audit layers change once delegated authority has a durable home. Each layer still has a real job. Each integrates with Mission in a specific way. None of them becomes the durable authority state owner.

PAM and NHI

PAM and Non-Human Identity controls govern secret hygiene, issuance, brokering, and rotation. They manage the credential correctly.

They integrate with Mission by taking lifecycle direction from it rather than approximating authority lifetime indirectly. Mission state tells PAM when a credential should stop representing live authority.

Task-scoped credentials and JIT provisioning are the natural implementation at the credential layer. When a Mission becomes active, PAM can provision credentials scoped to the Mission Authority Model. When it is suspended, completed, or revoked, PAM can suspend, rotate, tear down, or stop renewing those credentials according to the enforcement model.

The key point is auditability. Credential scope should follow the Mission Authority Model, not be determined independently by the requesting agent. The Mission record shows what authority was approved, and the JIT system shows which credentials were provisioned against it. Actual teardown still depends on credential type, cache behavior, propagation latency, and enforcement architecture.

PAM remains the credential governor. Mission becomes the authority clock.

Workload Identity and SPIFFE

Workload identity proves which software principal is acting.

Systems such as SPIFFE answer that identity question well. A workload gets an SVID that binds it to an authenticated software identity. In a Mission-aware architecture, that is the right foundation for proving that the calling process is the agent, orchestrator, sidecar, or sub-agent it claims to be.

But workload identity by itself does not tell you why that workload is acting, under which approved authority boundary it is acting, or whether that authority is still live. A SPIFFE ID can tell you that spiffe://example.org/ns/agents/sa/research-bot is the caller. It cannot tell you whether that bot is acting under Mission M-2026-0317, whether that Mission is suspended, or whether the call is part of a delegated sub-Mission.

Mission fills that architectural gap. Identity answers who is acting. Mission contributes the durable authority context that lets downstream systems decide whether this execution is legitimate for that actor at this time.

Without Mission, teams tend to overload workload identity with authorization semantics it was never designed to carry. The service sees a valid workload certificate, infers that the caller is generally trusted, and lets that standing software identity accumulate more effective authority than any single task should have.

The stronger pattern is composition: workload identity authenticates the software principal, Mission binds that principal to an approved purpose and lifecycle, and policy evaluates the request using both. In a SPIRE-based deployment, Mission activation can bind authority to a verified SPIFFE identity or workload class. Later token issuance, sub-Mission creation, or policy evaluation can require the caller to present that same attested workload identity.

The same logic applies to sub-agents. A child workload may have its own valid SPIFFE identity and still need a separate sub-Mission. Authenticating the child does not justify inheriting the parent’s authority.

SPIFFE gives the architecture a strong answer to software identity and attestation. Mission gives it a strong answer to delegated authority and lifecycle. Workload identity authenticates the caller. The MAS owns the delegated-authority state that determines what that caller is authorized to do.

OAuth, OIDC, and Protocol Surfaces

OAuth and OIDC become projection layers, not the canonical home of Mission.

OAuth and OIDC carry Mission references, reduced Mission views, approval input, verified actor continuity, and derived token semantics across protocol boundaries. They project Mission state into tokens, assertions, introspection responses, and protocol decisions after consulting the MAS. But they do not have to be the canonical storage location for the Mission itself.

There are two different protocol jobs here.

First, OAuth request and token surfaces can carry Mission-related authorization input and output.

RFC 9396 Rich Authorization Requests is the most directly relevant OAuth mechanism for carrying Mission intent into an authorization request. RAR allows a caller to include structured authorization details (not just scope strings) in the request to the AS. That makes it a plausible carrier for Mission-related inputs such as a Mission reference, a reduced Mission Authority Model summary, or a pointer to an active Mission record once those semantics are profiled explicitly. That lets the AS validate Mission state before issuing tokens rather than having to infer it from scope strings alone.

The act claim in RFC 8693 Token Exchange is one concrete example of where delegation context already propagates through OAuth today. That standardization is useful and worth building on. It is also not a substitute for a durable Mission record, which Standardize act Across Assertion Grants and JWT Access Tokens covers from the delegation side.

Second, call-chain context surfaces can preserve Mission-derived context as work moves through a trusted runtime path.

The emerging IETF work on Transaction Tokens addresses some of what RFC 8693 alone cannot provide. It defines short-lived tokens for preserving user identity, workload identity, and authorization context through a call chain within a trusted domain. Transaction Tokens look like a promising projection surface for some Mission-derived context. They do not provide the durable Mission record, the lifecycle state machine, or the revocation model. They also should not be treated as a general multi-hop delegation or sub-Mission mechanism by themselves. They are a useful context-propagation primitive that a Mission architecture may consume, not a replacement for the authority object.

Protocol surfaces move Mission-derived authority across trust boundaries or through call chains. Mission remains the control-plane object that owns the durable authority state being projected.

PDPs, FGA, and AuthZen

Policy systems provide request-time evaluation. They answer questions such as whether this subject may perform this action on this resource under current conditions.

They integrate with Mission by consuming Mission state as a first-class decision input. The Policy Enforcement Point asks not only for identity, resource, and environment context, but also for current Mission state. The Policy Decision Point evaluates whether the request still falls inside an active Mission.

The MAS is not the PDP. It is the system whose state the authorization service or PDP queries, caches, or synchronizes with. AuthZen, the OpenID Foundation’s authorization API standard, is relevant here as one candidate decision interface near the commit boundary. A caller can send subject, resource, action, and context to an authorization service and receive a structured decision. In that model, Mission state is part of what the authorization service evaluates before it responds. It does not replace the MAS itself.

The PDP still decides. The MAS still owns the durable authority record that informs those decisions. Policy remains an enforcement layer. Mission remains the control-plane state that policy evaluates against.

That layer should also stay distinct from the final commit boundary. A PDP may be consulted there, but the architectural point is broader than “call the PDP later.” The system still needs a non-bypassable control point that re-validates the current Mission state, actor continuity, approvals, and relevant target conditions before irreversible action. The PDP participates in that answer. The MAS is still the system whose durable authority state makes the answer meaningful.

CAEP and Shared Signals

CAEP and Shared Signals Framework provide propagation rails for distributed systems that need to react to state changes.

They integrate with Mission by carrying Mission lifecycle changes such as suspension, revocation, completion, and terminal business events across enforcement points without forcing every system into synchronous callback patterns.

CAEP is not the source of Mission truth. It is the rail Mission truth travels on.

One practical constraint is worth noting. CAEP’s existing event type vocabulary covers identity and security events such as session, credential, assurance, device, and risk changes. Mission lifecycle transitions such as suspension, completion, forced termination, and scope change are not yet defined event types in the Shared Signals Framework. Using CAEP as a Mission propagation rail requires defining those event types, which is implementer work until the standards catch up.

That boundary is important. CAEP and Shared Signals do not decide Mission lifecycle and do not own canonical Mission state. They distribute changes emitted by the MAS.

IGA and Audit

IGA systems and audit platforms provide review, correlation, attestation, and evidence about who had access, how it was used, and under what governance conditions.

They integrate with Mission by consuming Mission identifiers and lifecycle facts emitted into tokens, enforcement logs, and audit records. Instead of asking only who had access, they can ask:

• under which Mission was this access exercised?
• was that Mission active at the time?
• who approved it?
• when did it terminate?

The result is an authority record, not just an access record.

To be useful, that record has to preserve more than access facts. It has to preserve provenance: who acted, for whom, under which Mission, under which policy and constraint version, at which enforcement point, with which resulting state change or external effect.

For this to work in practice, the Mission identifier must survive in the audit events, tokens, and enforcement records that need downstream provenance and correlation. If the Mission reference is not preserved where that traceability matters, IGA and audit systems are back to reconstructing authority context from fragments, which is the problem Mission is meant to eliminate.

This is no longer just an architectural preference in regulated or audited environments. Many governance regimes increasingly require stronger approval provenance, runtime traceability, and accountability for automated decisions or delegated execution. They do not prescribe a MAS by name. But they do make questions like who approved an agent action, under what authority, and whether that authority was valid at the time of execution much harder to treat as optional. A MAS is one architectural way to make those questions answerable without forensic reconstruction after the fact.

IGA and audit do not become Mission Control. They observe, correlate, and prove what happened. The MAS remains the system of record that made those events legible in the first place.

Orchestrators, Agent Frameworks, and Sub-Agent Delegation

Orchestrators and agent frameworks provide runtime coordination and execution state. They plan, delegate, call tools, pause, resume, and track task progress. Upward, the orchestrator emits Mission-relevant events: completion, failure, exception, proposed extension, and sub-agent spawn. Downward, it consumes Mission-relevant events: suspension, revocation, scope change, and termination. The orchestrator is an important actor but not the authority. The MAS owns the delegated-authority state that decides what authority the runtime actually has.

That relationship becomes recursive when sub-agents are involved. A sub-agent is a new principal performing work on behalf of an existing Mission. It should not inherit the full authority envelope of the parent by default. The architectural answer follows directly from the Mission model: sub-agents get delegated sub-Missions, not copies of the parent Mission.

A sub-Mission is derived from the parent Mission. It carries a reference to the parent, a narrowed purpose scope, its own lifecycle with a ceiling governed by the parent, its own principal binding identifying the sub-agent specifically, and delegation provenance connecting it back to the original approval. The MAS validates that proposal against the parent Mission’s current state and constraints. It does not simply accept whatever the orchestrator claims.

Three constraints matter for placement in the IAM stack: the sub-Mission cannot exceed the parent authority envelope, its lifecycle is coupled upward, and the delegation chain must remain auditable.

The first constraint is partly structural and partly semantic. The MAS can mechanically check resource, action, and time bounds if those fields are structured in the Mission Authority Model. Purpose containment is harder. A parent Mission that authorizes “research competitors and draft an analysis” does not implicitly authorize sending the draft to the client, but detecting that boundary often requires policy or human judgment unless purpose is expressed in a constrained vocabulary. Governed attenuation is still significantly better than no check at all, but it should not be described as a portable proof until the Mission Authority Model has explicit subset semantics.

Stage and sequencing constraints are just as important. “Call back for approval before releasing the presentation” is not a scope question. It is a stage constraint. If the Mission Authority Model cannot represent that release is blocked until a later approval event, the system either depends on a human remembering the prose or loses the requirement entirely. This is not an abstract concern. The AAuth gap analysis shows the same constraint at the protocol level: the current AAuth drafts name mission lifecycle states but provide no mechanism to represent sequencing constraints between them.

This is where protocol projection matters, but it is still not where Mission lives. The act claim in RFC 8693 Token Exchange is the closest current OAuth artifact for representing delegation context in tokens, and Standardize act Across Assertion Grants and JWT Access Tokens covers that delegation-chain problem from the token side. Transaction Tokens may also be useful for preserving transaction context inside trusted domains, but they do not, by themselves, provide a durable sub-Mission lifecycle or cross-domain delegation model.

Cross-organizational sub-agent delegation remains the hardest case because the receiving domain may not share the originating MAS or have a live trust relationship with it.

Runtime Governance Integration

The reference sequences show the MAS emitting lifecycle events outward to consumers. They do not show the orchestrator reporting back to the MAS as execution proceeds. That return channel is the missing half of the feedback loop.

Mission governance is not only a pre-execution gate. A useful MAS needs runtime signals: task completion, extension requests, anomaly notifications, and release-gate requests before irreversible actions. Those signals let the MAS complete the Mission, require step-up approval, narrow remaining authority, suspend for review, or revoke.

This is the integration point the Mission Shaping Is Not Enough argument was pointing toward. Containment can block bad actions at the tool boundary, but it needs somewhere to route anomalies for governance-level response. The MAS provides that anchor. Containment limits damage in the moment; Mission governance provides the authority to act on what containment observes.

The practical gap is not one specific framework. It is that there is no common standard integration pattern for agent frameworks to report Mission lifecycle events back to a MAS. CAEP and Shared Signals cover outward propagation from a control plane to consumers. The inbound rail from orchestrator to MAS still needs a direct API, event bus, or bidirectional signal pattern. The exact implementation may vary by trust model, protocol surface, and operational maturity.

Cross-Domain Mission Federation

Cross-organizational sub-agent delegation is the case the Mission architecture is least equipped to handle today. The hardest version is when a receiving domain has no live trust relationship with the originating MAS, has not participated in the Mission approval, and cannot verify the provenance of the authority claim without additional trust infrastructure.

There are only a few basic shapes. A receiving MAS can query the originating MAS through federation and get live Mission state, accepting a live availability dependency. The originating MAS can issue a signed, self-contained projection with a short TTL, accepting weaker revocation. Or the receiving domain can treat the incoming projection as evidence and issue its own local Mission, accepting additional latency and possible human review.

Privacy constraints apply in every approach. The full Mission text and internal authority model should not cross the boundary unmodified. A reasonable privacy-preserving projection is a minimal view: the Mission reference, a purpose summary, the requested resources and actions, and the delegation chain up to the approval root.

No widely deployed standard covers this today. OIDC Federation addresses dynamic trust establishment, not Mission-to-Mission authority projection. AAuth’s mission-aware governance and PS-to-AS federation are closer to this problem, and companion work like R3 improves resource-local authorization semantics, but neither yet defines a general Mission-to-Mission federation model or a portable Mission Authority Model above the resource boundary. The gap is a protocol profile for how a Mission projection from one domain is packaged, signed, transmitted, and evaluated by a receiving domain.

What This Does Not Solve

This placement does not solve every hard problem.

It does not define a complete Mission Authority Model schema. It specifies what the model must express and what each consuming system needs from it. The standards gap it names (no defined interface contract between approved Mission and authority model derivative) remains open, and there are credible reasons an ecosystem might standardize Mission coordination and projection before it standardizes full Mission Authority Model semantics.

It does not make revocation instantaneous. It gives revocation an authoritative source and propagation path, but token lifetime, cache behavior, signal delivery, and resource-side enforcement still matter.

It does not eliminate policy engines. PDPs still decide request-time authorization. The MAS gives them durable authority state to evaluate.

It does not eliminate runtime containment. A valid Mission does not prove that an agent is still semantically aligned with the approved purpose. The Runtime Governance Integration section above describes how containment and the MAS connect through the orchestrator feedback loop, but runtime monitoring and semantic alignment remain application-layer responsibilities the MAS cannot substitute for.

It does not dictate whether the MAS is physically separate from the AS. In some deployments, the MAS may be implemented inside an AS. The architectural role is what matters.

It does not imply that every Mission question can or should be mechanized. Some Mission questions will remain policy or governance judgments even in mature systems. The point is to make the parts that benefit from consistency, bounded delegation, and durable provenance explicit and machine-consumable.

The Real Shift

The shift is not from IAM to something that replaces IAM.

It is from an IAM stack that answers request-scoped questions in isolation to a control plane with a mission-scoped state owner available to those systems.

The architectural placement matters for exactly this reason.

The shaping problem is real. The runtime problem is real. The protocol problem is real. But underneath all three is one deeper architectural fact.

Mission has to live somewhere as a durable control-plane object, or the rest of the stack is only simulating authority governance.

That does not mean every deployment must standardize a fully portable Mission Authority Model on day one. A reasonable path is to establish Mission as a durable state owner first, standardize lifecycle and projection next, and let richer Mission Authority Model semantics mature later. The architecture still needs a place for that model to live when the ecosystem is ready for it.

If a deployment can show durable delegated authority, lifecycle control, bounded sub-delegation, revocation propagation, and commit-boundary revalidation without a distinct Mission state owner, that would weaken the need for MAS as a separate architectural role. In practice, most current alternatives achieve some of those properties by reconstructing Mission state from other systems rather than owning it directly.

The Mission series started with a simple claim: agents should not be governed by borrowed credentials alone. They need delegated authority that can be approved, bounded, projected, enforced, revoked, and audited.

This post completes the architectural answer by giving that authority a durable home in the stack.

Once that object exists, today’s IAM systems stop competing with the Mission model and start composing around it.

That is where Mission lives in the stack.