Implementing Mission Architecture End to End

The architectural argument in Where Mission Lives in the IAM Stack is that Mission needs a durable state owner. The obvious next question is: what would an end-to-end implementation actually look like?

The rest of this note makes that concrete.

You can build a credible Mission architecture today with OAuth and MCP, but only if Mission is treated as the durable authority record and everything else is treated as a projection or enforcement surface.

What this design gets right that others miss

Before diving in, the six non-obvious choices worth reading carefully:

1. The compiler is the trust boundary, not the model. The shaping model produces a proposal. The compiler turns that proposal into enforceable state using trusted inputs: the resource catalog, policy templates, and deterministic rules. The model cannot grant itself authority by producing a permissive proposal. This is not how most agent systems work today.

2. constraints_hash is a live version handle, not an audit tag. Every enforcement point checks the hash on every request. A stale hash blocks execution. A new hash triggers a fresh policy bundle pull. This is what makes revocation and amendment effective at runtime rather than just in the log.

3. The host queries authority once at authority transitions, not per thought. The capability snapshot model means the host fetches current authority state at session start and when Mission state changes — not on every tool consideration. This keeps MAS off the hot path and makes the system fast enough to use in practice.

4. The commit boundary is owned by the downstream system, not the agent. Irreversible side effects require revalidation at the moment they become real, by a component the agent cannot bypass. This is the only containment boundary that survives prompt injection.

5. Cedar policies are per template class, not per Mission instance. Entity snapshots are per Mission; policies are shared. This means O(templates) policy sets, not O(missions). Amendments change the entity snapshot, not the policy. The system stays evaluable at scale.

6. Approval is either pre-approved patterns or explicit inline user pause. There is no background wait on an unavailable approver. Most work auto-approves. When a human needs to be in the loop, they are the user in the current session. This is the model that actually works in agentic deployments.

How to read this note

This note is doing three jobs at once. Read it in this order:

The simplified core path is:

1. shape the Mission
2. compile and approve it
3. project it into policy and tokens
4. enforce it at host and MCP boundaries
5. refresh and revalidate it when lifecycle, approval, or risk changes

V1 Product Contract

This is the single authoritative statement of what v1 is. An implementation team can build v1 by satisfying everything in this section. Supporting detail is in the sections referenced.

What v1 is:

V1 is done when:

1. The compiler produces a deterministic enforcement bundle with a stable constraints_hash for any input drawn from the v1 template pack
2. Missions move through the full lifecycle (draft → approved → active → completed/revoked) with approval evidence persisted
3. No external tool executes based on tools/list alone — tools/call is Mission-aware and enforces Cedar evaluation
4. Stale constraints_hash blocks execution at the host and at the MCP server
5. Token issuance is audience-specific and reproducible from Mission state
6. Gated actions cannot obtain a commit-boundary pass without a current approval object
7. Commit-boundary actions are non-bypassable — the downstream system of record owns the final check
8. Revocation changes runtime behavior on the next checkpoint (within entity snapshot TTL, not immediately)
9. Signal ingestion is live — anomaly signals flow from host to MAS and affect Mission state
10. The admin console surfaces: active Missions, pending approvals, recent denials, template drift, and emergency controls

What is explicitly out of scope for v1:

• cross-domain federation (ID-JAG, domain-B token exchange)
• sub-agent delegation (child Missions, narrowing proofs)
• asynchronous enterprise approval workflows
• advanced profiles (multi-agent orchestration, broad delegation)
• general-purpose temporary elevation
• custom policy adapters (Cedar only in v1)

If a feature does not appear in the v1 include list above, it is out of scope. Resist including it “just in case” — advanced profile complexity added early is the main reason v1 deployments stall.

Supporting sections:

Build target

This note should be readable as a build handoff. A coding agent implementing this design should be able to identify:

• required components
• required artifacts
• required state transitions
• required enforcement points
• required failure behavior

Anything not tied to one of those should be treated as explanatory context, not as the implementation contract.

The implementation below uses:

• a Mission Authority Service (MAS) as the state owner
• a Mission shaping step that turns user intent into a bounded authority record
• an OAuth authorization server to mint tool-facing tokens scoped to Mission
• MCP servers as the tool transport and tool enforcement surface
• explicit containment at both the tool boundary and the commit boundary
• a Cedar policy layer to evaluate principal, action, resource, and context against the Mission Authority Model

I also looked at the current Model Context Protocol authorization spec, the MCP tools spec, OAuth 2.0 Token Exchange, OAuth 2.0 Rich Authorization Requests, the Cedar policy language, and Anthropic’s Claude Code hooks.

The Concrete Architecture

Use seven components:

That is the minimum shape. Do not collapse it into prompt text and local orchestration state.

Core ERD

This ERD shows the durable records in the simplified core profile.

Runtime Artifact ERD

This ERD shows the narrower runtime objects that enforcement points actually consume.

Required implementation artifacts

The system is not complete until it can produce and consume these artifacts:

Artifact interface contracts

These artifacts need stable wire shapes. A coding agent should not invent them ad hoc.

Mission proposal schema

Produced by the Mission shaper. Consumed by the compiler.

Required fields:

Minimum payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "proposal_id": "prop_01JR9S2N0P",
  "summary": "Prepare the Q2 board packet comparing actuals to plan",
  "purpose": "Prepare an internal board packet for Q2 financial review",
  "requested_resource_classes": ["finance.read", "documents.read", "documents.write"],
  "requested_actions": ["read", "summarize", "draft"],
  "requested_tools": ["erp.read_financials", "docs.read", "docs.write"],
  "stage_constraints": [
    {
      "name": "release_gate",
      "reason": "user asked to review before release"
    }
  ],
  "time_bounds": {
    "requested_ttl_seconds": 28800
  },
  "delegation_bounds": {
    "subagents_allowed": false,
    "requested_max_depth": 0
  },
  "explicit_exclusions": ["publish_external", "pay"],
  "open_questions": [],
  "confidence": "high"
}

Review packet schema

Produced by the compiler. Consumed by human approvers and auto-approval logic.

Required fields:

Minimum payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "review_id": "rev_01JR9S9D1H",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "purpose_class": "board_packet_preparation",
  "summary": "Prepare Q2 board packet comparing actuals to plan",
  "allowed_tools": ["erp.read_financials", "docs.read", "docs.write"],
  "gated_tools": ["docs.publish"],
  "denied_tools": ["email.send_external"],
  "trust_domains": ["enterprise"],
  "risk_level": "medium",
  "risk_factors": [
    {"signal": "destructive_action", "score": 30, "value": "docs.publish"}
  ],
  "recommended_path": "auto_with_release_gate"
}

Governance record schema

Produced by the MAS. Consumed by operators, host, policy services, and audit.

Required fields:

Minimum payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "active",
  "approval_mode": "auto",
  "principal": {
    "user_id": "user_123",
    "agent_id": "agent_research_assistant"
  },
  "purpose_class": "board_packet_preparation",
  "approved_tools": ["mcp__finance__erp.read_financials", "mcp__docs__docs.read", "mcp__docs__docs.write"],
  "actions": ["read", "summarize", "draft"],
  "allowed_domains": ["enterprise"],
  "stage_constraints": [
    {
      "name": "controller_approval",
      "applies_to": ["mcp__docs__docs.publish"]
    }
  ],
  "delegation_bounds": {
    "subagents_allowed": false,
    "max_depth": 0
  },
  "constraints_hash": "sha256-abc123"
}

Approval object schema

Produced by MAS or human approval workflow. Consumed by host, MCP commit boundary, and audit.

Required fields:

Minimum payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "approval_id": "appr_01JR9SQP4W",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "approval_type": "controller_approval",
  "approved_by": "user:controller_42",
  "approved_scope": {
    "tools": ["mcp__docs__docs.publish"],
    "actions": ["publish_external"]
  },
  "status": "granted",
  "issued_at": "2026-04-11T18:10:00Z",
  "expires_at": "2026-04-11T19:10:00Z",
  "constraints_hash": "sha256-abc123",
  "reusable_within_mission": false
}

Runtime signal schema

Produced by host, MCP server, or MAS. Consumed by MAS, caches, PAM, and audit.

Required fields:

Minimum payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "signal_id": "sig_01JR9T3Y2M",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "source": "mcp_server",
  "event_type": "commit.denied",
  "tool": "mcp__docs__docs.publish",
  "resource_id": "mcp__docs__docs.publish",
  "risk_level": "high",
  "timestamp": "2026-04-11T18:12:00Z",
  "correlation_id": "req_01JR9T3W7G"
}

Token projection metadata schema

Produced by the AS alongside token issuance logic. Consumed by MCP servers, downstream APIs, and audit.

Required fields:

Minimum payload:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "projection_id": "proj_01JR9T5N5S",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "constraints_hash": "sha256-abc123",
  "audience": "https://mcp.finance.internal",
  "allowed_tools": ["mcp__finance__erp.read_financials"],
  "allowed_actions": ["read"],
  "allowed_domains": ["enterprise"],
  "issued_at": "2026-04-11T18:15:00Z",
  "expires_at": "2026-04-11T19:15:00Z"
}

These schemas are the minimum contract. They can be extended, but the build should not proceed without stable versions of them.

Tool name forms

Two forms appear in these schemas and should not be mixed within the same field:

• Short form (erp.read_financials, docs.write): used in Mission proposals and review packets, where human readability matters and the canonical resolution has not yet happened.
• Canonical resource ID (mcp__finance__erp.read_financials, mcp__docs__docs.write): used in governance records, compiled tokens, Cedar entities, and any field consumed by enforcement systems. Format is mcp__<server>__<tool> for MCP tools.

The resource catalog is the only translation surface between these two forms. Enforcement systems must always use the canonical resource ID. Any field in a schema above that lists tools for enforcement purposes uses the canonical form. Any field produced by or consumed by the shaper or review UI may use the short form.

Service API contracts

Stable payloads are not enough. The system also needs stable service boundaries.

Use four API groups:

1. MAS Mission APIs
2. approval workflow APIs
3. authorization server APIs
4. signal ingestion APIs

The endpoints below are the minimum useful surface.

MAS Mission APIs

Tenant admin operations (require operator or admin role; user_id from token must have tenant-admin entitlement):

Mission quota and rate limits:

MAS enforces quotas at Mission creation time. Requests that exceed quota receive 429 Too Many Requests with a retry_after field.

Quota limits are configurable per tenant via operator API. The default active-Mission limit of 5 per user is intentionally low — most users doing governed work have one or two active Missions at a time. A user hitting this limit is likely accumulating stale Missions that should be completed or expired.

Minimum POST /missions request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "proposal": {
    "proposal_id": "prop_01JR9S2N0P",
    "summary": "Prepare the Q2 board packet comparing actuals to plan"
  },
  "request_context": {
    "user_id": "user_123",
    "agent_id": "agent_research_assistant",
    "session_id": "sess_123",
    "tenant_id": "acme",
    "entry_channel": "claude_code"
  }
}

Minimum POST /missions response:

1
2
3
4
5
6

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "active",
  "approval_mode": "auto",
  "constraints_hash": "sha256-abc123"
}

Minimum GET /missions/{mission_id} response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "active",
  "approval_mode": "auto",
  "principal": {
    "user_id": "user_123",
    "agent_id": "agent_research_assistant"
  },
  "purpose_class": "board_packet_preparation",
  "approved_tools": ["mcp__finance__erp.read_financials", "mcp__docs__docs.read", "mcp__docs__docs.write"],
  "actions": ["read", "summarize", "draft"],
  "allowed_domains": ["enterprise"],
  "stage_constraints": [
    {
      "name": "controller_approval",
      "applies_to": ["mcp__docs__docs.publish"]
    }
  ],
  "delegation_bounds": {
    "subagents_allowed": false,
    "max_depth": 0
  },
  "constraints_hash": "sha256-abc123"
}

