MCP Governance: Runtime Accountability for AI Tool Orchestration

1. The Governance Gap in MCP

The Model Context Protocol defines transport for connecting AI models to tools. It does not define accountability: who authorized the tool call, what data was accessed, whether the action was compliant with organizational policy. MCP is plumbing. Governance is what prevents the plumbing from flooding the building.

Without a governance layer, organizations deploying MCP-connected agents face significant operational and regulatory gaps:

• No audit trail of tool invocations. When an agent calls a database query tool or a file-write tool, there is no standard mechanism to record what was called, by whom, or what the outcome was. Forensic reconstruction after an incident requires manual log correlation across multiple systems.
• No policy evaluation at the tool boundary. MCP transports requests but does not evaluate whether a given tool call is permitted under organizational policy. Rate limits, data classification restrictions, and role-based access are left entirely to the tool implementor.
• No evidence chain for regulatory compliance. The EU AI Act (Article 12), NIST AI RMF (Map/Measure/Manage), and CMMC Level 2 all require demonstrable records of AI system behavior. MCP transport logs are insufficient for these requirements.
• No trust verification between agents sharing tools. In multi-agent architectures where agents delegate tool calls to other agents, there is no protocol-level mechanism to verify that the delegating agent is authorized to make that delegation.

These gaps are not theoretical. As MCP adoption accelerates across enterprise AI deployments, the absence of a governance layer creates accumulating compliance debt that becomes increasingly expensive to remediate.

2. OWASP and NSA Guidance

The OWASP MCP Top 10 (beta, 2026) catalogs the most critical risks in MCP deployments. As of publication, over 30 CVEs have been disclosed against MCP implementations, with 43% involving shell injection through tool parameters. The Top 10 includes tool poisoning, excessive permissions, and rug-pull attacks where tool descriptions change between discovery and invocation.

NSA guidance on MCP security emphasizes the need for tool-level access controls, session monitoring, and cryptographic verification of tool provenance. The guidance specifically calls out the risk of unrestricted tool execution in classified and controlled environments.

SWT3 maps directly to both frameworks. For detailed procedure-level mappings, see:

• OWASP MCP Top 10 Mapping - Each OWASP risk category mapped to the SWT3 procedure that provides witnessing coverage.
• NSA MCP Security Mapping - NSA recommendations mapped to SWT3 governance capabilities and configuration options.

Both guides demonstrate that the governance gap identified in Section 1 is not a hypothetical concern but one that standards bodies and national agencies have formally recognized.

3. SWT3 MCP Server: Governance Layer

The @tenova/swt3-mcp server (available on npm and the MCP Registry as io.tenova/swt3-witness) adds three governance capabilities on top of any MCP deployment. It operates as a transparent layer: tool functionality is unchanged, but every invocation is witnessed, policy-checked, and trust-verified.

a) Tool Policy Gates

The .swt3.yaml configuration file includes an mcp_policy section that defines tool-level governance rules. These are evaluated before every tool invocation:

• witnessed_tools - Glob patterns for tools that must be witnessed. Any tool matching these patterns generates an SWT3 Witness Anchor on invocation. Example: ["write_*", "search_*", "execute_*"]
• exempt_tools - Low-risk tools excluded from witnessing overhead. Example: ["list_files", "get_time"]
• max_velocity - Rate limiting expressed as invocations per time window. Example: "4/30s" limits a tool to 4 calls per 30-second window.
• max_chain_depth - Maximum number of sequential dependent tool calls permitted in a single chain. Prevents runaway agent loops.
• tool_allowlist / tool_blocklist - Explicit permit and deny lists. Blocklist takes precedence over allowlist when both are specified.
• fail_secure - When set to true (the default), any failure in the witnessing pipeline blocks the tool call rather than allowing it to proceed unwitnessed.
• rules - Custom governance rules with match conditions, actions, and human-readable reasons. Enables organization-specific policy logic.

b) Session Witnessing

Every tool invocation that matches the witnessed_tools pattern generates a witness anchor under the AI-TOOL.1 procedure. The anchor records the tool name, call ID, and outcome. Each anchor is cryptographically fingerprinted using the SWT3 formula:

SHA256("WITNESS:{tenant}:{procedure}:{factor_a}:{factor_b}:{factor_c}:{timestamp_ms}").hex()[:12]

Anchors are transmitted to the compliance ledger in real time. For high-throughput deployments, anchors are batched and flushed at configurable intervals. The fingerprint formula is locked and produces identical output across all five SWT3 SDK languages (Python, TypeScript, Rust, C#, Ruby).

c) Trust Mesh

Before executing a tool on behalf of an agent, the SWT3 MCP server can verify the agent's trust level against the mesh configuration defined in .swt3.yaml. The trust mesh supports three modes:

• Strict - Untrusted agents are blocked. Tool calls from agents not in the trusted_agents list are rejected with a policy violation reason.
• Permissive - Untrusted agents are allowed but their invocations are flagged in the witness anchor with a reduced trust level.
• Monitor - All agents are allowed. Trust status is recorded in the anchor but no blocking occurs. Useful during initial deployment.

