Security Series

MCP: From Spec to Incident to Governance

Four episodes. One complete story. Everything Anthropic shipped, everything that broke, and the governance layer nobody built.

Start at MCP 101 Jump to the checklist

The Episodes

SECURITY SERIES EP. 01

MCP 101: I Read the Documentation So You Don't Have To

What the spec actually says. The N x M problem. Why USB-C for AI is the right analogy and where it breaks down.

MCP 102: Claude Already Knows

Claude Code ships with MCP built in. Your IT team does not know yet. Here is what that means.

MCP 103: I Gave Claude Code Someone Else's Tools

Three community servers. One sentence. No change request. No audit trail. Three systems acted.

BONUS

Your Policy Isn't Ready: Everything Anthropic Shipped in March 2026

Claude 3.7, Claude Code, updated usage policy — same month. Your governance docs did not keep up.

MCP 201: The Governance Deficit

30 CVEs in 60 days. 38 percent of scanned servers with zero authentication. The protocol works. The guardrails do not exist yet.

The Security Framework

These visuals live in MCP 201. They also stand alone.

MCP Security Series: From Spec to Safety System

MCP 101 SPEC What the protocol actually says.

MCP 102 BEHAVIOR It's already turned on in your IDE.

MCP 103 INCIDENT No change request. No audit trail. Three systems acted.

MCP 201 GOVERNANCE Same MCP. Very different risk profile.

Spec Behavior Incident Governance

The Five Layers

Not an MCP feature. Your infrastructure.

5 Observability & Response

log everything / SIEM / kill-switch

4 Safety Shim (Policy & Content Controls)

prompt injection filters / DLP / tool allowlists

3 Network & Runtime Isolation

hardened containers / default-deny egress

2 Server Authenticity & Supply Chain

TLS/mTLS / signed metadata / approved allowlist

1 Identity, Auth & Scopes

OAuth 2.1 / scoped tokens / no static API keys

If one layer fails, the others still hold.

Where Are You Today?

Most organizations are Stage 0 or 1.

Stage 3 Resilience SIEM integration, kill-switch, runbooks, recertification

Biggest risk drop here Stage 2 Control Plane Central registry, policy gateway, RBAC, DLP

Stage 1 Inventory & Basic Auth Servers documented, scopes recorded, basic OAuth

Stage 0 Shadow MCP Random servers, long-lived tokens, no catalog, no visibility

Three Ways MCP Goes Wrong

The Content Injector

Hides instructions in tickets, emails, GitHub issues.

Real incident Malicious GitHub issue exfiltrated private repo data to a public PR.

The Supply Chain Attacker

Fake or compromised MCP servers.

Real incident Fake email connector BCC'd every outbound email to attacker.

The Over-Helpful Agent

Too many tools, too many permissions, no guardrails.

"The agent did exactly what you told it to do. That is the whole problem."

Free Resources

Take these back to your team.

Stage 0 MCP Self-Assessment

Six yes/no questions. Run it against any MCP server in production or in your lab.

1. Is this server on an approved allowlist with a documented owner and scopes? 2. Are we using short-lived scoped tokens? No static API keys in the config? 3. Is the server running behind TLS? Do we verify its identity before connecting? 4. Does untrusted content pass through any injection filter before tools fire? 5. Do tool outputs get scanned for PII or sensitive data before they leave the platform? 6. Do we log MCP tool calls, and do we have a way to shut this server down in under 10 minutes?

More than two NOs = Stage 0 in production.

MCP Server Review Template

Use this before approving any new MCP server for your environment.

Server	Owner	Data Domains	Scopes	Auth Method	Logging	DLP	Risk
GitHub MCP	[your team]	Source code, issues, PRs	repo:read (separate from repo:write)	OAuth 2.1 short-lived token	Y	Y	High

MCP Minimal Governance Policy

Paste this into your internal docs. Edit the brackets. It is a starting point, not a legal document.

MCP MINIMAL STANDARD (v1.0)

ALLOWLIST: All MCP servers must be registered in the approved catalog with a documented owner, data domains, and permitted scopes before connecting to any production environment.
AUTHENTICATION: All MCP servers must use OAuth 2.1 with short-lived, scoped tokens. Static API keys and long-lived credentials are not permitted.
SCOPES: Read and write permissions must be separate tokens. No wildcard scopes (e.g., crm.* is not permitted; crm.read and crm.write are required separately).
LOGGING: All MCP tool calls, parameters, and responses must be logged with trace IDs and fed into [your SIEM].
DLP: Tool outputs must pass PII and sensitive data checks before leaving the platform.
KILL SWITCH: Every registered MCP server must have a documented procedure for revocation or shutdown within 10 minutes of an incident flag.

More episodes coming soon.

Multi-agent patterns, cost architecture, and the governance frameworks that actually shipped. Get notified when it drops.

Subscribe free on Substack

Free. No spam. Unsubscribe whenever.