The previous three posts in this series made the strongest case for Mission-Bound OAuth:

• Part 1 argued that a durable Mission object is better than token-only continuity for delegated agent authority
• Part 2 showed how the authentication layer bootstraps a Mission cleanly and how ID-JAG projects it across same-IdP trust domains
• Part 3 argued that even AAuth, a cleaner-sheet agent protocol, still appears to need a Mission-like governance layer

That is the positive case.

This post is the negative one.

If I were trying to tear the idea down rather than defend it, I would say this:

Mission-Bound OAuth may be a clever way to improve OAuth-heavy enterprise IAM, but it may also be the wrong home for the problem, the wrong abstraction boundary for agent governance, and the wrong long-term substrate for open-world systems.

That critique is worth stating directly, because the architecture is only useful if it survives serious skepticism.

The pessimistic argument has five main parts:

1. Mission-Bound OAuth asks the Authorization Server to do too much.
2. It mixes governance state with protocol transport concerns.
3. It depends on an authority-compilation step that is much harder than the OAuth parts.
4. It may still underfit real agent execution, which is messier than the architecture assumes.
5. It may be too broad to standardize well at the semantic layer that actually matters.

If those objections hold, then Mission-Bound OAuth is not the right answer to the full problem. At best, it is a transitional answer for organizations that already live inside OAuth.

The Authorization Server Becomes Too Important

The architecture looks disciplined because everything routes through the Authorization Server (AS):

• Mission creation
• approval and attenuation
• lifecycle state
• delegation depth
• verified actor binding
• token issuance and exchange
• business-event termination
• introspection
• distributed authority-model retrieval

That is elegant on paper. It is also a warning sign.

The AS stops being only a credential issuer and becomes all of the following at once:

• a durable authority ledger
• a lifecycle state machine
• a delegation graph authority
• an approval evidence store
• a policy compilation checkpoint
• an event-driven execution governor

That concentration creates three distinct problems.

It creates operational bottlenecks

Every serious control point now depends on AS correctness and AS availability. If the AS or the systems it depends on are slow, mission execution slows. If they fail closed, execution stalls. If they fail open, the governance story collapses.

This is not incidental. It is a direct consequence of choosing OAuth as the home for Mission governance. A typical enterprise OAuth deployment is already a latency-sensitive component in every user-facing flow. Mission-Bound OAuth adds Mission state lookups, lifecycle checks, compiled authority evaluation, and introspection calls on top of that. Each additional dependency is another failure mode.

The staged adoption path in Part 1 acknowledges that the AS may become a bottleneck and calls for a resilience model. But “we need a resilience model” deferred is not the same as “we have a resilience model.” For a component that is now the authority source for whether delegated software should continue operating at all, the resilience requirements are much higher than for a standard token service.

It creates organizational bottlenecks

In most enterprises, the team that runs the IdP or Authorization Server is not the team that owns workflow orchestration, business events, agent runtime safety, or domain-specific approval systems.

Mission-Bound OAuth assumes those worlds can be joined behind one control plane: the IAM team now also owns Mission lifecycle, approval policies, authority compilation, and business-event integration. Sometimes that is realistic. Often it is not. The IAM team has no operational visibility into the business processes that should drive Mission termination, and the workflow team has no way to extend AS policy to reflect domain-specific authority rules.

The result is either a very thin AS-side Mission that only stores lifecycle state and delegates all real governance to downstream systems, or an AS that accumulates domain knowledge it is not structurally suited to own. Neither is the architecture the document describes.

It creates disproportionate blast radius

If the Mission store or the AS is compromised, the attacker does not just gain token issuance influence. They gain the authority layer that decides whether delegated software should still be operating at all.

That is a qualitatively different prize than a normal token server. A compromised standard AS lets an attacker issue new tokens with elevated scope. A compromised Mission-bearing AS lets an attacker also rewrite the governance record that downstream systems use to determine whether existing execution should continue. They can activate suspended Missions, prevent revocation from propagating, and silently expand authority envelopes. The delta between those two threat surfaces is not marginal.

Mission-Bound OAuth’s design compounds this by making the AS the authoritative source for the compiled Mission Authority Model. If that model is stored at the AS and the AS is compromised, an attacker does not just steal tokens. They steal the compiled representation of what each agent is permitted to do, and they can modify it without triggering token rotation.

Governance May Not Belong Inside OAuth

The deepest critique is not that the architecture is too complicated. It is that it may be putting the durable authority object in the wrong place.

OAuth is fundamentally good at:

• issuing tokens
• narrowing tokens to audiences
• deriving tokens across exchanges
• binding tokens to clients and keys

Mission governance is about something else:

• approval
• durable authority state
• lifecycle transitions
• business-event termination
• delegation policy
• audit evidence
• cross-system authority continuity

Those are governance concerns first and OAuth concerns second.

Mission-Bound OAuth tries to connect those two layers by making the AS authoritative for the Mission itself. That is coherent, but it is not obviously the best separation of concerns. It may be cleaner to let OAuth consume Mission state rather than own it.

There is a simple test for whether an object belongs in a protocol or belongs in a layer that the protocol consumes:

if the architecture still makes sense when the protocol is removed, then the protocol may not be the right home for the primary object.

The Mission passes this test. A Mission-like durable authority object makes sense whether the downstream execution layer is OAuth, AAuth, a job scheduler, a workflow engine, or a tool broker. The governance concern exists independently of the transport. That is a strong signal that Mission governance belongs in a separate authority layer and OAuth is one consumer of that layer, not its home.

GNAP (Grant Negotiation and Authorization Protocol) is at least suggestive here. One of the recurring adoption questions around GNAP has been whether richer protocol capability and richer governance capability are being introduced together in a way that raises the adoption bar. Mission-Bound OAuth may be taking on a similar risk by coupling the transport improvement and the governance object too tightly.

Mission-Bound OAuth makes a similar choice. It is a real improvement in what the AS governs. It may not be the right place to put the object that drives that governance.

The Hard Part Is Not OAuth. It Is Compilation

The architecture is at its strongest when it says a Mission is the compilation boundary between ambiguous intent and enforceable authority. That is also where it is weakest.

Part 1 describes the compilation step as follows:

1
2
3
4
5
6
7

intent
  ->
Mission Proposal
  ->
Approved Mission
  ->
Mission Authority Model

That stack is the right conceptual shape. The hard problem is the first arrow: turning open-ended human intent into a bounded, machine-evaluable Mission Proposal without over-delegating or causing constant re-approval failures.

The compilation problem has several hard sub-problems that Mission-Bound OAuth does not directly address.

Semantic ambiguity. “Schedule a meeting with the engineering team” could mean: read all engineering team calendars, write a calendar event, send email invitations, record the meeting in a CRM, look up attendees’ availability across a directory, and propose a room booking. Or it could mean just the calendar write and the email send. The same natural-language intent compiles to very different authority envelopes depending on who is doing the compilation and what they assume. The Mission Authority Model format defines how to express those envelopes. It does not resolve the ambiguity in choosing which envelope is correct for a given intent.

Verification. Even if you compile a Mission Proposal from a user’s stated intent, how do you verify that the compiled result actually matches what the user intended? The approval step is the intended answer: the user sees the compiled authority and approves it. But the gap between what a non-expert user reads in an approval screen and what the machine-evaluable authority model actually encodes can be large. Approval UX that accurately represents a complex compiled authority model is an unsolved design problem, not a layout problem.

Trust in the compilation agent. If an LLM interprets the user’s prompt and proposes the Mission, the compiled authority model is a probabilistic artifact. The same prompt submitted twice may produce different proposals. A prompt injected with adversarial content in a retrieved document may produce a silently expanded proposal. The Mission Authority Model format gives you a way to inspect the result. It does not give you a way to attest that the LLM’s interpretation was faithful to the user’s intent and free of injection. That attestation problem is pre-OAuth and does not become easier because the result ends up in a well-structured authority model.

Interoperability collapse at the hardest layer. Part 1 already acknowledges that compilation may become proprietary, and that if every implementation compiles authority models differently, interoperability may exist only at the token-envelope layer. That is the realistic outcome. The purpose taxonomy, the operation groups, the resource selectors, the relationship predicates: all of these require shared semantics to be interoperable. Shared semantics require coordination. That coordination is harder than defining the schema that carries the semantics.

The practical result is that Mission-Bound OAuth may be disproportionately elaborate around the easier half of the problem, the OAuth protocol mechanics, while still being under-specified around the hardest half: the semantic agreement that makes compiled authority models meaningful across system boundaries.

The Architecture May Still Underfit Real Agent Execution

Mission-Bound OAuth is built around checkpoints:

• approval
• issuance
• exchange
• introspection
• lifecycle transitions

Real agent systems do not only act at those checkpoints. They:

• pause and resume unpredictably, often across different runtime processes
• switch runtimes when a sub-agent is spun up or a tool call delegates further
• re-plan after partial failure, discovering that the initial plan did not account for what they found
• discover new tools at runtime through MCP or equivalent capability discovery
• accumulate new facts that change what the next step should be
• branch into multiple parallel tasks that may have different authority requirements
• call systems that are not inside the OAuth fabric at all

The MCP tool discovery case is a specific and important example. An agent may be approved for a Mission covering calendar, email, and CRM. During execution, it discovers through MCP that a scheduling assistant tool is available that also touches document storage. The agent never planned to touch document storage. The Mission never anticipated it. But the agent’s natural execution path leads there.

Mission-Bound OAuth’s answer is mission_authority_exceeded: the agent gets a structured error indicating that document storage is outside the compiled authority envelope, and it must either stop that path or trigger a Mission expansion proposal. That is the right governance answer. It is also a significant friction point in agent execution that may, in practice, cause agents to request broader initial authority envelopes, defeating the bounded authority goal.

The re-planning case is equally challenging. An agent plan that looked like three steps may turn into seven steps because the first three uncovered new information. The Mission approved the three-step view. The seven-step execution may be well within the spirit of the original approval but exceed the compiled authority in specific ways. The architecture’s answer is expansion proposals. But expansion proposals require human review cycles, and an agent that hits expansion boundaries mid-execution must either stall, abort, or work around the limitation.

The harder challenge is the model-tool boundary. Mission-Bound OAuth governs which API calls an agent is permitted to make. It does not govern what the model does with the response. An agent can read a file it is authorized to read and then include the contents in a message sent to a recipient outside the Mission’s authority envelope. The OAuth layer never sees that second action as a distinct authorization event. Mission governance is strong at the resource-access boundary and blind to what happens inside the model’s reasoning process.

This creates the illusion of governance:

the system feels governed because the token path is governed, while the runtime still has many ways to drift, cache, fork, or route around the intended control points.

The architecture acknowledges some of this under practical limits, but the problem is structural, not just a matter of deployment discipline.

The Model May Be Too Broad To Standardize Well

Mission-Bound OAuth needs a surprisingly large meta-model:

• purpose classes
• templates
• authority models
• resource selectors
• relationship predicates
• operation groups
• lifecycle states
• approval evidence
• delegation chains
• projection policies
• event semantics

Each piece is individually reasonable. Together they are a substantial standardization surface.

XACML is the historical cautionary example. XACML was technically correct. It modeled the right things: attributes, policies, rules, combining algorithms, obligations. It was too complex for most enterprises to author and maintain in practice. Adoption was thin outside specific regulated verticals. The fundamental problem was not that XACML was wrong but that the surface it standardized was too large to be adopted incrementally.

Mission-Bound OAuth faces a version of the same problem. The likely failure mode is:

• the protocol pieces get standardized at IETF: mission_ref as a token claim, token exchange extensions, lifecycle error codes, introspection fields
• the semantic pieces remain deployment-specific: purpose taxonomy, compiled authority format, relationship predicates, business-event termination conditions
• every implementation uses different authority compilation logic
• interoperability exists at the token-envelope layer, not at the authority layer the architecture actually cares about

If that happens, Mission-Bound OAuth succeeds procedurally and fails substantively. Operators can exchange mission_ref-bearing tokens between any two implementations. But two implementations in the same enterprise still cannot share a Mission, because their compiled authority models are incompatible. The most important interoperability, the kind that makes a Mission’s authority meaningful across system boundaries, never arrives.

The staged adoption path helps with this by starting with AS-side lifecycle and deferring semantic richness. But the semantic richness is the point. A mission_ref that only carries lifecycle state is useful. It is not the Mission Authority Model the document describes.

A Stronger Critique

There is an even harsher version of the argument.

Open-world agents are not primarily a delegated authorization problem. They are a runtime control problem. The question is not only “is the agent authorized to take this action?” The question is “is the agent behaving consistently with what was intended, and how would we know if it stopped?”

Mission-Bound OAuth improves the first question. It does not address the second.

Authorization systems govern boundaries. They answer yes or no at defined checkpoints. Runtime control governs behavior between those checkpoints: whether the agent is reasoning correctly, whether it has been manipulated by content in its context window, whether it is producing outputs consistent with the user’s intent, and whether human oversight is being exercised at the right frequency.

Prompt injection is a concrete example. An agent executing a Mission can be redirected by adversarial content in a tool response. A malicious calendar entry might contain instructions that cause the agent to take actions outside its intended path. The agent’s token requests remain within the Mission’s authority envelope, because the agent is still calling the APIs it is authorized to call. The governance layer never sees the manipulation. The audit trail shows a sequence of authorized actions that, taken together, represent behavior nobody intended to authorize.