Trust verification uses the AI-TRUST.1 and AI-TRUST.2 procedures to record the verification outcome and any credential exchange between agents.

4. Installation and Configuration

Quick Start

Install and run the SWT3 MCP server directly:

npx @tenova/swt3-mcp

Or add it to your Claude Desktop or MCP client configuration:

{
  "mcpServers": {
    "swt3-witness": {
      "command": "npx",
      "args": ["-y", "@tenova/swt3-mcp"],
      "env": {
        "SWT3_ENDPOINT": "https://sovereign.tenova.io",
        "SWT3_API_KEY": "axm_live_..."
      }
    }
  }
}

The server starts in local mode by default, writing witness anchors to a local WAL (Write-Ahead Log) file. When SWT3_ENDPOINT and SWT3_API_KEY are provided, anchors are transmitted to the compliance ledger for persistent storage and auditor access.

Tool Policy Configuration

Create a .swt3.yaml file in your project root with an mcp_policy section:

mcp_policy:
  witnessed_tools: ["write_*", "search_*", "execute_*"]
  exempt_tools: ["list_files", "get_time"]
  require_trust_level: 2
  auto_witness: true
  block_on_failure: true
  max_velocity: "10/60s"
  max_chain_depth: 5
  fail_secure: true

This configuration witnesses all write, search, and execute operations while exempting read-only utility tools. The require_trust_level of 2 means agents must present a trust credential at level 2 or above. The max_velocity of 10 calls per 60 seconds prevents runaway invocation loops. The max_chain_depth of 5 limits sequential dependent tool calls to prevent unbounded chains.

Validation

Use the built-in doctor command to validate your configuration:

npx @tenova/swt3-mcp doctor

The doctor checks configuration syntax, connectivity to the ledger endpoint, trust mesh consistency, and tool policy conflicts (such as a tool appearing in both the allowlist and blocklist).

5. Competitive Landscape

Several vendors address aspects of AI governance. The following table compares governance capabilities specific to MCP deployments:

ComplyHat focuses on compliance documentation generation rather than runtime witnessing. It does not operate at the tool boundary and cannot produce cryptographic evidence of individual tool invocations. Stratalize targets fintech audit trails with Ed25519 signing but does not provide tool-level policy gates or agent trust verification. Neither offers the clearing-level data classification that regulated environments (CMMC, FedRAMP) require.

6. Procedures for MCP Governance

The following SWT3 procedures are most relevant to MCP deployments. Each procedure defines a specific witnessing obligation that maps to a regulatory requirement:

For the complete procedure registry (47 procedures across 23 namespaces), see the UCT Registry.

7. Architecture

The SWT3 MCP governance layer operates as a transparent intermediary in the MCP request flow. The following describes the end-to-end sequence for a governed tool invocation:

Request Flow

1. Tool Request. The MCP client (such as Claude Desktop, a custom agent, or another MCP client) sends a standard MCP tool invocation request to the SWT3 MCP Server.
2. Policy Evaluation. The server loads the mcp_policy section from .swt3.yaml and evaluates the request. It checks the tool name against witnessed_tools, exempt_tools, tool_allowlist, and tool_blocklist. It checks the current invocation rate against max_velocity and the chain depth against max_chain_depth. Custom rules are evaluated in order.
3. Trust Verification. If require_trust_level is set, the server checks the calling agent's credentials against the trusted_agents configuration. The verification outcome is recorded via AI-TRUST.1. In strict mode, untrusted agents are blocked at this step.
4. Tool Execution. If the policy allows the request, the tool executes normally. The SWT3 server does not modify tool behavior or intercept tool data beyond what is required for witnessing at the configured clearing level.
5. Witness Anchor Minting. After execution, an AI-TOOL.1 witness anchor is minted. The anchor contains the tool name, call ID, outcome, and a cryptographic fingerprint. The clearing level determines how much detail is preserved in the anchor (Level 0 retains analytics metadata only; Level 3 retains full classified-grade detail).
6. Ledger Transmission. The anchor is written to the local WAL and, if a remote endpoint is configured, transmitted to the compliance ledger. Batch mode collects anchors and flushes at configurable intervals to reduce network overhead.
7. Response. The original tool result is returned to the MCP client unchanged. The governance layer is transparent to the client; it receives the same response it would have received without SWT3.

Failure Modes

When fail_secure is true (the default), any failure in steps 2 through 6 blocks the tool call and returns a policy violation error to the client. This ensures that no tool invocation proceeds without a corresponding witness anchor. When fail_secure is false, the tool call proceeds and the failure is logged locally for later reconciliation.

The WAL (Write-Ahead Log) provides durability during network interruptions. Anchors written to the WAL are retried on the next successful connection to the ledger endpoint, ensuring that temporary connectivity loss does not result in missing audit records.