Minimum POST /missions/{mission_id}/derive request:

1
2
3
4
5
6
7
8

{
  "parent_mission_id": "mis_parent_01",
  "requested_tools": ["mcp__finance__erp.read_financials"],
  "requested_actions": ["read", "summarize"],
  "requested_domains": ["enterprise"],
  "requested_expiry": "2026-04-11T20:00:00Z",
  "requested_max_depth": 0
}

Minimum POST /missions/{mission_id}/derive response:

1
2
3
4
5
6
7

{
  "mission_id": "mis_child_01",
  "parent_mission_id": "mis_parent_01",
  "status": "active",
  "constraints_hash": "sha256-child-123",
  "proof_id": "proof_01JR9T1R7W"
}

Minimum POST /missions/{mission_id}/amend request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "amendment_type": "narrowing",
  "reason": "governance operator removed external send scope",
  "delta": {
    "remove_tools": ["mcp__email__email.send_external"],
    "remove_actions": [],
    "add_tools": [],
    "add_actions": [],
    "modify_stage_constraints": [],
    "modify_time_bounds": {}
  },
  "requested_by": "operator:security_ops_42"
}

For broadening amendments, amendment_type is "broadening" and the delta uses add_tools and add_actions. Broadening must go through the approval path.

Minimum POST /missions/{mission_id}/amend response:

1
2
3
4
5
6
7
8

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "amendment_id": "amend_01JR9V8K2P",
  "amendment_type": "narrowing",
  "status": "active",
  "constraints_hash": "sha256-def456",
  "prior_constraints_hash": "sha256-abc123"
}

For broadening amendments that require human approval, the response status will be pending_approval and the prior constraints_hash remains active until approval is granted.

Amendment compiler pipeline:

1. Narrowing: apply the delta directly; run only steps 8-10 of the compiler (enforcement bundle + constraints_hash + persist). No re-shaping, no re-classification, no approval.
2. Broadening: run steps 4-10 of the compiler against the delta only (resolve the added resources, score the delta, build a delta review packet, emit for approval). The existing constraints_hash remains active for the non-broadened scope while the delta is pending.

Minimum POST /missions/{mission_id}/clarify request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "clarification_id": "clar_01JR9S6A1Z",
  "responses": [
    {
      "question": "Which external recipients are in scope?",
      "answer": "investor-relations@acme.com only",
      "resolved": true
    }
  ]
}

Minimum POST /missions/{mission_id}/clarify response:

1
2
3
4
5

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "pending_approval",
  "remaining_open_questions": []
}

After all open questions are resolved, the MAS re-runs approval classification from step 2 (template match) with the resolved fields. If the updated proposal now qualifies for auto-approval, the Mission moves directly to active. If it still requires human review, it moves to pending_approval and a review work item is created.

Minimum GET /missions query parameters:

The caller’s identity (from the bearer token) must match the user_id parameter or the request must be rejected. MAS must not allow cross-user Mission listing.

Minimum GET /missions response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "missions": [
    {
      "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
      "status": "active",
      "purpose_class": "board_packet_preparation",
      "constraints_hash": "sha256-abc123",
      "created_at": "2026-04-11T10:35:00Z",
      "expires_at": "2026-04-11T23:59:59Z",
      "entry_channel": "claude_code"
    }
  ]
}

Session resumption contract:

When a new session needs to resume work on an existing Mission (e.g., after async approval, session timeout, or continuation):

1. The host calls GET /missions?user_id={uid}&status=active with the user’s current session token
2. MAS verifies the caller’s identity matches user_id — the binding is to the authenticated user, not to any session identifier
3. The host finds the Mission by purpose_class or presents the list to the user to select from
4. The host calls GET /missions/{mission_id} to hydrate the full authority record
5. The host re-establishes the local Mission cache: mission_id, constraints_hash, approved_tools, stage_constraints
6. The host proceeds as if the Mission was just activated — there is no “resume session” operation; every session binds to the current Mission state at the time it starts

The session never resumes; the Mission resumes. A new session is always a fresh execution environment that fetches the current capability snapshot before acting. This means a session cannot assume anything about what prior sessions did — it must refresh its planning view from current authority state.

Required behavior:

• POST /missions must fail closed on unknown tools or unresolved clarifications
• POST /missions/{mission_id}/derive must persist a narrowing proof artifact
• POST /missions/{mission_id}/amend with narrowing must produce a new constraints_hash and emit mission.amended immediately
• POST /missions/{mission_id}/amend with broadening must not change the active constraints_hash until approval is granted
• POST /missions/{mission_id}/clarify must re-run approval classification after resolving questions
• POST /missions/{mission_id}/complete must transition status to completed and revoke all active tokens for this Mission
• GET /missions must enforce that the caller can only list their own Missions
• suspend and revoke endpoints must emit lifecycle signals
• POST /missions/{id}/pause blocks token issuance and tool execution; emits mission.paused with source user; does not change constraints_hash; can only be lifted by the same user via POST /missions/{id}/resume — not by operator suspend/lift flow
• POST /missions/{id}/resume on a user-paused Mission re-activates token issuance; emits mission.resumed; does not re-run approval classification
• POST /missions/{id}/clone runs the full compiler pipeline against the current catalog and template version using the approved scope of the source Mission as the proposal input; does not skip compilation or approval — the result may differ from the original if the catalog or template changed
• POST /missions?mode=preview runs steps 1-9b of the compiler pipeline; returns the review packet and recommended approval path; persists nothing; no mission_id is created; the response includes a preview_id that can be passed to a subsequent POST /missions call to skip re-shaping (the compiler re-runs from the preview result rather than re-calling the shaper)

Approval workflow APIs

Minimum approve request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "approved_by": "user:controller_42",
  "approval_type": "controller_approval",
  "constraints_hash": "sha256-abc123",
  "approved_scope": {
    "tools": ["mcp__docs__docs.publish"],
    "actions": ["publish_external"]
  },
  "expires_at": "2026-04-11T19:10:00Z"
}

Minimum approve response:

1
2
3
4
5
6

{
  "approval_id": "appr_01JR9SQP4W",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "active",
  "constraints_hash": "sha256-abc123"
}

Minimum deny response:

1
2
3
4
5
6

{
  "review_id": "rev_01JR9S9D1H",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "denied",
  "reason": "controller rejected external publication"
}

Required behavior:

• approval requests must be bound to the current constraints_hash
• if the Mission version changed since the work item was created, approve must fail with conflict
• approval grant or denial must emit a signal and invalidate planning caches

Authorization server APIs

These APIs extend standard OAuth (RFC 6749, RFC 8693 token exchange, RFC 7662 introspection) with Mission-specific claims. The full request/response contract is specified below.

Mission-aware introspection response (extends RFC 7662):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "active": true,
  "sub": "user_123",
  "aud": "https://mcp.finance.internal",
  "scope": "mcp.tools.call finance.read",
  "exp": 1744408800,
  "iat": 1744405200,
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "constraints_hash": "sha256-abc123",
  "allowed_tools": ["mcp__finance__erp.read_financials"],
  "stage_constraints": []
}

When the Mission is revoked or the token is invalidated, return:

1
2
3

{
  "active": false
}

Consumers using the opaque token model should treat active: false the same as a stale constraints_hash in the self-contained model: deny the request and emit a signal. The mission_id and constraints_hash in the introspection response are the authoritative liveness signals — not the token’s own exp claim.

Minimum Mission-scoped token request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
  "subject_token": "eyJ...",
  "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "audience": "https://mcp.finance.internal",
  "scope": "mcp.tools.call finance.read",
  "resource": "https://mcp.finance.internal",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "constraints_hash": "sha256-abc123",
  "requested_tools": ["mcp__finance__erp.read_financials"],
  "requested_actions": ["read"]
}

Minimum token response:

1
2
3
4
5
6
7
8
9

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "projection_id": "proj_01JR9T5N5S",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "constraints_hash": "sha256-abc123"
}

Required behavior:

• AS must verify Mission is active and hash-current before issuance
• AS must reject requests for tools or actions outside the current projection
• AS must emit issuance records or projection metadata for audit

Token lifetime defaults:

The expires_in: 3600 in the minimum token response example is a placeholder for documentation. Production deployments should use the 300-900 range for MCP transport tokens. Longer lifetimes require either opaque introspection or synchronous commit-boundary checks to enforce revocation within the token window.

Token refresh strategy:

With 300-900 second lifetimes, the host must refresh tokens proactively. Do not wait for a 401.

Use this refresh rule:

• refresh when remaining token lifetime falls below max(60s, expires_in * 0.2) — that is, with at least 60 seconds remaining or 20% of the original lifetime, whichever is larger
• the host local gateway (or hook script) checks expiry on each PreToolUse event and refreshes before the call if the token is within the refresh window
• do not refresh in the middle of an in-flight tools/call; refresh between calls only
• if a refresh fails, the behavior depends on the risk level of the next call:
  • low-risk read with remaining lifetime > 0: allow the call and retry refresh after
  • any commit-boundary or gated action: fail closed and surface the refresh failure before the side effect becomes real
• if the Mission has been revoked or suspended since the last refresh, the AS will reject the refresh attempt; that rejection is the signal that triggers session shutdown or restricted mode

A refresh attempt is the same token exchange request as initial issuance, using the current constraints_hash. If the Mission has been amended since the last issuance, the refreshed token will carry the updated projection automatically.

Signal ingestion APIs

Minimum POST /signals request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "signal_id": "sig_01JR9T3Y2M",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "source": "mcp_server",
  "event_type": "commit.denied",
  "tool": "mcp__docs__docs.publish",
  "resource_id": "mcp__docs__docs.publish",
  "risk_level": "high",
  "timestamp": "2026-04-11T18:12:00Z",
  "correlation_id": "req_01JR9T3W7G"
}

Minimum POST /signals response:

1
2
3
4
5
6
7
8

{
  "accepted": true,
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "effects": [
    "cache_invalidation",
    "risk_recompute"
  ]
}

Required behavior:

• signal ingestion must be idempotent on signal_id
• MAS must process signals in Mission order where ordering matters
• signal effects that change enforceable state must produce a new constraints_hash

Backpressure and 429 client behavior:

When the ingestion endpoint returns 429 signal_rate_exceeded, the caller must not drop the signal silently. Use the following rules:

Use exponential backoff starting at 1 second with a 2x multiplier and ±20% jitter. Cap individual retry intervals at 30 seconds.

Callers must not retry lifecycle-critical signals synchronously in the middle of a tool call. Queue the signal and continue; the retry happens asynchronously.

Main Path

This is the main build path for the system:

1. shape a Mission proposal
2. compile it into a bounded authority envelope
3. approve or escalate it
4. project it into policy and tokens
5. enforce it at host and MCP boundaries
6. re-evaluate it as Mission state changes

The next sections follow that path in order.

Key Decisions

This design has a few decisions that matter more than the rest. Readers should not have to infer them from the middle of the note.

These defaults are not arbitrary. Changing any of them changes the architecture materially.

On baseline entitlements: the core profile is a narrowing model. Mission does not replace entitlement provisioning; it narrows, stages, and governs already-authorized access at execution time. If a tool requires standing entitlement and the user has it, the compiler may include that tool in the Mission envelope. If a tool requires standing entitlement and the user does not have it, the compiler must not silently widen authority.

There are two supported outcomes:

