SWT3 Compliance Binding for MCP

1. The Accountability Gap in MCP

The Model Context Protocol (MCP) 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. This is a significant advance for AI interoperability.

However, MCP has no accountability primitives.

This gap is not theoretical. The EU AI Act (Regulation 2024/1689) 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.

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.

This separation provides three guarantees:

1. No performance impact on MCP. Witnessing happens asynchronously. Tool execution is not blocked by anchor computation or ledger writes.
2. No modification to existing MCP servers. The witness layer wraps the tool call at the SDK level. Existing MCP servers do not need to be rewritten.
3. Independent verification. Anchors can be verified by any party with SHA-256 support, with no access to the MCP server or model required.

3. Standard Tool Definitions

An SWT3-compliant MCP server SHOULD expose the following tools. These names are canonical: adopting them ensures interoperability across implementations and allows compliance tooling to discover witnessing capabilities automatically.

3.1 witness_inference Parameters

* Either prompt or prompt_hash SHOULD be provided. If raw text is provided, it is hashed locally before transmission. The raw text never leaves the client.

4. Standard Resource URIs

MCP resources provide read-only data that models can reference. SWT3-compliant servers SHOULD expose the following resources using these canonical URIs:

The swt3:// URI scheme is used as a namespace convention within MCP resource discovery. It does not imply a custom protocol handler. MCP servers resolve these URIs internally.

5. Tool Witnessing Pattern

Beyond the explicit witness_inference tool, SWT3 defines a pattern for witnessing any MCP tool call. This is the mechanism by which AI tool use becomes auditable without modifying the tools themselves.

5.1 The Wrap Pattern

An SWT3-compliant SDK provides a wrap_tool (Python) or wrapTool (TypeScript) function that intercepts a tool call, executes the original function, and mints an anchor recording the invocation.

Python (runnable)

# pip install swt3-ai openai
from openai import OpenAI
from swt3_ai import witness

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

# This call works exactly like normal OpenAI.
# Behind the scenes, an SWT3 anchor is minted:
#   - Prompt and response are SHA-256 hashed (never stored raw)
#   - Factor matrix records model, latency, and token counts
#   - Anchor is printed to console (or sent to your witness endpoint)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Summarize Q3 revenue"}]
)

# Output includes:
# SWT3-S-LOCAL-AI-AIINF1-PASS-1774800000-c059eb5938c0
# Clearing Level 1: prompt/response destroyed, factors + anchor persist

TypeScript (runnable)

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

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

// Every call is witnessed. Same API, same types, same behavior.
const response = await client.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "Summarize Q3 revenue" }],
});

MCP Server (zero-config demo)

# Run the SWT3 MCP server in demo mode. No API keys needed.
npx @tenova/swt3-mcp

# Or with live persistence:
SWT3_API_KEY=axm_live_... npx @tenova/swt3-mcp

5.2 What Gets Recorded

5.3 Privacy Guarantee

The wrap pattern is designed around a fundamental constraint: raw data never enters the witness system. Tool arguments and results are SHA-256 hashed at the point of observation. The hash is irreversible. An auditor can verify that a specific tool call produced a specific result (by re-hashing the original data), but cannot reconstruct the data from the anchor alone.

This satisfies the dual requirement of traceability (EU AI Act Art. 12: "logs shall enable the tracing of the AI system's operation") and data minimization (GDPR Art. 5(1)(c): "adequate, relevant and limited to what is necessary").

6. Integration Levels

MCP servers can adopt SWT3 witnessing at three levels of depth. Each level adds accountability without removing functionality from the previous level.

7. Regulatory Mapping

SWT3-witnessed MCP tool calls map directly to regulatory requirements across multiple frameworks. This mapping demonstrates that the combination of MCP (transport) and SWT3 (accountability) satisfies obligations that neither protocol addresses alone.

8. Multi-Agent Chains

When multiple AI agents collaborate through MCP, each agent's tool calls can be witnessed independently while maintaining a verifiable chain of accountability across the full workflow.

8.1 Chain Witnessing

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

# Agent A: orchestrator
SWT3-S-AWS-AI-AIINF1-PASS-1773900000-a4c7e2f91b03  agent_id=orchestrator-v1

# Agent B: research agent (invoked by A via MCP)
SWT3-S-AWS-AI-AITOOL1-PASS-1773900001-b5d8f3a02c14  agent_id=research-agent-v2

# Agent A: synthesizes research output
SWT3-S-AWS-AI-AIINF1-PASS-1773900005-c6e9g4b13d25  agent_id=orchestrator-v1

8.2 Accountability Properties

• Attribution: Every anchor records which agent produced it via agent_id
• Ordering: Millisecond timestamps establish causal sequence
• Delegation: When Agent A invokes Agent B's MCP tools, both the invocation and execution are witnessed
• Integrity: Tampering with any anchor in the chain breaks its fingerprint without affecting other anchors (no cascading failure)

9. Clearing in MCP Context

MCP tool calls frequently involve sensitive data: database queries, API credentials, file contents, user information. The SWT3 Clearing Protocol ensures that this data does not persist in the witness system after the tool call completes.

9.1 Clearing Sequence for MCP Tool Calls

1. MCP client invokes tool with arguments
2. SWT3 witness layer captures:
   - SHA-256(tool_arguments) as factor_a component
   - SHA-256(tool_result) as factor_b component
   - Timestamp at invocation
3. SWT3 anchor is minted with factor matrix
4. Clearing level determines what persists:
   Level 0: Raw arguments and results retained
   Level 1: Only hashes and factors retained (RECOMMENDED)
   Level 2: Only anchor token retained
   Level 3: Anchor transmitted to verifier, nothing retained locally

9.2 MCP-Specific Clearing Guidance

10. Conformance

An MCP server claiming SWT3 compliance MUST satisfy the following requirements:

10.1 Minimum Requirements (all levels)

• Expose the witness_inference and verify_anchor tools using the names defined in Section 3
• Expose the swt3://registry/procedures resource using the URI defined in Section 4
• Compute fingerprints using the SWT3 canonical formula
• Document the clearing level in the server's configuration or health resource
• Never transmit raw prompt or response text to the witness endpoint (hash locally)

10.2 Level 2 (Active) Additional Requirements

• 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

10.3 Level 3 (Sovereign) Additional Requirements

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

10.4 Interoperability

An anchor minted by any SWT3-compliant MCP server MUST be verifiable by any SWT3-compliant verifier, regardless of implementation language, hosting provider, or MCP version. This is the fundamental portability guarantee: the anchor is the evidence, not the system that produced it.

Full protocol specification: SWT3 Protocol Specification v1.3. Source code and test vectors: github.com/tenova-labs/swt3-ai.

SDKs available in 5 languages: Python (pip install swt3-ai), TypeScript (npm install @tenova/swt3-ai), Rust (cargo add swt3-ai), C# (dotnet add package swt3-ai), Ruby (gem install swt3-ai). All produce identical fingerprints. Cross-language parity verified by shared test vectors.