Microsoft quietly shipped a conformance spec for the MCP security boundary

Microsoft quietly shipped a conformance specification for the MCP security boundary via its open-source Agent Governance Toolkit. The MCP Security Gateway 1.0 spec defines a policy-enforcing interception layer between agents and tool servers, complete with 127 conformance tests and a Python implementation. The spec precisely defines tool-call interception, response scanning for six named threats, schema-drift detection, and fail-closed behavior, turning vague security advice into testable requirements.

Most of the advice about securing MCP tools is sound and vague: "vet your servers," "scan responses," "fail closed." Good instincts, no spec. Microsoft's Agent Governance Toolkit https://github.com/microsoft/agent-governance-toolkit — an MIT-licensed, open repo — turned one of those instincts into something you can actually conform to. The piece worth reading is MCP Security Gateway 1.0 https://github.com/microsoft/agent-governance-toolkit/blob/main/docs/specs/MCP-SECURITY-GATEWAY-1.0.md . It describes a policy-enforcing interception layer that sits between an agent and its MCP tool servers — a gateway every tool call and every tool response passes through. And it's written in RFC-2119 conformance language: the MUSTs, SHOULDs, and MAYs are load-bearing, which means an implementation can be measured against it rather than vibe-checked. The repo ships exactly that measurement: a conformance suite of 127 tests against a Python implementation. The gateway pattern itself isn't new. What's new is having the boundary specified precisely enough to test, instead of each team reinventing it. The spec is specific about what the gateway does, which is the useful part. Tool-call interception with approval. Calls are evaluated in a strict order: deny-list, then allow-list, then a sensitive-tool check that invokes an approval callback, then rate limits. For a sensitive tool, if the callback returns anything but APPROVED — DENIED or PENDING — the call is blocked. Response scanning. Tool responses are scanned and handled with one of three actions: BLOCK , SANITIZE redact the bad part, pass the rest , or LOG . It looks for instruction-tag injection markers like <SYSTEM or INST , imperative injection "ignore previous instructions" , credential leaks, PII like SSNs and card numbers, and exfiltration URLs that smuggle data out in query parameters. A security scanner for six named threats. The MCPThreatType enum is exactly six values, and the naming is the documentation: TOOL POISONING — malicious instructions in a tool definition RUG PULL — the tool's description or schema changed since registration CROSS SERVER ATTACK — a tool reaching for tools on other servers CONFUSED DEPUTY — a tool escalating privilege or acting for another agent HIDDEN INSTRUCTION — invisible Unicode, encoded payloads, hidden comments DESCRIPTION INJECTION — prompt injection embedded in a tool description Schema-drift detection. A drift detector fingerprints each tool's schema and compares on every load. Any fingerprint change MUST raise a CRITICAL alert — which is the concrete control for the rug-pull case, where a trusted tool turns hostile in a later release. Fail-closed throughout. The stated design principle is that every component — gateway, scanner, rate limiter, auth enforcer — MUST deny on error, never silently permit. There's a conformance table mapping each component's failure mode to its safe default. A scanner that crashes blocks the response; it doesn't wave it through. The MCP boundary is where an agent meets code it doesn't control, running with real authority. It's the natural place to put controls, and until now "put controls there" was where the guidance stopped. A conformance-testable reference changes the conversation from "we should scan responses somehow" to "does our gateway pass the response-scanning conformance tests, yes or no?" You can disagree with a specific MUST, but you're now disagreeing with a written rule, not filling a blank. It's also a useful reference even if you never adopt the toolkit. The six threat names and the fail-closed table are a checklist for whatever you've already built. Route MCP traffic through one auditable, fail-closed choke point. Not per-tool checks scattered across your agent code — a single layer that every tool call and response crosses, that denies on error, fingerprints tools and notices drift, and scans responses before they reach the model. The payoff of one boundary is that "is this safe?" has exactly one place to be answered, and one place to audit when something goes wrong. The good news is you don't have to design that boundary from scratch. The spec already enumerates the threats, the actions, and the failure semantics — read it, then either adopt the gateway or hold your own implementation to the same bar. This spec is one of the sources behind BRACE https://braceframework.org/ , an open, vendor-neutral framework for securing autonomous AI agents — its ecosystem guide covers the fail-closed MCP gateway pattern this implements. BRACE is built by reading the incidents and the research and asking, each time: what concrete control would have prevented or contained this?