1. Core profile: fail closed for that tool or resource and surface the gap in the review packet.
2. Advanced profile: mark the request as requiring approved temporary elevation. In that mode, Mission approval does not itself grant access. It authorizes a separate elevation flow through the organization’s entitlement broker, JIT credential service, or target-domain AS. The resulting temporary entitlement must be scoped, time-bounded, auditable, and bound back to the Mission and constraints_hash.

This keeps Mission architecture compatible with existing RBAC or ABAC systems rather than pretending Mission is a replacement for entitlement provisioning.

Layer-by-layer design decisions

This is the compact architectural spine by layer.

Short architectural spine

If you strip the design down to its essentials:

1. shape intent into a bounded proposal
2. compile it deterministically into authority state
3. approve or escalate it
4. project it narrowly into runtime tokens and policy bundles
5. enforce it at host, tool, and commit boundaries
6. keep it current through lifecycle, signals, and revalidation

Decision checkpoints

Before implementation starts, answer these questions explicitly:

1. will the runtime use opaque/introspected tokens or self-contained tokens plus Mission freshness
2. will tokens be held by a trusted local gateway or sender-constrained directly
3. which actions are commit-boundary actions on day one
4. which purpose templates qualify for auto-approval
5. which teams own catalog, templates, approvals, and emergency revocation
6. is the deployment running narrowing-only Missions, or does it support approved temporary elevation as an advanced profile

If those are not decided, the rest of the implementation will drift.

Things not to simplify away

Three places where the design made a harder-but-correct choice that will be tempting to simplify under schedule pressure. Don’t.

1. The capability snapshot model. Teams will be tempted to query MAS on every tool consideration (“let me check if this is allowed first”). Don’t. Build the capability snapshot: query once at session start and after authority transitions, hold it, plan inside it. Per-call MAS queries make MAS a hot-path synchronous dependency that will fail under load and add 50-200ms to every tool decision.

2. Compiler output validation (step 9b). Teams will be tempted to skip the independent validation pass after compilation and just trust that the compiler is correct. Don’t. The constraints_hash proves the bundle is self-consistent; it does not prove the bundle is correct. Step 9b is the one check that catches a compiler bug before it produces a valid-but-wrong hash that auto-approves something it shouldn’t.

3. Commit-boundary lock in MAS, not the host. Teams will be tempted to implement the commit serialization lock in the agent host process or the MCP server. Don’t. A lock that lives in the host or MCP server is invisible to other concurrent sessions against the same Mission. The lock must be in MAS because MAS is the only component with global Mission scope.

Reconciling “MAS owns the lock” with “downstream owns serialization”: these are two different locks at two different scopes, and both must exist.

• MAS advisory coordination lock — prevents two concurrent sessions from simultaneously reaching the commit boundary for the same Mission and both proceeding. This is acquired by the host (via POST /missions/{id}/commit-boundary/acquire) before presenting the step-up prompt, and released after the downstream write completes or times out. It lives in MAS because only MAS has cross-session visibility. It is short-lived (seconds, not the duration of the whole session).
• Downstream idempotency lock — the downstream system of record rejects duplicate or conflicting writes for the same commit_intent_id. This survives MAS lock release. It is scoped to the specific resource or effect, not to the whole Mission.

Both are required. The MAS lock alone does not prevent duplicate writes if the MAS lock is released and a retry occurs. The commit_intent_id alone does not prevent two concurrent sessions from both acquiring the downstream write slot simultaneously. Together they provide: (a) cross-session coordination before the write, and (b) idempotent duplicate suppression at the write itself.

When the MAS advisory lock is unavailable, the host must treat the commit boundary as blocked (fail closed). When only the downstream idempotency lock is unavailable, the downstream system handles the failure per its own protocol.

Architecture positions after deployment pressure

The design started as a clean logical model. Real deployments force a few sharper positions.

These are the positions this note now assumes.

Simplified deployment profile

If the goal is to achieve the same governance objectives with less distributed-systems risk, use this as the default profile:

1. single domain only
2. narrowing-only Missions
3. MAS holds authority state only
4. host consumes one cached capability snapshot per Mission version
5. OAuth audience tokens carry mission_id and constraints_hash
6. host precheck + MCP tools/call enforcement
7. downstream system owns final commit boundary
8. no sub-agents in v1, or only pre-issued child delegation artifacts
9. no cross-domain federation in the core build
10. Cedar is canonical at compile and AS layers; adapters are acceptable elsewhere

This profile keeps the important properties:

• bounded authority
• revocation-aware containment
• audibility and traceability
• distributed ownership of irreversible writes

while removing the most failure-prone parts of the broader design from the first deployment.

V1 product boundary

To keep the first deployment operationally sane, treat v1 as a product with a hard boundary, not as a partial implementation of every future feature.

The recommended v1 product is:

• one enterprise trust domain
• one production host integration
• one OAuth AS mode
• one MCP server family or tightly related tool family
• one approval mode for routine work plus one inline step-up path for gated actions
• one small template pack
• one commit-boundary pattern owned by the downstream system of record

Everything else should be explicitly out of scope for v1:

• cross-domain federation
• asynchronous approval workflows
• broad delegation or multi-agent orchestration
• general-purpose temporary elevation
• multiple competing host integrations in the same first rollout

If a feature does not fit this boundary, move it to an advanced profile instead of letting it complicate the core.

V1 reference stack

For the first real deployment, the recommended reference stack is:

• one host: Claude Code
• one authority service shape: MAS authority state + inline step-up approval
• one AS mode: self-contained JWTs plus freshness checks
• one planning model: capability snapshot refresh at authority transitions
• one tool surface: one MCP server family for the initial template pack
• one commit-boundary owner pattern: downstream system of record owns final write
• one template pack: board_packet_preparation, support_ticket_triage, and draft_and_review

If the implementation cannot be described this concretely, the v1 boundary is still too loose.

Core profile mandatory defaults

V1 has one valid configuration. The following values are non-negotiable for v1. An implementation team may override them for v2 with documented justification — but v1 ships with these values and “we haven’t decided yet” is not an acceptable v1 state for any of them.

Approval model: auto_with_release_gate is the default for all templates. Templates may use auto only when the template’s risk tier is low and the template has no commit-boundary tools. human_step_up is reserved for high-risk templates. These are the only three valid modes — no custom approval modes in v1.

Entity snapshot TTLs:

• default for low-risk reads: 120 seconds
• for token issuance: 0 seconds (live check required)
• for commit-boundary decisions: 0 seconds (live check required) Not configurable per-deployment in v1. These values are locked in the mas.* configuration namespace until production tuning data from a real deployment justifies changing them.

Token lifetime: 300–900 seconds. Default: 600 seconds. Not shorter (impractical refresh overhead). Not longer (widens the revocation gap). The AS may issue shorter tokens for high-risk audiences.

Policy language: Cedar. No custom adapters in v1. Every enforcement point evaluates Cedar policy. If a runtime cannot embed the Cedar library, it calls a sidecar — it does not substitute a custom allow/deny function.

Commit-boundary ownership: the downstream system of record owns the final write. Host and MCP precheck are convenience layers. If a downstream system does not yet own its commit boundary, that tool family is out of scope for v1 — it goes on the v2 backlog after the downstream system implements the boundary.

Capability snapshot refresh: exactly at session start and after authority transitions (Mission activation, amendment, suspension/resumption). Not per-tool-call. Not per-model-thought. Not on a timer. Deviating from this rule either makes MAS a hot-path per-call dependency (bad) or leaves stale snapshots cached too long (bad). Both are wrong.

Anomaly signal weights: use the default values from the mas.* configuration namespace. Do not tune them before running the system in observation mode for at least 30 days on real traffic. Premature tuning of weights produces a classifier that is calibrated to theory rather than real behavior.

Advanced profiles: off by default. No cross-domain federation, no sub-agent delegation, no async enterprise approval in v1. These may not even be implemented — they are out of scope, not just disabled. Implementing them as stubs “just in case” adds complexity that must be maintained and tested without being used.

V1 sequenced build plan

Build in this order. Each step has a minimum acceptance test that unlocks the next step. Do not advance until the acceptance test passes — each step is a load-bearing dependency for the steps that follow.

Step 1 — Resource catalog stub

Build a minimal catalog service with a single hardcoded resource record. The record needs: tool_name, resource_class, trust_domain, data_sensitivity, commit_boundary (bool), allowed_action_classes.

Acceptance test: GET /catalog/resources/{tool_name} returns the record in the correct schema. One test tool per resource class you plan to use in the first template.

Step 2 — Minimal compiler (Phase 0 pipeline)

Build the 3-step Phase 0 pipeline: normalize intent → constrain to catalog → emit enforcement bundle. Skip classification scoring, review packet generation, and validation (steps 2, 4, 5, and 9b). Emit a constraints_hash for the bundle.

Acceptance test: given a natural-language Mission description and a catalog stub, the compiler produces a deterministic enforcement bundle with a stable constraints_hash. Run the compiler twice on the same input; hashes must match. Change one field; hash must differ.

Step 3 — MAS core: Mission lifecycle state machine

Build the Mission state machine: draft → pending_review → approved → active → completed/revoked. Implement POST /missions, GET /missions/{id}, POST /missions/{id}/activate, POST /missions/{id}/revoke. Persist governance records and compiled enforcement bundle.

Acceptance test: create a Mission, advance it through the full lifecycle (draft → approved → active → revoked). Verify state transitions are recorded with timestamps and actor IDs. Verify that activating from draft (not approved) returns an error.

Step 4 — Capability snapshot API

Add POST /missions/{id}/capability-snapshot. Return allowed_tools, gated_tools, denied_actions, constraints_hash, anomaly_flags (empty), session_budget_status (zeroed counters), snapshot_ttl_seconds.

Acceptance test: call the snapshot endpoint for an active Mission; verify the response matches the compiled enforcement bundle. Amend the Mission (trigger a recompile); verify the next snapshot returns the new constraints_hash. Verify the old constraints_hash is no longer returned.

Step 5 — Host hook wiring (Claude Code)

Wire the Claude Code hooks: PreToolUse checks allowed_tools/denied_actions from the cached capability snapshot. PostToolUse increments local budget counters and fires a signal to MAS. Session-start checklist runs in order (see Session start checklist).

Acceptance test: with an active Mission that denies tool_x, issue a call to tool_x via the wired host — verify the call is blocked before reaching the MCP server. With a Mission that allows tool_y, verify the call proceeds. Verify the PreToolUse decision is logged.

Step 6 — Cedar policy evaluation at host

Replace the simple allowlist/denylist check with Cedar policy evaluation. Load the compiled Cedar policy bundle from MAS. Evaluate allow/deny using the Cedar runtime at PreToolUse. Verify constraints_hash from the local bundle matches the Mission’s current hash before evaluating.

Acceptance test: write a Cedar policy that denies finance.read after 5pm (a time-based constraint). Verify the host denies the tool call at 5:01pm. Verify it allows the call at 4:59pm. Verify that presenting an expired bundle (mismatched constraints_hash) causes the host to fetch a fresh bundle before evaluating.

Step 7 — MCP server enforcement

Add tools/call enforcement in the MCP server: validate the OAuth audience token (verify mission_id claim), check constraints_hash against the current Mission, reject calls outside allowed_tools. This is the second enforcement layer after the host precheck.

Acceptance test: bypass the host (call the MCP server directly) with a valid token for Mission A. Verify the MCP server allows calls within Mission A’s allowed_tools. Verify it rejects calls outside allowed_tools even with a valid token. Verify it rejects a token with a constraints_hash that does not match the current Mission.

Step 8 — Commit-boundary integration

