MCP Governance and Compliance

1. The Accountability Gap in MCP

The Model Context Protocol defines a standard interface for AI models to discover, invoke, and interact with external tools and data sources. It solves the integration problem: any MCP-compliant model can use any MCP-compliant server.

However, MCP has no accountability primitives.

The EU AI Act requires automatic logging of AI system operations (Art. 12), human oversight of high-risk decisions (Art. 14), and risk management measures that are operational, not merely documented (Art. 9). When an AI model invokes a tool via MCP, none of these requirements are satisfied by the protocol itself.

The OWASP MCP Top 10 (2026) and NSA MCP security guidance formally recognize these risks. For detailed procedure-level mappings, see the OWASP MCP Top 10 Mapping and NSA MCP Security Mapping.

2. Architecture: Transport vs. Accountability

SWT3 operates alongside MCP, not inside it. The protocol does not modify MCP's tool discovery, invocation, or response handling. Instead, it wraps tool calls with a witnessing layer that produces anchors as a side effect of normal operation.

Request Flow

1. Tool Request. The MCP client sends a standard tool invocation request to the SWT3 MCP Server.
2. Policy Evaluation. The server evaluates the request against mcp_policy rules: tool allowlist/blocklist, velocity limits, chain depth, and custom rules.
3. Trust Verification. If require_trust_level is set, the calling agent's credentials are checked. In strict mode, untrusted agents are blocked.
4. Tool Execution. If policy allows, the tool executes normally. SWT3 does not modify tool behavior.
5. Witness Anchor Minting. An AI-TOOL.1 anchor is minted with tool name, call ID, outcome, and cryptographic fingerprint.
6. Ledger Transmission. The anchor is written to the local WAL and, if configured, transmitted to the compliance ledger.
7. Response. The original tool result is returned unchanged. The governance layer is transparent.

When fail_secure is true (default), any failure in the witnessing pipeline blocks the tool call. When false, the call proceeds and the failure is logged for reconciliation.

3. Installation and Configuration

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_..."
      }
    }
  }
}

Tool Policy Configuration

Create a .swt3.yaml file in your project root:

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

Policy options:

• witnessed_tools -- Glob patterns for tools that must be witnessed
• exempt_tools -- Low-risk tools excluded from witnessing overhead
• max_velocity -- Rate limiting (invocations per time window)
• max_chain_depth -- Maximum sequential dependent tool calls
• tool_allowlist / tool_blocklist -- Explicit permit and deny lists
• fail_secure -- Block tool call if witnessing fails (default: true)
• rules -- Custom governance rules with match conditions and actions

Validate with: npx @tenova/swt3-mcp doctor

4. Standard Tool Definitions

An SWT3-compliant MCP server SHOULD expose these canonical tools:

Standard resource URIs:

5. Tool Witnessing Pattern

SWT3 defines a pattern for witnessing any MCP tool call without modifying the tools themselves.

Python

from openai import OpenAI
from swt3_ai import witness

# Wrap your OpenAI client. All calls are now witnessed.
client = witness(OpenAI(), clearing_level=1)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Summarize Q3 revenue"}]
)

TypeScript

import OpenAI from "openai";
import { witness } from "@tenova/swt3-ai";

const client = witness(new OpenAI(), { clearingLevel: 1 });

const response = await client.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "Summarize Q3 revenue" }],
});

What Gets Recorded

Privacy guarantee: Raw data never enters the witness system. Tool arguments and results are SHA-256 hashed at the point of observation. An auditor can verify a specific tool call produced a specific result (by re-hashing), but cannot reconstruct the data from the anchor alone.

6. Integration Levels

7. Governance Procedures

For the complete procedure registry (80 procedures across 41+ namespaces), see the UCT Registry.

8. Regulatory Mapping

9. Clearing in MCP Context

MCP tool calls frequently involve sensitive data. The SWT3 Clearing Protocol ensures that this data does not persist in the witness system after the tool call completes.

10. 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. Three modes:

• Strict -- Untrusted agents are blocked. Tool calls from agents not in trusted_agents are rejected.
• Permissive -- Untrusted agents allowed but flagged with reduced trust level in the anchor.
• Monitor -- All agents allowed. Trust status recorded but no blocking. Useful during initial deployment.

Multi-Agent Chains

Each agent in a multi-agent system is assigned a unique agent_id. When Agent A delegates work to Agent B via MCP, both agents produce anchors. The chain is reconstructable from the anchor sequence with millisecond ordering.

11. Conformance

An MCP server claiming SWT3 compliance MUST satisfy:

Minimum Requirements (all levels)

• Expose witness_inference and verify_anchor tools using canonical names
• Expose swt3://registry/procedures resource
• Compute fingerprints using the SWT3 canonical formula
• Never transmit raw prompt or response text to the witness endpoint

Level 2 (Active) Additional

• Block tool execution if anchor minting fails
• Include agent_id in all anchors when configured
• Support HMAC-SHA256 payload signing when a signing_key is provided

Level 3 (Sovereign) Additional

• Implement clearing at Level 1 or higher as default
• Ensure clearing irreversibility per the SWT3 Clearing Protocol
• Support per-tool clearing level configuration

Interoperability: An anchor minted by any SWT3-compliant MCP server MUST be verifiable by any SWT3-compliant verifier, regardless of language, hosting provider, or MCP version.