Mission-Bound OAuth’s threat model includes actor substitution, confused deputy, and scope creep. It does not have a good answer for adversarial content injection because that threat crosses the model-tool boundary in a way that authorization infrastructure is not designed to observe.

The stronger critique is not that Mission-Bound OAuth is wrong. It is that it may be misframed. If the real problem is runtime control of autonomous systems, then improving OAuth-level credential governance is necessary but far from sufficient. The right starting point is not:

how do we make OAuth carry longer-lived governed authority?

It is:

what authority service governs agent execution, and how do existing protocols consume it?

Those are different architecture questions. The second one does not have OAuth at its center.

A Better Answer: Make Mission a Separate Authority Service

The most plausible better answer is not “throw away Mission.” It is “move Mission out of OAuth.”

In that sense this post is also a return to the original Power of Attorney intuition. The earlier series treated the state owner more like a mandate or authority service that sat above IAM, policy, and orchestration rather than inside one protocol component. Mission-Bound OAuth narrowed that thesis into an AS-centered protocol architecture. The MAS alternative reopens the broader control-plane version of the idea.

The cleaner architecture looks like this:

• a dedicated Mission Authority Service (MAS) owns Mission state
• the MAS handles approval, lifecycle, delegation policy, compiled authority, approval evidence, and business-event termination
• OAuth Authorization Servers call the MAS at issuance and exchange time to check Mission state and authority bounds
• AAuth authorization servers do the same, because the MAS does not care what protocol is presenting the request
• gateways, schedulers, orchestrators, and tool brokers can query the MAS directly for Mission state, without needing an OAuth token in the path
• OAuth becomes one projection and enforcement mechanism, not the canonical home of the authority object

That produces a cleaner split of responsibilities:

This is not a radical departure from the Mission-Bound OAuth architecture. The Mission object, the authority model, the lifecycle states, the approval flow, and the audit trail are all the same. The main change is where they live and which component is authoritative for them. That shift does not make the hard problems disappear. A MAS still has to solve authority compilation, event integrity, actor continuity, lifecycle coupling, and operational resilience. The claim is narrower: if those hard problems must exist somewhere, they may belong in a dedicated governance service rather than inside the OAuth AS.

Cleaner separation of concerns. Mission governance no longer has to be smuggled into OAuth as if it were a token problem. The MAS can be owned by the team that understands workflow and business events. The AS remains the credential issuer it was designed to be. The organizational ownership story becomes much more natural.

Broader applicability. Not every enforcement path in agent systems is an OAuth path. Job schedulers, internal queues, workflow engines, tool brokers, and MCP servers may need Mission state even when no OAuth access token is in the path. If Mission state lives in the AS, those systems either become second-class consumers or start depending on IAM endpoints that were not built for them. If Mission state lives in a dedicated MAS, they can consume the same authority record through a purpose-built API.

Protocol portability. If OAuth remains the dominant enterprise deployment substrate, the MAS becomes the AS’s upstream authority source. If AAuth or something else becomes better suited later, the MAS survives and the transport layer changes underneath it. Part 3 ended with “Mission governance on AAuth” as the cleaner long-term architecture. A Mission Authority Service is what makes that transition possible without rebuilding the governance layer each time.

The practical integration pattern at Stage 1 would look like this: the AS calls GET /missions/{mission_ref} on the MAS at exchange time, the MAS returns current lifecycle state and authority bounds, the AS enforces them in the issued token.

That introduces real costs:

• a new network dependency on the MAS for issuance and exchange decisions
• new consistency requirements between AS caches and MAS state
• a new governance service that now needs the same operational hardening the AS would otherwise need

But those costs buy a cleaner separation of concerns. The critique is not that MAS is easy. It is that its difficulty is more honest: it puts the governance complexity in the layer that actually owns governance rather than embedding it inside the credential issuer.

That is the deeper attraction of MAS. It is not only “Mission state moved out of OAuth.” It is governance restored as a layer above IAM, policy, and orchestration, with each of those systems consuming Mission state rather than one of them trying to become the whole control plane.

An Even More Conservative Answer

There is also a safer answer than either Mission-Bound OAuth or a Mission Authority Service, and it deserves honest consideration.

It is less elegant and less autonomous:

• do not let agents hold much durable delegated authority at all
• keep approvals narrow and frequent
• issue per-step credentials
• require renewed justification often
• treat long-running missions as orchestrated job control, not as persistent delegated continuity