Add commit-boundary flow: host acquires MAS advisory lock via POST /missions/{id}/commit-boundary/acquire, presents step-up prompt to user, on confirmation issues commit_intent_id, passes it through to the downstream owner. The downstream owner rejects duplicate commit_intent_id values.

Acceptance test: trigger a gated action. Verify the host surfaces the step-up confirmation prompt before the tool executes. Verify that replaying the same commit_intent_id at the downstream owner returns a rejection. Verify that attempting the commit without acquiring the MAS lock fails.

Step 9 — Signal rail

Wire anomaly signal emission: host fires POST /missions/{id}/signals for the 8 anomaly types. MAS accumulates weights and transitions the Mission to suspended_anomaly when the threshold is exceeded. The capability snapshot reflects the suspension.

Acceptance test: emit repeated repeated_denial signals until the accumulated weight exceeds the suspension threshold. Verify MAS transitions the Mission to suspended_anomaly. Verify the next capability snapshot refresh returns a suspended state. Verify the host blocks further tool calls in the suspended state.

Step 10 — Approval workflow

Add the approval routing service: POST /missions/{id}/submit-for-review creates a work item. Approvers receive notification (email adapter first). POST /approvals/work-items/{id}/approve or /reject transitions the Mission. Auto-approval fires when all auto stage constraints are satisfied.

Acceptance test: submit a Mission for review. Verify a work item appears for the configured approver. Approve via the API. Verify Mission transitions to approved. Verify the approval object is stamped with approver identity and timestamp. Configure a template with approval_required: auto and verify a Mission created from it activates without requiring a manual approval call.

Build order constraints:

• Steps 1–2 are sequential (compiler depends on catalog)
• Steps 3–4 are sequential (snapshot depends on MAS lifecycle)
• Steps 5–6 can overlap (Cedar evaluation replaces the step 5 precheck; run step 5 first to get the wiring right, then swap in Cedar)
• Steps 7–10 are each independently shippable once steps 1–6 are complete
• Do not begin step 10 until step 3’s lifecycle state machine is solid — the approval workflow directly manipulates Mission state

Reference deployment topology

MAS is a logical authority role, not a single monolithic service. Splitting it into adjacent services is the correct production shape. Here is the reference topology:

┌─────────────────────────────────────────────────────────────────┐
│                        MAS Core                                  │
│  Governance records, compiled authority state, lifecycle FSM     │
│  Synchronous write path. Stateful. P0 availability.              │
│  APIs: POST /missions, GET /missions/{id}, POST /missions/{id}/  │
└─────────────┬───────────────────────────────┬───────────────────┘
              │ reads (sync)                  │ publishes bundles
              ▼                               ▼
┌─────────────────────────┐   ┌───────────────────────────────────┐
│  Bundle Distribution    │   │  Approval Workflow Service         │
│  CDN-backed, read-heavy │   │  Human review queue, routing,      │
│  GET /policy-bundle     │   │  notification delivery, work items │
│  Async pull on miss     │   │  POST /approvals/work-items/{id}/  │
└─────────────────────────┘   └───────────────────────────────────┘
              │                               │
              │ consumed by                   │ resolves to
              ▼                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                   Enforcement Points                             │
│  AS token endpoint, MCP servers, host precheck, commit boundary  │
│  Read bundle from distribution layer. Write signals to buffer.   │
└─────────────────────────────┬───────────────────────────────────┘
                              │ signals (async, fire-and-forget)
                              ▼
                ┌─────────────────────────┐
                │  Signal Ingestion Buffer │
                │  Write-heavy, async      │
                │  POST /signals           │
                │  Drains into MAS core    │
                └─────────────────────────┘

Synchronous dependencies (must be available for operations to proceed):

• MAS core: Mission creation, capability snapshot, commit-boundary lock, sub-agent lineage check
• Bundle distribution: first request against a new Mission (cold-start pull)

Async dependencies (degradation is acceptable):

• Bundle distribution after cold-start: subsequent requests use cached bundle
• Approval workflow: pending approval stays pending; existing active Missions continue
• Signal ingestion: signals buffer; MAS core processes when buffer drains

What this means operationally: MAS core and bundle distribution are P0. The approval workflow service and signal buffer can degrade without stopping active Mission execution. Size and replicate accordingly.

MAS centrality mitigation

MAS has high conceptual centrality — almost every design decision references it. The mitigation is not to remove MAS but to classify which decisions actually require a live MAS call vs. which can operate on cached state or entirely locally. This classification determines the real blast radius of a MAS outage.

The practical blast radius of a MAS core outage:

• Existing active sessions with valid cached snapshots continue for up to 120s for read operations
• Token issuance stops immediately (fail closed)
• Commit-boundary actions stop immediately (fail closed)
• No new Missions or session starts succeed
• Signal delivery buffers but does not block active sessions

This is the right failure mode: governance tightens under outage, never loosens. The 120s window for read operations is the designed residual risk window. Shorten it by reducing entity snapshot TTL, at the cost of higher MAS read traffic.

How to reduce MAS centrality without changing the design:

• replicate MAS core with strong consistency reads — most MAS reads are state queries, not writes
• put bundle distribution behind a CDN — the most common read (cached policy bundle) never hits MAS core
• pre-warm capability snapshots for known recurring sessions (e.g., daily scheduled agent jobs) so the session-start MAS call succeeds before the session begins
• use the signal buffer to absorb write spikes rather than hitting MAS core directly on every tool use

Applying the research

The research linked in the earlier Mission-shaping discussion is not being used here as decoration. It drives specific design choices.

In other words, the research is showing up in three places:

1. the compiler turns ambiguous intent into a constrained authority candidate
2. the approval layer decides whether that candidate becomes real authority
3. the runtime layer keeps that authority current as execution changes

Paper-specific contributions

The papers are contributing different pieces of the design.

How IBAC changes the compiler

The IBAC paper is the clearest argument for why the compiler has to produce a concrete authority envelope instead of broad ambient permissions.

We are applying four IBAC-style ideas directly:

1. minimum capability derivation The compiler starts from the narrowest candidate envelope implied by the request.
2. specific resource binding Approval and escalation should name exact tools, resources, or domains where possible.
3. hard deny precedence Organizational deny sets stay outside agent control and cannot be broadened by the model.
4. tool-boundary enforcement Every actual execution path goes through host or MCP authorization checks, not just prompt-time interpretation.

We are not copying IBAC’s exact tuple model, but the design is using the same core idea: derive the narrowest actionable authority set and enforce it deterministically.

How semantic task-to-scope matching changes approval

The semantic task-to-scope matching paper pushes on a real weakness: raw model matching becomes fragile as tasks need more scopes and more combinations.

That is why this design does not stop at “LLM guessed the right scopes.”

Instead, it adds:

• purpose templates
• deterministic resource catalogs
• hard disqualifiers
• review packets
• approval modes

Semantic matching is the front end. It is not the final grant decision.

How CaMeL changes runtime containment

CaMeL’s main contribution is the insistence that untrusted retrieved content should not be able to influence trusted control flow.

That shows up here in three rules:

1. Mission authority is compiled from trusted inputs:
   • user request
   • trusted context
   • policy templates
   • resource catalog
2. untrusted tool output may affect reasoning, but not authority state
3. irreversible actions are rechecked at a non-bypassable commit boundary

That is why the note keeps separating:

• proposal from approval
• token from Mission
• model reasoning from authority state

What we are not taking from the papers

The note is intentionally not doing a few things those papers might tempt readers to assume:

• the LLM is not the policy engine
• one semantic parse is not enough for the whole session
• prompt-injection defense is not treated as sufficient without deterministic enforcement
• cross-domain identity assertions do not carry Mission semantics

The design uses those papers to justify a stricter compiler and enforcement model, not to outsource authority decisions back to the model.

Start With the Shaping Prompt

The first thing to implement is not token exchange. It is Mission shaping.

Here is a practical prompt for Claude or Codex that is good enough to start with.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

You are the Mission Shaper for an autonomous agent system.

Your job is to transform a user request into a structured Mission proposal for governance and enforcement.

Do not plan execution steps in detail. Do not invent permissions. Do not broaden intent.

Produce JSON with these fields:
- purpose: one-sentence statement of what the user is trying to accomplish
- summary: short human-readable description of the Mission
- requested_resource_classes: array of high-level resource classes the task appears to require
- requested_actions: array of high-level action classes
- requested_tools: array of tool categories or named tools if explicitly requested
- stage_constraints: array of stage gates or approval checkpoints implied by the request
- time_bounds: object with any obvious duration or deadline constraints
- delegation_bounds: object with whether sub-agents appear necessary and what limits should apply
- explicit_exclusions: array of actions or resource classes that are clearly out of scope
- open_questions: array of questions that must be answered before approval
- confidence: low | medium | high

Rules:
- Prefer narrower authority over broader authority.
- If the request implies external communication, payment, deletion, publication, or irreversible action, add a stage constraint requiring explicit approval before that action becomes real.
- If the request is ambiguous, put the ambiguity in open_questions rather than expanding authority.
- Do not output markdown. Output JSON only.

This prompt should not be the authority record. Its output is only the proposal.

Pass the template list as context. The shaper prompt above works but it guesses purpose classes blind. The host should fetch GET /templates at session start and inject the template summaries into the shaping prompt before calling the model:

1
2
3
4
5
6
7
8

Available Mission templates for this organization:
- board_packet_preparation: reads finance and document systems; gates publication; auto-approved
- support_ticket_triage: reads/updates tickets, internal notes; partner ticket create; auto-approved for allowlisted partners
- sales_account_research: CRM read, document draft; no outbound; auto-approved
- engineering_release_drafting: issue tracker read, build metadata read, release note draft; auto-approved with publish gate
- vendor_due_diligence: vendor doc read, internal memo draft; no external send; auto-approved

When selecting purpose_class, use only the purpose class names listed above. If the user's request does not match any template, set purpose_class to null and add an open question explaining what type of work this is.

A shaper that receives this context will propose matching purpose classes on the first pass for ~90% of requests that fit known templates, dramatically reducing clarification loops and classification failures. The template list is not trusted input to the compiler — the compiler still validates the match — but it makes the shaper’s output much more likely to be compilable on first attempt.

The shaping model is not a security control. The instructions say “do not broaden intent” but the model will still broaden intent for vague requests, ambiguous phrasing, or any user who writes a wide scope on purpose. A user who writes “help me with the quarterly finance work and also anything else that comes up” will get a broad proposal. The shaper output is untrusted input to the compiler. The compiler is the trust boundary. Hard denies, catalog resolution, and template matching are what constrain authority – not the shaping instructions.

How Intent Gets Compiled

The shaping prompt produces a proposal. The MAS still has to turn that proposal into enforceable state.

This is the part that most systems hand-wave. Do not.

The compiler should be a deterministic pipeline with explicit inputs, transforms, and outputs.

Compiler contract

Required inputs

• Mission proposal
• request context
• resource catalog
• policy templates
• current authority state

Processing

• normalize
• classify
• constrain
• score for approval
• build review packet
• compile enforcement bundle
• compute constraints_hash

Required outputs

• governance record
• policy bundle
• token projections
• host enforcement hints

Failure behavior

• missing required input -> fail closed
• unknown resource class -> fail closed or route to clarification
• no matching template -> restrictive fallback or human review
• invalid compiled state -> do not emit constraints_hash

Acceptance checks

• same input set yields same compiled output
• denied resources do not appear in any token projection
• stage-gated actions appear in governance and enforcement outputs
• compiled hash changes whenever enforceable state changes

Compiler inputs

The compiler should receive at least these inputs:

1. Mission proposal Output from the shaping model.
2. request context
   • user identity
   • agent host identity
   • channel or entry point
   • current session ID
   • tenant or organization
3. resource catalog The registry that maps real tools, APIs, datasets, folders, and domains into internal resource classes.
4. policy templates Organizational defaults for low-risk work, stage gates, partner-domain rules, data handling, and delegation.
5. current authority state Existing Missions, approvals, suspended domains, risk flags, and business events already attached to the user or agent.

If one of those inputs is missing, the compiler should fail explicitly rather than quietly broadening authority.

Purpose classification algorithm

The compiler needs an explicit classification procedure for purpose_class.

Use this sequence:

1. the shaping model proposes the top 3 candidate purpose classes with confidence
2. the deterministic matcher scores each candidate against:
   • requested tools
   • requested actions
   • trust domains
   • keywords in the summary
   • historical template fit if allowed
3. apply tie-break rules:
   • prefer narrower purpose class
   • prefer enterprise-local over cross-domain when both fit
   • prefer templates with fewer allowed actions
4. if the top score is below the confidence threshold, route to clarification
5. if the top two scores are too close, route to clarification or review

Minimum scoring contract:

1
2
3
4
5
6
7
8

{
  "candidate_purpose_classes": [
    {"purpose_class": "board_packet_preparation", "model_score": 0.81, "rule_score": 0.92},
    {"purpose_class": "financial_analysis", "model_score": 0.74, "rule_score": 0.66}
  ],
  "selected_purpose_class": "board_packet_preparation",
  "selection_reason": "narrower matching template with stronger tool fit"
}

Required behavior:

• no classifier result may broaden authority by itself
• unknown or low-confidence classifications must fail into clarification or review
• classification output must be persisted for audit

Purpose classifier inputs

The classifier should run on a fixed input object, not on raw prose alone.

Minimum input:

1
2
3
4
5
6
7
8
9

{
  "proposal_summary": "Prepare the Q2 board packet comparing actuals to plan",
  "requested_tools": ["erp.read_financials", "docs.read", "docs.write"],
  "requested_actions": ["read", "summarize", "draft"],
  "requested_domains": ["enterprise"],
  "explicit_stage_constraints": ["release_gate"],
  "user_channel": "claude_code",
  "tenant_id": "acme"
}

The classifier should not read runtime tool output, prior agent chain-of-thought, or arbitrary retrieved content. Classification is based on trusted shaping output plus trusted catalog context.

Purpose classifier thresholds and tie-breaks

Use explicit thresholds so the implementation behaves predictably.

These thresholds are calibration anchors, not production values. The specific numbers (0.80, 0.65, 0.10) have no empirical basis. A greenfield deployment has no request distribution data to derive them from. In practice, the first few hundred real requests will surface patterns that score at 0.78 (just below threshold) for routine work, or 0.82 for genuinely ambiguous requests. Treat these numbers as the starting shape and budget explicit calibration time – collect rejected/clarification outcomes, compare against what a human would have done, and adjust thresholds before using the classifier for auto-approval decisions. The numbers must be fixed in configuration and versioned. Do not bake them into code.

Tie-break rule: when two candidates are within margin, the tie-break must be deterministic:

1. select the candidate with the fewest allowed tools in the matched template
2. if still tied, select the candidate with the lower aggregate risk score for the matched template
3. if still tied, clarification_required

“Prefer narrower purpose class” is not a decision rule. Narrower allowed-tool count is.

Purpose classifier output contract

The compiler should persist the full classification result, not only the selected class.

Minimum stored result:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "classification_version": "purpose-classifier-v2",
  "selected_purpose_class": "board_packet_preparation",
  "review_recommended": false,
  "clarification_required": false,
  "candidate_rankings": [
    {
      "purpose_class": "board_packet_preparation",
      "model_score": 0.81,
      "rule_score": 0.92,
      "matched_templates": ["board_packet_low_risk_v3"]
    },
    {
      "purpose_class": "financial_analysis",
      "model_score": 0.74,
      "rule_score": 0.66,
      "matched_templates": ["finance_analysis_internal_v2"]
    }
  ],
  "selection_reason": "narrower matching template with stronger tool fit"
}

Compiler outputs

The compiler should produce four concrete outputs, not one vague “approved Mission”:

1. Governance record The approved or pending Mission that humans and operators reason about.
2. Policy bundle Cedar-friendly principal, resource, action, and context projections plus the policy set or template-linked policies to evaluate them.
3. Token projections The narrow claim sets that an AS can embed into MCP transport tokens and direct API tokens.
4. Host enforcement hints Action mappings, commit-boundary flags, safe-mode rules, and signal thresholds that the agent host can apply before a tool call ever leaves the session.

That split matters. The Mission record is what was proposed and approved. The policy bundle is what gets evaluated. The token projection is what gets carried. The host hints are what make containment immediate.

Step-by-step compiler pipeline

Minimum viable compiler for Phase 0: If you are building the first version, you do not need all 10 steps immediately. Start with three:

1. Resolve tools — look up every requested tool in the catalog; fail closed on anything not found
2. Match template — check whether the resolved tool set fits one known template; fail if no match
3. Compute hash — SHA-256 of {allowed_tools, stage_constraints} sorted canonical JSON

That is enough to prove the compiler is deterministic and fails closed — which is the Phase 0 exit gate. Add the remaining steps as you scale. The full pipeline below is the target, not the starting point.

Use a fixed sequence like this.

Step 1: assign stable identifiers

The compiler should first mint or attach:

• mission_id
• request correlation ID
• session ID
• tenant / org ID
• initial proposal_hash

Nothing downstream should rely on raw prompt text as the stable identifier.

Step 2: normalize free-form fields

Convert model-produced prose into stable internal categories.

For example:

• Prepare the Q2 board packet -> purpose_class = board_packet_preparation
• pull final numbers -> action_classes = ["read", "summarize", "draft"]
• call me before releasing -> stage_constraint = release_gate
• might need help from another agent -> delegation_bounds.subagents_allowed = true

Normalization should use:

• internal enums
• catalog lookups
• deterministic mapping rules
• reviewable mapping tables

Do not let every request invent new resource or action categories.

Step 3: resolve concrete resource classes

Take the requested tools or implied systems and resolve them through the resource catalog.

Example:

• erp.read_financials -> finance.read
• docs.write -> documents.write
• docs.publish -> publication.external

At this stage, also attach:

• data sensitivity class
• trust domain
• partner-domain classification
• whether the resource can create an irreversible effect

This is where vague intent becomes real surface area.

Resource catalog schema

The resource catalog needs a stable schema. Without it, compiler outputs will drift.

Minimum catalog record:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "resource_id": "mcp__finance__erp.read_financials",
  "resource_type": "tool",
  "resource_class": "finance.read",
  "trust_domain": "enterprise",
  "data_sensitivity": "internal_financial",
  "commit_boundary": false,
  "aliases": ["erp.read_financials", "finance.actuals.read"],
  "allowed_action_classes": ["read"],
  "owner": "finance-platform"
}

Required behavior:

• every executable tool, API, dataset, folder, and partner domain must have a stable record
• aliases must resolve to one canonical resource_id
• unknown resources must fail closed
• catalog changes must be versioned and auditable

Resource catalog ownership and onboarding

The catalog needs an operational owner. Otherwise the compiler will drift from reality.

Use this ownership split:

Onboarding uses a tiered model. Not every tool needs a full security review before it can be used:

Tier 1 — self-attestation (low-sensitivity internal tools)

An owning team submits a catalog record via POST /catalog/resources. It enters with status: provisional automatically if it meets all of:

• trust_domain: enterprise (internal network only)
• data_sensitivity: internal or lower
• commit_boundary: false
• no external API calls

A provisional record can be used by the compiler for low-risk Mission templates only (templates with aggregate risk score below the medium threshold). The compiler must record that a provisional resource was used; this is surfaced in the approval packet.

Full security review is still required before:

• the record reaches status: approved
• the resource is usable in medium-risk or high-risk Mission templates
• trust_domain, commit_boundary, or data_sensitivity change

Tier 2 — full review (everything else)

1. new tool or API cannot be used until it has an approved catalog record
2. owning team must declare action classes, trust domain, and commit-boundary behavior
3. security or IAM must approve the trust-domain and sensitivity mapping
4. compiler consumes only the published catalog version

What self-attestation does not change: the compiler still fails if a resource is not in the catalog at all. “Not in catalog” is not the same as “provisional”. Self-attestation fast-path requires that the record exists; it just allows provisional use in bounded cases.

Resource catalog service API

The catalog must be a queryable service, not a static file. The compiler and MCP servers need to resolve resources at compilation time and at runtime without reading a local file.

Minimum GET /catalog/resources/{resource_id} response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "resource_id": "mcp__finance__erp.read_financials",
  "resource_type": "tool",
  "resource_class": "finance.read",
  "trust_domain": "enterprise",
  "data_sensitivity": "internal_financial",
  "commit_boundary": false,
  "aliases": ["erp.read_financials", "finance.actuals.read"],
  "allowed_action_classes": ["read"],
  "owner": "finance-platform",
  "mcp_server_url": "https://mcp.finance.internal",
  "catalog_version": "2026-04-11",
  "status": "approved"
}

The mcp_server_url field closes the gap between catalog records and MCP token audiences. The compiler uses it to determine which AS audience to request a token for when a resource is included in a Mission.

mcp_server_url must be verified against the AS audience registry. The AS maintains a registered set of known audiences. Before the compiler emits a token request for a given mcp_server_url, it must verify the URL is registered as a valid audience in the AS. An unregistered URL fails compilation.

Required behavior:

• mcp_server_url changes to an existing catalog record must trigger the same review path as commit_boundary or trust_domain changes — the record returns to pending_review and cannot be used until re-approved
• the AS audience registry and the catalog mcp_server_url field must be reconciled during catalog approval: a catalog record cannot reach approved status if its mcp_server_url is not registered in the AS
• the compiler must reject any mcp_server_url that is not in the AS registered audience set, even if the catalog record is approved

This prevents a compromised or misconfigured catalog record from redirecting valid Mission-scoped tokens to an attacker-controlled server.

AS audience registry spec

The audience registry is owned by the AS team, not the catalog team. This is an intentional separation: the catalog team governs what resources exist; the AS team governs which servers can receive Mission-scoped tokens. A catalog team member with write access to the catalog must not be able to unilaterally register a new token audience.

Component ownership: the audience registry is a service operated by the AS team. It is not a field in the resource catalog. The catalog record’s mcp_server_url is a reference into the registry, not the registry itself.

Registration API:

POST /audiences
Authorization: Bearer <AS admin token>

Request body:

1
2
3
4
5
6
7
8

{
  "url": "https://mcp.finance.internal",
  "display_name": "Finance Platform MCP Server",
  "owning_team": "finance-platform",
  "technical_contact": "finance-platform-oncall@example.com",
  "environment": "production",
  "registration_reason": "Initial registration for Finance ERP tool surface"
}

Response:

1
2
3
4
5
6
7

{
  "audience_id": "aud_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "url": "https://mcp.finance.internal",
  "status": "pending_verification",
  "registered_at": "2025-10-01T10:00:00Z",
  "registered_by": "identity-team-admin"
}

Status transitions: pending_verification → verified (after AS team confirms the URL is reachable, TLS-valid, and controlled by the owning team) or pending_verification → rejected.

Required fields for registration:

Verification process (what the AS team does before verified):

1. Confirm the URL is reachable over HTTPS with a valid certificate matching the domain
2. Confirm the owning team has signing authority over the domain (DNS or certificate ownership check)
3. Confirm the environment matches (production URL must not resolve to a staging host)
4. Record verification evidence (checked by, checked at, evidence type)

