MCP interceptor

import { Aside } from ‘@astrojs/starlight/components’;

The MCP context interceptor is a middleware layer inside ov mcp serve. It scans every message flowing through the bridge and blocks any message containing a detected secret pattern before it reaches the AI model.

This is OpaqueVault’s second line of defense — it catches the mistakes that the vault itself can’t prevent.

---

Why it exists

The vault prevents secrets from being requested by an AI. The interceptor prevents secrets from being sent to an AI — accidentally, in a stack trace, in a debug paste, or any other way a raw secret might end up in the MCP channel.

These are different threat vectors. Both need to be covered for the zero-knowledge guarantee to be unconditional.

---

What it detects

The same detection engine as ov scan:

Pattern	Example
AWS access keys	AKIA[0-9A-Z]{16}
GitHub tokens	ghp_, github_pat_
Stripe keys	sk_live_, sk_test_
Private keys	PEM headers
JWT tokens	eyJ... three-part base64url
Connection strings	postgres://user:pass@host
High-entropy strings	Shannon entropy > 4.5 bits/char

---

How it works

Claude Code  ──message──▶  [interceptor]  ──clean──▶  ov mcp serve
                                ↓ match found
                         blocked + audit log entry
                                ↓
                    error returned to Claude Code:
                    "[OpaqueVault] Potential secret intercepted
                     (aws-access-key). Message blocked.
                     Store this value with 'ov secret set' instead."

The interceptor runs on every MCP message — both tool call arguments inbound from the client and tool responses outbound from the bridge.

---

Modes

BLOCK (default)

OV_INTERCEPT_MODE=block ov mcp serve

The message is dropped. A structured error is returned to the MCP client. The interception is logged to the audit trail. vault_status increments intercepted_count.

WARN

OV_INTERCEPT_MODE=warn ov mcp serve

WARN mode allows the secret to reach the model. Use only for debugging. Never in production.

The message passes through. An intercept event is written to the audit log with mode: warn. vault_status increments intercepted_count.

---

Audit log entries

Intercepted events appear in the audit log as:

operation: intercept
pattern:   aws-access-key
mode:      block
api_key:   (current session key)
ip:        127.0.0.1

Filter interception events:

ov audit log --filter intercept

---

Checking interceptor activity

vault_status()
→ { "intercepted_count": 2, "intercept_mode": "block", ... }

If intercepted_count is non-zero, something tried to send a raw secret through the MCP channel. Check your audit log and consider whether the source needs to be addressed (e.g., a script that prints env vars to stdout, a stack trace that includes connection string details).