This is the principle of least delegation taken seriously: the right amount of authority is the minimum needed for the next specific action, not the maximum that might be needed across the whole intent.

That model is worse for user experience and agent autonomy. An agent that needs approval for each step is not usefully autonomous. It is also worse for agents that operate in low-latency workflows where human approval introduces unacceptable delay. And it is worse for headless or service-to-service workflows where a user is not in the loop at all.

But it may be better for safety in several important cases.

In regulated environments, the compliance risk from a single governance failure may outweigh the UX cost of frequent re-approval. Finance, healthcare, and government deployments where a single unauthorized action triggers audit findings or regulatory penalties may reasonably decide that per-step credentials are worth the friction. The architecture should say so explicitly rather than treating narrow, frequent approval as a degraded mode.

In high-stakes action domains, irreversible actions, large financial transactions, external communications, code deployments, database modifications, the governance value of a brief approval moment before each action may be much higher than the value of seamless autonomous execution. Governance tradeoffs are not always won by the smoother user experience.

For organizations that are still developing their understanding of how their agents actually behave in production, narrow credentials provide a natural forcing function. You cannot have a runaway agent that accumulates unauthorized capabilities if each capability required its own issuance event. That property is valuable during the early deployment period even if it becomes unnecessary later.

The honest conclusion is that Mission-Bound OAuth and the Mission Authority Service architecture described above are both designed around the goal of making autonomous agents work well under governance. The conservative answer is designed around the goal of not having that problem in the first place. Depending on the deployment context, that may be the right engineering decision.

So Is Mission-Bound OAuth a Bad Idea?

Not necessarily. The honest conclusion is narrower and less flattering than the architecture post itself.

Mission-Bound OAuth may be the wrong answer if the goal is a clean-sheet architecture for agent governance. It may still be a good answer if the goal is to improve governance in OAuth-heavy enterprise infrastructure without replacing the whole stack.

That is a meaningful distinction and it matters for how to read the series.

Mission-Bound OAuth is strongest as:

• a pragmatic retrofit for OAuth-centric environments where replacing the AS is not realistic
• an incremental deployment model where Stage 1 lifecycle and delegation enforcement delivers real value before the full architecture is in place
• an IAM-native improvement to token exchange, lifecycle, and delegated authority continuity that fits existing Okta, Auth0, or Azure AD deployments with extension

It is weakest as:

• a universal architecture for open-world agents operating across heterogeneous systems
• the natural long-term home of the Mission concept, since Mission governance makes sense independent of OAuth
• the only layer at which runtime governance should live, since authorization is necessary but not sufficient for behavioral control

The staged adoption path matters here. A deployment that starts with Stage 1, AS-side Mission lifecycle with a projected mission_ref claim, gets the core lifecycle and revocation property with minimal architectural disruption. That is a real improvement over token-only OAuth even if stages 2 and 3 never arrive. But it is also the strongest evidence that the full architecture may be doing too much. If the most adoptable and defensible part of the design is the smallest AS-side lifecycle layer, that may be a sign that the rest belongs elsewhere.

The answer to that question depends on the deployment. For teams running agent workflows today with no Mission-level lifecycle control, Stage 1 is a clear improvement. For teams evaluating whether to build a full governance infrastructure from scratch, the Mission Authority Service alternative may be worth starting with.

Conclusion

The series has made one consistent claim across all four posts: agent authority needs a durable, governed object, not just a chain of well-formed tokens.

That claim still holds. The critique in this post is not that the claim is wrong. It is that Mission-Bound OAuth may be a reasonable but suboptimal way to realize it.

The most defensible framing for where this lands is:

Mission is the right object. Mission-Bound OAuth may not be the right home.

That leaves three things true at once:

• the Mission model is directionally right
• extending OAuth may be the most practical near-term path for OAuth-heavy deployments
• a separate Mission Authority Service, and eventually Mission governance on AAuth or a successor, may be the better end state

The series ends here. The argument is not that Mission-Bound OAuth solves agent authorization. The argument is that it identifies the right object and may still put it in the wrong place.

The practical test is simpler: is a deployment with Mission-level lifecycle, authority bounds, and delegation control meaningfully better than a deployment without it?

For the problems agent systems actually face today, the answer is still often yes. That does not make Mission-Bound OAuth the best answer. It makes it a plausible transitional one. If a deployment can start from a cleaner Mission Authority Service architecture instead, that may be the better bet.