Automated verification can handle steps 1 and 3. Step 2 and step 4 require manual confirmation for the initial registration. URL changes always require re-verification.

Catalog approval gate:

The catalog approval workflow must call GET /audiences?url={mcp_server_url} before approving any catalog record. If the URL is not present with status: verified, the catalog record must remain in pending_review. The catalog approval UI should surface this as a blocking check: “mcp_server_url not registered in audience registry — contact the AS team.”

Change control for URL changes:

When a catalog record’s mcp_server_url changes:

1. The catalog record returns to pending_review
2. The new URL must be registered in the audience registry and reach verified status before the catalog record can be re-approved
3. The old URL registration is not deactivated automatically — it remains verified until the AS team explicitly deactivates it (there may be other catalog records using the same URL)
4. Token requests using the old URL continue to succeed until the catalog record is re-approved with the new URL

What the registry prevents:

An attacker with catalog write access cannot redirect tokens to a server they control by changing mcp_server_url in the catalog — the change triggers re-review, and the new URL must pass AS verification before it can receive tokens. The catalog record is stuck in pending_review until the registry entry is verified, which requires AS team involvement.

List endpoint:

GET /audiences
GET /audiences?url={url}        (exact URL match)
GET /audiences?owning_team={team}

Returns all audience registrations visible to the caller’s tenant. AS admins see all; catalog owners see records matching their team’s owned catalog entries.

Minimum GET /catalog/version response:

1
2
3
4
5

{
  "version": "2026-04-11T10:00:00Z",
  "version_hash": "sha256-catalog-abc",
  "record_count": 142
}

The compiler should pin the catalog version used for each compilation run and record it alongside the constraints_hash. If the catalog version used changes, the same proposal may compile differently.

Required behavior:

• GET /catalog/resources/{id} must accept both canonical resource_id and any registered alias
• catalog records with status: pending_review must not be used by the compiler
• catalog changes to trust_domain, commit_boundary, or data_sensitivity must require a new security review before status returns to approved
• the compiler must record the catalog_version used in each compilation output

Resource resolution algorithm

Resolution should be deterministic.

Use this order:

1. exact canonical resource_id match
2. exact alias match
3. product-local alias namespace match
4. fail closed

Required behavior:

• fuzzy matching must not be used for executable resources
• if two aliases resolve to different canonical resources, compilation fails
• if a requested tool name maps to a resource with no declared action class for the requested action, compilation fails

Step 4: compute the baseline authority envelope

Build the narrowest authority envelope implied by the request before policy broadens or narrows it.

For a board-packet Mission, that might be:

1
2
3
4
5
6
7
8

{
  "purpose_class": "board_packet_preparation",
  "resource_classes": ["finance.read", "documents.read", "documents.write"],
  "action_classes": ["read", "summarize", "draft"],
  "candidate_tools": ["erp.read_financials", "docs.read", "docs.write"],
  "candidate_commit_boundaries": ["docs.publish", "email.send_external"],
  "candidate_domains": ["enterprise"]
}

This object should still be thought of as a candidate envelope, not yet approved authority.

Step 5: apply organizational constraints

Now apply policy templates and environment rules.

Examples:

• deny by default:
  • hr.read
  • treasury.transfer
  • email.send_external
• require stage gate:
  • external_send
  • final_publish
• reduce maximum time:
  • request asked for seven days
  • org policy caps this purpose class at eight hours
• reduce delegation:
  • request asked for sub-agents
  • org policy allows max depth 1

This is the first point where organizational policy changes the candidate envelope.

Step 6: score for approval mode

The compiler should now produce an approval classification.

A practical scoring shape is:

• risk_level
  • low
  • medium
  • high
• auto_approval_eligible
  • true | false
• required_human_approvals
  • list of approval types
• required_open_questions
  • unresolved ambiguities that block activation

For example:

1
2
3
4
5
6

{
  "risk_level": "medium",
  "auto_approval_eligible": true,
  "required_human_approvals": [],
  "required_open_questions": []
}

or:

1
2
3
4
5
6

{
  "risk_level": "high",
  "auto_approval_eligible": false,
  "required_human_approvals": ["controller_approval"],
  "required_open_questions": ["Which external recipients are in scope?"]
}

This classification should be explainable. Do not emit only a boolean.

Approval decision function

Approval mode should be computed by a deterministic function, not by intuition.

Use this decision order:

1. hard deny check If any hard policy deny matches, result is denied.
2. clarification check If required fields or open questions remain unresolved, result is clarification_required.
3. hard disqualifier check If the request contains any non-auto-approvable element, result is human_step_up.
4. risk threshold check If no hard disqualifier applies, compare aggregate risk score to the auto-approval threshold.

Minimum risk factors (qualitative signal categories):

This table names the signal categories. The scoring model below assigns concrete numeric weights to each category so that the aggregate score can be compared against a threshold.

Required behavior:

• hard denies override every other rule
• hard disqualifiers override aggregate score
• risk score must be explainable in the review packet
• approval mode must be persisted with the evidence record

Approval risk tier model

Assign each Mission to a risk tier based on the signals present. The tier determines the default approval mode. This replaces numeric scoring, which creates false precision without empirical calibration data.

Tier assignment — use the highest-matching tier:

Assignment is worst-case: if any signal maps to HIGH, the Mission is HIGH regardless of other signals. BLOCKED always overrides.

Approval TTL defaults by tier:

Hard deny default set (always BLOCKED regardless of tier):

• treasury.transfer
• admin_change on production systems
• delete on regulated data
• new external domain with destructive scope

Hard disqualifiers bypass tier assignment entirely.

This tier model encodes the same logic as a scoring table but without fabricating numeric precision. The tiers can be calibrated by observing whether MEDIUM Missions are actually being escalated appropriately vs. auto-approving — a much simpler calibration task than tuning numeric thresholds.

Approval work-routing rules

Approval also needs explicit routing.

Minimum routing contract:

If no valid approver route exists, result is denied.

Default approver groups

If the deployment does not already have named approver groups, start with:

Step 7: build the review packet

Before approval, build the object a human or policy engine will actually review.

That packet should include:

• Mission summary
• purpose class
• requested tools and resource classes
• denied items
• stage-gated items
• trust domains involved
• delegation request
• time bounds
• open questions
• risk explanation
• recommended approval path

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "summary": "Prepare Q2 board packet comparing actuals to plan",
  "purpose_class": "board_packet_preparation",
  "allowed_tools": ["erp.read_financials", "docs.read", "docs.write"],
  "denied_tools": ["email.send_external"],
  "stage_gated_tools": ["docs.publish"],
  "trust_domains": ["enterprise"],
  "delegation_bounds": {"subagents_allowed": false, "max_depth": 0},
  "time_bounds": {"expires_at": "2026-04-11T23:59:59Z"},
  "risk_level": "medium",
  "recommended_path": "auto_with_release_gate"
}

This packet is the bridge between model-shaped intent and enforceable authority.

The review packet must also include a purpose class confirmation surface. Before the packet is submitted for approval — auto or human — the compiler must check that the classified purpose class is consistent with the user’s original summary. The check is not a model call; it is a structural check:

• every approved tool must appear in the matched template’s tool set or an explicit delta justification must be present
• every denied tool must be traceable to a hard deny in the template or to an explicit scope exclusion
• if the user’s summary contains signals that the template hard-denies (e.g., summary says “send to our auditors” and template denies send_external), the compiler must emit an open_question asking the user to confirm their intent, not silently proceed on the mis-match

This does not catch all misclassifications — a confident misclassification that fits the template will still pass. But it catches the case where the classified template is structurally incompatible with the user’s stated intent and prevents auto-approval from proceeding on an intent that the approved tools can never satisfy.

Step 8: compile the enforcement bundle

Only after the review packet exists should the compiler emit enforceable artifacts:

• Cedar entities
• Cedar context template
• approved tools
• stage constraints
• domain list
• delegation bounds
• host hints
• token projection templates

Step 9: compute constraints_hash

Hash the compiled enforcement state, not the raw prompt and not the review UI payload.

The hash should cover:

• allowed tools
• allowed resource classes
• action classes
• stage constraints
• delegation bounds
• time bounds
• trust domains
• approval requirements

Computation specification:

1. Serialize the above fields as a single JSON object with keys sorted lexicographically at every nesting level.
2. Serialize arrays in their stable canonical order (tools and resource classes sorted alphabetically, stage constraints sorted by name).
3. Compute SHA-256 over the UTF-8 bytes of the serialized string.
4. Encode as sha256-<hex>.

The determinism requirement is strict: the same compiled Mission state must produce the same constraints_hash on every call and on every node. Any field that is excluded from the hash input is not part of the enforceable state and cannot be used as a versioning signal.

That makes constraints_hash a version handle for what is actually enforceable.

Step 9b: validate compiler output against approval criteria

constraints_hash proves that the enforcement bundle is self-consistent and reproducible. It does not prove the bundle is correct. Add an independent validation pass after compilation, before persistence:

1. Scope containment check: verify that every tool in the compiled allowed_tools set appears in the matched template’s allowed set or in an explicit approved delta. Any tool that appears in the bundle but not in the template or delta is a compiler error — fail compilation.
2. Hard deny check: verify that every tool in the matched template’s hard deny list is absent from allowed_tools. A compiler bug that fails to apply a hard deny must be caught here.
3. Risk score consistency check: verify that the compiled risk_level is consistent with the signals present. If the bundle contains any signal that is a hard disqualifier for auto-approval (e.g., commit_boundary: true on any tool, external domain, destructive action), the compiled approval_mode must not be auto.
4. Stage gate completeness check: verify that every tool in the bundle with commit_boundary: true has a corresponding stage gate entry in stage_constraints.

If any check fails, compilation fails. Log the specific check failure as a compiler.validation_error event. Do not emit a partial bundle.

This validation pass is the thing that catches a compiler bug before it produces an incorrectly permissive hash. A hash is only as safe as the output it was computed from.

Step 10: persist all three layers

Persist:

1. proposal and review artifacts
2. governance record
3. compiled enforcement bundle

You need all three later:

• proposal for audit and dispute resolution
• governance record for operators and humans
• enforcement bundle for host, AS, and MCP consumers

Board-packet compilation example

For the board-packet example, the pipeline should do something like this:

1. shape prompt output into a structured proposal
2. map Prepare a board packet to purpose_class = board_packet_preparation
3. resolve tools:
   • erp.read_financials
   • docs.read
   • docs.write
4. classify domains:
   • all enterprise-local
5. apply defaults:
   • deny email.send_external
   • deny hr.read
   • deny treasury.transfer
6. apply stage gates:
   • controller_approval required for docs.publish
7. cap delegation:
   • subagents_allowed = true
   • max_depth = 1
8. emit:
   • one governance record
   • one Cedar policy bundle
   • one host hint bundle
   • one token projection template for finance MCP
   • one token projection template for docs MCP

That compiler is where local policy and Mission shaping meet. Do not skip it.

Cedar Policy Bundle Distribution

The compiler produces a Cedar policy bundle. That bundle must reach the AS, MCP servers, and agent host before they can evaluate Cedar locally. The distribution model is pull-on-invalidation:

1. Each consumer caches the current bundle keyed by mission_id and constraints_hash.
2. When a consumer receives a constraints_hash it does not recognize — from a token claim, a capability snapshot response, or a signal — it fetches the new bundle from the MAS.
3. The MAS exposes a bundle fetch endpoint:

Minimum response:

1
2
3
4
5
6
7

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "constraints_hash": "sha256-abc123",
  "cedar_entities": [...],
  "cedar_policies": "permit(...) when {...};\nforbid(...) unless {...};",
  "valid_until": "2026-04-11T20:00:00Z"
}

