Propose five Mission Contract enhancements from implementation experience

[nickgamb-strata]

Summary

Based on our implementation of AAuth Mission Contracts for MCP (Model Context Protocol) tool governance, we identified five optional extensions that address gaps in the current Mission spec (Section 8). All proposals are backward-compatible and complement the existing design.

We originally built a "Desired Outcome Contract" (DOC) protocol for intent-bound authorization. After evaluating both approaches, we aligned with AAuth and migrated our POC to Mission Contracts. These proposals capture the novel concepts from DOC that proved valuable in practice.

Proposed Extensions

1. Tamper-evident mission log via hash chaining — Each audit entry chains to the previous via SHA-256(prev_hash | action | params | result), seeded from the mission's s256. Addresses the lack of integrity mechanisms in the mission log (Section 8.3).

2. Mission template discovery — Optional PS endpoint publishing structured mission templates that help agents compose better proposals. Reduces clarification rounds for first-time interactions.

3. Mission constraint budgets — max_tool_calls and timeout_seconds fields in the mission blob providing hard limits on agent execution, complementing contextual PS governance.

4. Tool ordering constraints — required_predecessors and prohibited_sequences encoding domain safety rules (e.g., must read account before modifying it).

5. Denial category classification — denial_category field on permission responses distinguishing authorization_denied, intent_denied, and trajectory_denied for richer observability.

Reference Implementation

All five proposals are demonstrated in a working POC with a Person Server (Go), MCP Auth Proxy (Python), and Enterprise Ledger (banking MCP server with tools of varying sensitivity). The POC implements the complete AAuth mission flow: template discovery → mission proposal → HITL approval with s256 computation → per-call permission for non-pre-approved tools → hash-chained audit logging. Reference implementation available upon request.

Test plan

• Review each proposal for compatibility with existing AAuth design principles
• Verify proposals don't conflict with planned companion specifications (Section 8.5)
• Consider whether any proposals should be normative vs. informational