MCP OAuth Token Binding: Witnessing the Authentication Lifecycle

1. The MCP OAuth Crisis

The Model Context Protocol enables AI assistants to call external tools. These tools access databases, APIs, file systems, and cloud services on behalf of the user. Authentication is the foundation of this access. When it fails, the consequences cascade.

The current state of MCP authentication:

• 8.5% OAuth adoption: The vast majority of MCP servers use no authentication, static API keys, or informal bearer tokens. OAuth, the industry standard for delegated authorization, is rare.
• 30+ CVEs in 60 days: Researchers disclosed over 30 vulnerabilities in MCP implementations between July and September 2026, including token theft, scope escalation, and session hijacking.
• Confused deputy (OWASP MCP-07): A malicious MCP server can act as a proxy, forwarding the user's OAuth token to a legitimate service while impersonating the user. The legitimate service cannot distinguish between the user and the proxy.
• One-click ATO: Combined with auto-approval flows in some MCP clients, the confused deputy attack becomes a one-click account takeover. The user installs a malicious MCP server, and their tokens are immediately compromised.

SWT3 does not prevent these attacks. Prevention is the responsibility of the OAuth implementation itself (audience validation, token binding, DPoP). What SWT3 does is produce an independent witness record of every OAuth lifecycle event, creating forensic evidence that persists regardless of whether the attack is detected in real time.

2. Eight Witnessable Events

The OAuth lifecycle in MCP has eight distinct events. Each event produces an AI-MCP.5 witness anchor with a specific event_type code.

3. Factor Semantics

All eight event types use the same procedure (AI-MCP.5) with the event type encoded in Factor A. This keeps the procedure namespace clean while allowing fine-grained event differentiation in the ledger.

The fingerprint is computed as SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]. This formula is locked across all seven SDK languages and produces identical fingerprints for identical inputs.

4. Confused Deputy Prevention

The confused deputy attack is the most dangerous OAuth vulnerability in MCP. Here is how it works and where witnessing provides evidence.

Witnessing does not block the confused deputy attack. Token audience validation (RFC 9068), DPoP (RFC 9449), and sender-constrained tokens are the preventive controls. What witnessing provides is an independent evidence trail that persists after the attack, enabling forensic reconstruction and proving whether audience validation was performed on every token use.

5. Python Integration

from swt3_ai import Witness
import hashlib

witness = Witness(
    endpoint="https://sovereign.tenova.io",
    api_key="axm_live_...",
    tenant_id="ACME_DEFENSE",
    agent_id="mcp-gateway-v2",
)

# Witness OAuth token issuance
token_hash = hashlib.sha256(access_token.encode()).hexdigest()[:16]

witness.witness_oauth_token_binding(
    event_type="oauth_token_issued",
    server_id="github-mcp-server",
    token_hash=token_hash,
    scopes="repo,read:org",
    audience="https://api.github.com",
    scope_count=2,
    expiry_epoch=1774900000,
)

# Witness audience validation on every token use
witness.witness_oauth_token_binding(
    event_type="oauth_audience_check",
    server_id="github-mcp-server",
    token_hash=token_hash,
    expected_audience="https://api.github.com",
    actual_audience="https://api.github.com",
    validation_result="pass",
)

# Witness token revocation
witness.witness_oauth_token_binding(
    event_type="oauth_revoke",
    server_id="github-mcp-server",
    token_hash=token_hash,
    reason="session_end",
    initiator="user",
)

6. TypeScript Integration

import { Witness } from "@tenova/swt3-ai";
import { createHash } from "crypto";

const witness = new Witness({
  endpoint: "https://sovereign.tenova.io",
  apiKey: "axm_live_...",
  tenantId: "ACME_DEFENSE",
  agentId: "mcp-gateway-v2",
});

const tokenHash = createHash("sha256")
  .update(accessToken).digest("hex").slice(0, 16);

// Witness OAuth token issuance
await witness.witnessOAuthTokenBinding({
  eventType: "oauth_token_issued",
  serverId: "github-mcp-server",
  tokenHash,
  scopes: "repo,read:org",
  audience: "https://api.github.com",
  scopeCount: 2,
  expiryEpoch: 1774900000,
});

// Witness audience validation
await witness.witnessOAuthTokenBinding({
  eventType: "oauth_audience_check",
  serverId: "github-mcp-server",
  tokenHash,
  expectedAudience: "https://api.github.com",
  actualAudience: "https://api.github.com",
  validationResult: "pass",
});

// Witness token revocation
await witness.witnessOAuthTokenBinding({
  eventType: "oauth_revoke",
  serverId: "github-mcp-server",
  tokenHash,
  reason: "session_end",
  initiator: "user",
});

7. MCP Server Tool

The SWT3 MCP server exposes witness_oauth_token_binding as a callable tool. Any MCP client can invoke it directly.

// MCP tool call
{
  "tool": "witness_oauth_token_binding",
  "arguments": {
    "event_type": "oauth_audience_check",
    "server_id": "github-mcp-server",
    "token_hash": "a1b2c3d4e5f6...",
    "expected_audience": "https://api.github.com",
    "actual_audience": "https://api.github.com",
    "validation_result": "pass"
  }
}

8. Framework Coverage

9. Scope Governance

OAuth scopes define what an MCP server can do on behalf of the user. Witnessing scope governance produces evidence of least-privilege enforcement that auditors can verify independently.

Scope Attestation Chain

• Scopes requested (oauth_authz_request): Records the exact permissions the MCP server asked for. If a server requests repo,admin:org,delete:repo, this is permanently recorded.
• Scopes granted (oauth_token_issued): Records what the authorization server actually granted. If the user or policy narrows the scopes to repo,read:org, the gap between requested and granted is visible.
• Scope reduction (oauth_scope_reduce): Records voluntary scope narrowing by the MCP server. A well-behaved server that only needs read access can reduce its granted scopes, and the reduction is witnessed.
• Scope consumed (oauth_token_use): Records which scope was actually used on each API call. Over time, this reveals unused scopes (permissions granted but never exercised), which are candidates for removal.

The scope_count field in Factor C provides a numeric measure of privilege breadth. An assessor can query the ledger for anchors where scope_count exceeds a policy threshold, identifying MCP servers with excessive permissions.

Scope Drift Detection

By comparing oauth_token_issued anchors across refresh cycles, scope drift becomes visible. If a token refresh silently adds new scopes (a known attack vector), the anchors will show a scope_count increase that was not preceded by a new authorization request. This pattern is a finding.