Required behavior:

• consumers must not use a bundle whose constraints_hash differs from the hash on the current token or planning response
• the MAS must reject bundle fetch requests for revoked Missions
• bundle fetch must be authenticated; the consumer must present its own service identity
• valid_until is a hint for cache TTL, not a security boundary; commit-boundary checks must always fetch fresh state

Cold-start bootstrap: every new Mission creates a guaranteed cache miss at every enforcement point. To avoid a pile of synchronous bundle fetch calls on the first request, MAS should push a lightweight activation hint to registered enforcement points when a Mission moves to active. The hint is not the full bundle — it is just a notification that a new Mission is live, so enforcement points can prefetch in the background:

1
2
3
4
5
6
7

{
  "event": "mission.activated",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "constraints_hash": "sha256-abc123",
  "template_class": "board_packet_v1",
  "prefetch_url": "/missions/mis_01JR9S4YDY6QF5Q9Q54M0YB4V1/policy-bundle"
}

Enforcement points that receive this signal before the first request arrives can prefetch the bundle and warm the cache before any tool call comes in. Enforcement points that don’t receive the signal (or are newly brought online) still work correctly — they take the cold-start cache miss and pull on first request. The push is an optimization, not a requirement for correctness.

Propagation lag tolerance: consumers may serve requests from a cached bundle for up to the host policy cache TTL (30-120 seconds) after a constraints_hash change, for low-risk reads only. Token issuance and commit-boundary actions must fetch the current bundle before proceeding. This means two MCP server nodes may briefly diverge on policy for low-risk reads — that is acceptable. They must not diverge on destructive or gated actions.

Entity snapshot TTL: entity snapshots are cached separately from tokens. A token has its own expires_in. An entity snapshot must have its own independent TTL that is not derived from the token lifetime. Required values:

A token with a 15-minute lifetime does not grant a 15-minute entity snapshot validity. The entity snapshot expires independently at 120 seconds. An enforcement point that holds a valid token against a 121-second-old snapshot must pull a fresh snapshot before evaluating, even if the token is valid. This is the only way a narrowing amendment becomes effective at enforcement points before the token expires.

What the MAS Stores

After shaping, the MAS should store two related objects:

1. Approved Mission
2. Mission Authority Model

The approved Mission is the governance record. The Mission Authority Model is the thing enforcement systems can actually consume.

Start with a narrow schema.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "principal": {
    "user_id": "user_123",
    "agent_id": "agent_research_assistant"
  },
  "purpose": "Prepare a board packet comparing Q2 actuals against plan.",
  "resource_classes": ["finance.read", "documents.read", "documents.write"],
  "actions": ["read", "summarize", "draft"],
  "approved_tools": ["erp.read_financials", "docs.read", "docs.write"],
  "stage_constraints": [
    {
      "name": "release_gate",
      "required_approval": "controller_approval",
      "applies_to": ["external_send", "final_publish"]
    }
  ],
  "delegation_bounds": {
    "subagents_allowed": false,
    "max_depth": 0,
    "inherit_by_default": false
  },
  "time_bounds": {
    "expires_at": "2026-04-11T23:59:59Z"
  },
  "status": "active",
  "constraints_hash": "sha256-abc123"
}

This is enough to be useful. It does not need to be a universal policy language.

Mission Approval Paths

The MAS should not do “approval” as a single yes/no. It should run a fixed approval procedure and record every decision point.

Approval contract

Required inputs

• compiled review packet
• approval templates
• hard disqualifier rules
• current authority state
• approver routing rules

Processing

• check clarification blockers
• match template
• evaluate hard disqualifiers
• choose approval mode
• activate or create review work item
• record approval basis

Required outputs

• approval mode
• Mission status
• approval work item or active Mission
• approval evidence
• current constraints_hash

Failure behavior

• unresolved open question -> pending_clarification
• hard deny -> denied
• no valid approver route -> denied
• expired review item -> remain non-active

Acceptance checks

• auto-approved Missions always identify approving policy
• step-up Missions always identify approver type and reason
• no gated token issuance occurs while status is non-active
• approval evidence references the exact Mission version approved

The minimum useful paths are:

1. organizational auto-approval
2. human step-up approval

Step-by-step approval procedure

Use an ordered approval flow like this.

Step 1: check for blocking open questions

Before approval, the MAS should ask:

• are there unresolved open questions from shaping?
• are required fields missing?
• is the target domain ambiguous?
• is the external recipient set unknown?

If yes:

• status = pending_clarification
• no Mission-scoped token issuance
• host remains in restricted planning mode

Do not auto-approve an ambiguous Mission.

pending_clarification exit rules:

A Mission must not stay in pending_clarification indefinitely. Required constraints:

After the maximum rounds or timeout, the Mission transitions to denied automatically. The MAS emits mission.denied with reason: clarification_timeout or reason: clarification_rounds_exceeded.

Who can close an open question: only the authenticated user who submitted the Mission (matched by user_id from the original POST /missions request context). The shaper model cannot close open questions — it can suggest answers in a clarification prompt, but the answers must come from the user via POST /missions/{id}/clarify. This is the adversarial-model-safe rule: if a prompt injection causes the shaper to add spurious open questions, only the real user can resolve them, and the Mission expires if they don’t.

Open question count limit: if the shaper emits more than 5 open questions on a single Mission proposal, the MAS must treat this as a classification failure and return status: denied with reason: excessive_ambiguity rather than entering pending_clarification. A proposal with 5+ unresolved questions is not a Mission candidate — it is an unformed request.

Step 2: match against an approval template

Take the compiled review packet and try to match it against an organizational template.

A template might say:

• purpose class = board_packet_preparation
• domains = enterprise only
• actions subset of read, summarize, draft
• tools subset of erp.read_financials, docs.read, docs.write
• no destructive action
• no external communication
• max runtime = 8 hours

If all of those match, the Mission can stay on the auto-approval path.

Step 3: evaluate hard disqualifiers

Even if a template mostly matches, the MAS should immediately disqualify auto-approval for:

• external publication
• new partner domain
• payment or funds movement
• destructive deletion
• admin or privileged infrastructure change
• high-sensitivity data access outside standing policy
• delegation depth beyond policy maximum

This avoids “mostly low-risk” requests sneaking through as auto-approved.

Step 4: determine approval mode

At this point the MAS should emit one of:

• approval_mode = auto
• approval_mode = human_step_up
• approval_mode = clarification_required
• approval_mode = denied

This should be an explicit field in the governance record, not an inferred state.

Step 5: if auto-approved, activate immediately

For auto-approved Missions, the MAS should persist:

1
2
3
4
5
6
7
8

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "approval_mode": "auto",
  "approved_by": "org_policy:board_packet_low_risk_v3",
  "approved_at": "2026-04-11T10:35:00Z",
  "status": "active",
  "constraints_hash": "sha256-abc123"
}

Then it should emit:

• active Mission record
• policy bundle
• host hint bundle
• token projection templates

This should be common for low-risk read, summarize, and draft work inside known enterprise boundaries.

Step 6: if human approval is required, create an approval work item

For step-up cases, the MAS should create a review object for the human approver.

That object should include:

• Mission summary
• exact tools and resource classes requested
• denied items
• stage-gated items
• trust domains involved
• delegation requested
• time bounds
• why auto-approval failed
• recommended approve / deny decision

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "review_id": "rev_01JR9S9D1H",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "approval_mode": "human_step_up",
  "required_approval": "controller_approval",
  "reason": "external publication requested",
  "allowed_tools": ["erp.read_financials", "docs.read", "docs.write"],
  "gated_tools": ["docs.publish"],
  "denied_tools": ["email.send_external"],
  "risk_level": "high"
}

Step 7: move Mission into a controlled pending state

When step-up is required, the MAS should persist:

1
2
3
4
5
6
7

{
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "approval_mode": "human_step_up",
  "status": "pending_approval",
  "required_approval": "controller_approval",
  "reason": "external publication requested"
}

While pending:

• the host should block tool calls outside a small safe set
• the AS should refuse Mission-scoped token issuance for gated actions
• the MCP layer should treat the Mission as non-active
• sub-agent derivation should be blocked unless separately approved

Step 8: on human decision, emit a state transition

If the human approves:

• attach approval object
• update status to active
• if approval changes enforceable state, emit a new constraints_hash
• invalidate host, AS, and MCP caches

If the human denies:

• status = denied
• no Mission-scoped token issuance
• host exits restricted planning mode and surfaces denial

Step 9: record approval basis

Whether approval was automatic or human, the MAS should always record:

• who or what approved it
• which policy or review object was used
• exact approval timestamp
• any stage gates that still remain
• the constraints_hash that was approved

That is the audit basis for every downstream action.

Auto-approval example

This should be common for low-risk work:

• approved tool families only
• approved data classes only
• no external communication
• no destructive action
• no privileged admin action
• no cross-domain access outside an approved partner set
• time bound within policy maximum

Example result:

1
2
3
4
5
6
7

{
  "approval_mode": "auto",
  "approved_by": "org_policy:board_packet_low_risk_v3",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "active",
  "constraints_hash": "sha256-abc123"
}

Human step-up example

Common escalation triggers are:

• external communication
• publication
• payment
• deletion
• admin or infrastructure change
• high-sensitivity data classes
• cross-domain access to a domain without standing policy
• sub-agent delegation beyond the normal bound

Example result:

1
2
3
4
5
6
7

{
  "approval_mode": "human_step_up",
  "mission_id": "mis_01JR9S4YDY6QF5Q9Q54M0YB4V1",
  "status": "pending_approval",
  "required_approval": "controller_approval",
  "reason": "external publication requested"
}

Once a human approves, the MAS emits a new state and often a new constraints_hash. That should invalidate caches and force fresh evaluation before work resumes.

Honest model of approval timing

The pending_approval state sounds like the agent waits in the background while a reviewer receives a notification, deliberates, and returns an answer. That is not a realistic operational model for most deployments.

In practice, approval works in one of two ways:

Pre-approved patterns (the common case). The approval is not an event — it is a pre-existing organizational decision. The template was reviewed and approved by a policy owner. The criteria are known and fixed. Auto-approval is just the runtime confirmation that this specific request fits the pattern. The user does not wait; execution starts immediately.

Explicit user-controlled pause (the realistic step-up case). When a request crosses a threshold that requires human judgment, the agent stops and surfaces the situation to the user in the current session. The user is the approver. They review the review packet inline and confirm or deny before execution continues. This is not a background notification flow — the agent is blocked in the user’s session until the user responds.

What does not work in practice: creating a pending state that blocks execution while waiting for an asynchronous approver who may not respond for hours or days, in a context where the model session may have expired. Do not build systems that assume an available approver who responds within a predictable SLA unless that approver is a webhook into an existing ticketing or compliance system with known routing and response behavior.

If you need asynchronous approval, that is a first-class architectural decision: the Mission is submitted, the session ends, and a new session begins after approval. The implementation must handle session resumption from approved Mission state rather than trying to keep a pending agent session alive indefinitely.

auto vs. auto_with_release_gate: side-by-side comparison

These two approval modes are easily confused. Both allow the Mission to activate immediately without human step-up. The difference is in which tools become available immediately.

auto — board_packet example:

The board_packet_preparation template with approval_required: "auto" and no stage gates. When activated:

• All tools are immediately available: finance_query, docs_editor, docs_publish
• The model can call docs.publish without any further approval
• Use this only when the organization explicitly trusts that an auto-approved board packet Mission should publish without a human checkpoint

auto_with_release_gate — board_packet example (the correct default):

