Proposal: Governance infrastructure extension for MCP tool call boundaries

[victor-davidenko]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Your Idea

The gap

MCP's 2026-07-28 revision drew a deliberate scope line: MCP connects applications to data and tools. Identity, observability, and governance are outside the core protocol. The OAuth 2.1 profile and EMA/ID-JAG handle authentication and transport-layer authorization. The stateless transport model removed sessions entirely, requiring that all context travel with each request.

This leaves a structural gap between "is this caller authorized to reach this server" (which MCP answers) and "what governance was applied to this tool call, and can a third party verify it" (which nothing in the MCP ecosystem currently answers).

That gap matters now for three reasons.

First, MCP tool calls increasingly cross organizational boundaries. When Organization A's agent invokes a tool hosted by Organization B, both organizations need to answer questions that OAuth tokens cannot: what data classification was applied to the payload, what policies were evaluated, whether the action stayed within the scope the token authorized, and whether the governance decisions can be verified without cooperation from the governed party.

Second, agents compose tool calls into workflows. An agent that calls five tools in sequence, each individually authorized, can accumulate privileges, exhaust budgets, or reconstruct sensitive datasets that no single tool call would have exposed. Per-call authorization does not address per-workflow governance.

Third, regulatory and contractual requirements are arriving that demand independently verifiable evidence of AI agent governance at the action level, including supply-chain governance obligations flowing through procurement contracts. An audit trail produced and signed by the governed party alone cannot satisfy independence requirements.

What a governance extension would cover

The following capabilities describe what governance infrastructure at the MCP tool call boundary would do. Each operates as a distinct module that can activate independently.

Tool call interception and classification. Every tool call crossing the governance boundary is intercepted before reaching the tool. The payload is classified for data sensitivity (PII, PHI, financial data, credentials, adversarial content, customer-defined patterns) before any policy evaluation occurs. Classification output travels with the governance decision, not as a separate metadata stream.

Policy evaluation with mandatory baseline. Two-layer policy architecture. A mandatory organizational baseline applies to every tool call regardless of which agent or tool is involved. Per-agent or per-tool policy adds restrictions within the bounds set by the baseline. The baseline cannot be overridden. This prevents the configuration gap where a misconfigured agent has no policy and defaults to allow.

Identity and entity registration with lifecycle enforcement. Every entity that participates in governed interactions (agents, MCP servers, system triggers) carries a verifiable identity credential with governance-scope attributes embedded in the credential itself. Governance scope, authorization boundaries, data sensitivity ceilings, and compliance regime tags travel with the identity rather than being resolved from an external policy system at runtime. Each entity registers with the governance infrastructure using this identity, and identity is cryptographically verified on every call during runtime, not only at registration. This applies to both sides of every interaction: the calling agent's identity is verified, and the called MCP server's identity is verified. In multi-hop chains where Agent A calls Tool B which triggers Agent C which calls Tool D, every entity at every hop is identity-verified before the interaction proceeds. The chain produces a sequence of verified entities, not a sequence of verified first hops followed by unverified downstream calls. An unregistered entity is blocked. A decommissioned entity is blocked. An entity whose runtime identity does not match its registered identity is blocked. Entity type is set at registration and checked at every runtime interaction. This closes the gap where MCP tool calls arrive with transport-layer authentication (OAuth tokens proving the caller is authorized) but without governance-layer identity (proving what governance scope, constraints, and compliance obligations both parties carry).

Kill switch. Immediate emergency shutdown of governed activity at configurable granularity. A kill switch snapshot is recorded on every governance evidence record so post-incident reviewers can see exactly what emergency controls were active at the time of each decision.

Multi-direction policy evaluation. Independent governance evaluation passes per communication direction. Request-direction governance (agent to tool) applies different policies than response-direction governance (tool to agent). A request might be authorized while the response contains content that should be blocked. Each direction produces a separate signed evidence record linked by a shared workflow identifier.

Cryptographic evidence production. Every governance decision produces a structured, cryptographically signed evidence record. Evidence is signed so that any third party can verify its integrity and authenticity without cooperation from the governed party or the governance infrastructure.

Offline verification. Any party holding the deploying organization's public key can verify the integrity and authenticity of governance evidence records offline, without network access to the governance infrastructure, the tool provider, or any intermediary.

Cross-organizational evidence. When a tool call crosses an organizational boundary, both the calling organization's governance infrastructure and the receiving organization's governance infrastructure produce evidence records for the same interaction. Each organization signs its own records with its own keys. A third-party reviewer can verify both sides independently.

How this relates to existing MCP constructs

This extension would not modify MCP core. It uses the extension mechanism (SEP-2133) to add governance as an optional, independently versioned capability layer.

MCP's OAuth 2.1 profile authenticates callers at the transport layer but does not carry governance-scope attributes: what constraints bind this caller, what data sensitivity ceiling applies, what compliance obligations it operates under. A governance identity layer can bolt on top of existing MCP authentication without requiring changes to the OAuth 2.1 profile. The caller authenticates via OAuth as today. The governance extension adds a verifiable identity credential carrying governance scope, evaluated by governance infrastructure at the tool call boundary. The governance identity layer is independent of whatever authentication mechanism MCP uses, whether OAuth 2.1, TLS certificates, or anything else. Authentication answers "who is calling." Governance identity answers "under what constraints and obligations." The governance extension does not depend on or modify MCP's authentication.

MCP's tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) describe expected tool behavior. This extension produces evidence of what actually happened when the tool was invoked.

The extension is transport-independent. It works with Streamable HTTP and any future transport MCP adopts, because governance operates at the tool call boundary, not at the transport layer.

MCP's stateless request model is architecturally compatible. Governance context (workflow identity, hop chain, policy state) is resolved from durable systems on each call rather than carried in session state.

What exists today

A working implementation of this governance model, built specifically to govern MCP tool call boundaries, is deployed and operational. It intercepts agent traffic, classifies payloads, evaluates policy, enforces kill switches, produces signed evidence packs, and supports offline verification through an open-source verifier.

The verifier is published at https://github.com/scarpprotocol/scarp-verify (Go, zero external dependencies, Apache 2.0). It performs offline cryptographic verification of governance evidence packs. Sample evidence packs demonstrating the full evidence structure are included.

The architectural treatment is published at https://scarpprotocol.com/ with a companion paper at https://doi.org/10.5281/zenodo.21927017.

Related work on the evidence independence problem and composition governance is in Issues #24, #25 and forthcoming contributions on the OpenSecureAIAlliance/RFCs repository.

What this proposal asks

I am proposing that governance infrastructure at MCP tool call boundaries be considered as a candidate extension under the SEP-2133 framework. The specific questions:

Is there interest in a governance extension within the MCP ecosystem that covers interception, classification, policy evaluation, kill switches, entity lifecycle, multi-hop governance, and independently verifiable evidence production?
Is the extension mechanism (reverse-DNS identifier, independent versioning, separate repository) the right vehicle, or does this scope warrant a working group or a separate AAIF project proposal?
Are there existing working groups, SEPs, or discussions addressing parts of this space that this work should align with?

I am an independent researcher with a working implementation covering the full capability set described above. This is an architectural contribution. The verifier is open source and the evidence format is published. I am prepared to draft the extension specification if there is community interest.

Victor Davidenko, independent researcher https://scarpprotocol.com/

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other