The board_packet_preparation template with approval_required: "auto_with_release_gate" and a controller_approval stage gate on docs.publish. When activated:

• Read and draft tools are immediately available: finance_query, docs_editor
• docs.publish is in gated_tools — the token is issued, but the commit-boundary check requires approvals.contains("controller_approval") before the publish executes
• The model can plan, draft, and research freely; when it reaches the publish step, it surfaces a step-up prompt
• Once the user or Finance Controller approves, docs.publish executes

Why auto_with_release_gate is the right default for most internal workflows:

It allows the agent to do all preparatory work without blocking on approval, while reserving the approval gate for the moment an irreversible side effect is about to happen. This is better UX than human_step_up (which requires approval before the agent can do anything) and safer than auto (which lets side effects happen without any human checkpoint).

Starter template pack — correct approval modes:

Compilation and approval sequence

Template Building

The compiler and approval flow depend on templates. If template building is weak, the whole system becomes ad hoc review plus brittle policy code.

Treat templates as first-class governed artifacts.

For the core profile, keep templates thin. A template should define the work-pattern envelope:

• allowed tool families
• denied tool families
• gated actions
• max duration
• whether delegation is allowed
• review route

Do not force templates to encode all backend resource semantics. Keep resource-instance detail in the catalog, backend authorization, and FGA layers. Thin templates age better and are easier to govern.

Starter template pack

If the goal is to get a real system running, start with this baseline. It is broad enough to cover the most common internal workflows and narrow enough to be governable without extensive policy work upfront.

That is enough to start without pretending every workflow has to be templated on day one.

What a template is

A template is not just a Cedar policy snippet.

A useful Mission template bundles:

1. purpose classification Which user requests this template applies to.
2. allowed resource classes Which systems and data classes are normally in scope.
3. allowed action classes Which kinds of actions are normally permitted.
4. default tool set Which tools or MCP surfaces are the normal execution path.
5. hard denies Which tools, actions, or domains are never allowed under this template.
6. stage gates Which actions require approval even if the Mission is auto-approved overall.
7. delegation bounds Whether sub-agents are allowed and at what depth.
8. time bounds Maximum lifetime and approval TTL defaults.
9. cross-domain rules Which partner domains are allowed and under what conditions.
10. review routing Which human approver type should receive a step-up request.

That means a template is closer to a policy package than to a single rule. In the simplified profile, start with the first six fields and add the rest only when a real deployment need appears.

Start from approved work patterns

Do not build templates from abstract IAM theory alone. Build them from common, already-accepted work patterns.

Examples:

• board packet preparation
• sales account research
• support-ticket triage
• engineering release drafting
• vendor due diligence

For each pattern, capture:

• what users actually ask for
• what tools they actually need
• what data classes are normally touched
• where irreversible actions happen
• what should always require human approval

This is the raw material for the template.

Template authoring procedure

Use a repeatable authoring flow.

Step 1: define the purpose class

Give the template a stable purpose identifier:

• board_packet_preparation
• support_ticket_triage
• vendor_security_review

This becomes the anchor for matching, review, and reporting.

Step 2: define the normal authority envelope

Specify:

• allowed resource classes
• allowed actions
• default tools
• expected trust domains
• maximum lifetime

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "template_id": "tpl_board_packet_v3",
  "purpose_class": "board_packet_preparation",
  "allowed_resource_classes": [
    "finance.read",
    "documents.read",
    "documents.write"
  ],
  "allowed_action_classes": [
    "read",
    "summarize",
    "draft"
  ],
  "default_tools": [
    "erp.read_financials",
    "docs.read",
    "docs.write"
  ],
  "allowed_domains": ["enterprise"],
  "max_duration": "8h"
}

Step 3: define the deny set

Every template should name the things it excludes, not just the things it allows.

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "denied_tools": [
    "email.send_external",
    "treasury.transfer",
    "hr.read"
  ],
  "denied_action_classes": [
    "delete",
    "pay",
    "admin_change"
  ]
}

This matters because it prevents later broadening by omission.

Step 4: define stage gates

Templates should separate:

• actions that are allowed outright
• actions that are allowed only after a checkpoint

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "stage_gates": [
    {
      "name": "release_gate",
      "approval_type": "controller_approval",
      "applies_to_tools": ["docs.publish"],
      "applies_to_actions": ["publish_external"]
    }
  ]
}

This is where auto-approval and human approval coexist in the same template.

Step 5: define delegation defaults

For each template, decide:

• whether sub-agents are allowed
• what max depth is allowed
• whether child Missions can cross domains
• whether child Missions can reach commit boundaries

Most templates should be conservative here.

Step 6: define cross-domain rules

If the template can cross trust domains, specify:

• which partner domains are allowed
• whether ID-JAG is permitted
• what local scopes are typically requested in the target domain
• which cases still require human approval

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "cross_domain_rules": [
    {
      "domain": "payroll-partner.example",
      "allowed": true,
      "exchange_mode": "id_jag",
      "allowed_actions": ["ticket.create"],
      "requires_human_approval": false
    },
    {
      "domain": "signing.example",
      "allowed": true,
      "exchange_mode": "id_jag",
      "allowed_actions": ["signature.submit"],
      "requires_human_approval": true
    }
  ]
}

Step 7: attach review routing

When step-up happens, the system should already know where the approval request goes.

Examples:

• controller_approval
• security_approval
• manager_approval
• vendor_owner_approval

This should be part of the template, not recomputed ad hoc every time.

Starter review routes

Use a small default approver set first:

Do not introduce many specialized approver types until the first baseline is stable.

Recommended initial template defaults

Use these defaults unless a business process requires something broader:

Session budget fields

Templates carry per-session budget limits. Budgets serve two purposes: (1) they narrow the exposure window for instruction-sequence attacks by bounding total agent activity, and (2) they give operators a knob to prevent runaway agents.

Add these fields to every template definition:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "session_budgets": {
    "max_reads_per_resource_class": {
      "finance.read": 100,
      "hr.read": 50
    },
    "max_external_calls_per_session": 20,
    "max_wall_clock_duration_seconds": 28800
  }
}

Behavior when a budget is reached: MAS transitions the Mission to suspended_budget. The host surfaces: “I’ve reached the session limit for [resource class / external calls / time]. Confirm to continue.” The user resumes with POST /missions/{id}/resume, which resets the relevant counter with explicit user acknowledgment logged to the Mission audit trail.

suspended_budget is a sub-state of active. It does not require a new Mission. The audit record includes which budget triggered the suspension and the counter value at suspension time.

Capability snapshot interaction: the capability snapshot response includes current counter values so the host can warn the user before a hard suspension:

1
2
3
4
5
6
7

{
  "session_budget_status": {
    "finance.read": { "used": 87, "limit": 100, "warning_threshold": 90 },
    "external_calls": { "used": 18, "limit": 20, "warning_threshold": 18 },
    "wall_clock_seconds": { "used": 14400, "limit": 28800, "warning_threshold": 25200 }
  }
}

When used >= warning_threshold, the host should surface a passive warning (“Approaching session limit for finance.read”) before the hard stop.

Session budget counter ownership

The capability snapshot carries authoritative counter values, but something must increment them. The ownership rule is:

The host owns local counter tracking. MAS owns the authoritative count.

Specifically:

1. The host increments local in-memory counters on every PostToolUse event (resource class reads, external calls, wall-clock elapsed).
2. The host reports counter state to MAS asynchronously via POST /missions/{id}/signals — not as a blocking call before each tool response, but after the tool use completes.
3. MAS persists the reported counts and returns the authoritative accumulated total in subsequent capability snapshot responses.
4. The host uses its local in-memory count for within-session enforcement decisions (e.g., blocking a tool call when used >= limit).
5. On session restore (crash/restart), the host pulls the last MAS-authoritative count from the capability snapshot and resumes from there.

This model avoids adding a synchronous MAS round-trip to every tool call while keeping MAS as the durable source of truth.

Failure behaviors:

Report interval: the host should report counter state to MAS at minimum: (a) when the local count crosses a warning threshold, (b) at session end, and (c) every 60 seconds for long-running sessions. Waiting until session end is not sufficient for sessions that exceed max_wall_clock_duration_seconds.

What the MCP server does not own: the MCP server does not track or report budget counters. It may receive tool calls, but the host is the component that sees every tool call across all MCP servers in a session and is therefore the correct aggregation point.

Template governance ownership and cadence

Templates with no named owner, no review cadence, and no deprecation path become brittle policy debt. The governance structure is not optional — it is what prevents the template model from decaying into an ungoverned collection of policy files that nobody audits.

Required ownership fields per template:

Every template definition must carry these fields:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "owner": "finance-platform-team",
  "owner_contact": "finance-platform-oncall@example.com",
  "reviewer": "security-operations",
  "reviewer_contact": "secops@example.com",
  "last_reviewed_at": "2025-10-01T00:00:00Z",
  "next_review_due": "2026-10-01T00:00:00Z",
  "review_cadence": "annual",
  "risk_tier": "medium"
}

owner is the team responsible for keeping the template current and resolving policy questions about it. reviewer is the team that must sign off on changes. For high-risk templates, owner and reviewer must be different teams.

Review cadence rules:

When next_review_due is exceeded by the grace period, the template moves to pending_re_review. Templates in pending_re_review:

• continue to function for currently active Missions
• cannot be used to activate new Missions
• appear in the admin dashboard’s template drift view with an “overdue review” indicator

What a review requires:

A review is not just signing off. The reviewer must:

1. confirm the allowed resource classes still match the intended work pattern
2. confirm the hard deny list still covers the right actions
3. confirm the approval routing still reaches the right approvers
4. confirm the session budget limits are still appropriate
5. run the template simulation against a representative Mission to verify the compiled output looks correct

After confirming all five, the reviewer sets last_reviewed_at to now and next_review_due to the next cadence date. The review event is logged to the audit trail with reviewer identity.

Deprecation path:

When a template is replaced by a newer version:

1. Publish the new template version (board_packet_v4) as draft → active
2. Mark the old version (board_packet_v3) as deprecated
3. Deprecated templates continue to work for active Missions — do not revoke active Missions that were created from the deprecated template
4. Set a deprecated_at and remove_after date on the deprecated template (minimum 30 days notice)
5. On remove_after, the template moves to archived — no new Missions, no active Missions can be created from it
6. The archived template record is retained in the system for audit purposes — it is never deleted

Templates must not jump from active to archived without a deprecation period. A sudden removal is a breaking change for any session that depends on that template being available for cloning or resumption.

What to do when a template has no owner:

Ownerless templates are a governance gap. If a template’s owner is an unmaintained team or alias, it must be assigned a new owner before its next review is due. If no owner can be found, the template must be deprecated — an ownerless template cannot be trusted to represent current policy intent.

Template re-review on capability change

Templates reference catalog resources. When a referenced resource changes in a way that affects the template’s risk profile, the template must be re-reviewed.

Triggering conditions for mandatory template re-review:

Implementation: the resource catalog should emit a catalog.record.changed event when any of these fields change on an approved record. Template management should subscribe to this event and automatically transition affected templates to pending_re_review. Templates in pending_re_review continue to function for currently active Missions but cannot be used to activate new Missions until re-review is complete.

Template owners must be notified when a resource they depend on changes. “We reviewed the template once” is not sufficient — the review is of the template against the resources as they were at review time, not as they are today.

Template discovery API

Templates must be discoverable. Users and hosts cannot use what they cannot see.

GET /templates is tenant-scoped and returns only templates in active status. Templates in draft or deprecated are not returned to end users (operators can see all statuses via admin API).

Minimum GET /templates response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15