Securing MCP integrations after the 28 July 2026 spec: what you must now prove per tool call

You must now design and operate a gateway that intercepts every tool call, enforce policy-as-code at runtime, bind each agent to its own cryptographic identity, and maintain a signed audit trail that proves what happened and why. The protocol itself does not enforce these controls — you do.

The prompt is an analysis of 7 September 2026 of the 28 July 2026 Model Context Protocol specification, which argues that the specification removes session-level risks but places responsibility for consent, authorisation and tool safety entirely on the integrator. The concrete case is the deployment of MCP in high-trust environments where sensitive workflows call external tools through model agents. In our assessment, this represents a shift in where security must be enforced: no longer at the protocol layer alone, but at the gateway, identity and audit layers that you control.

What changed in the specification itself?

The 28 July 2026 revision removed several protocol-level attack vectors. Session hijacking becomes harder. Spontaneous server prompts are constrained. OAuth flows are tightened. But the specification itself states explicitly that it does not enforce consent, authorisation, data minimisation or tool safety. Those remain implementation choices. The protocol provides the building blocks; you must fit the locks.

Which risks does the new architecture introduce?

Independent security analyses identify a new attack surface. The HTTP layer now carries MCP-specific headers such as MCP-Method and MCP-Name. Misconfiguration of these headers can leak data. Protocol confusion and desynchronisation attacks become possible when gateways do not validate the boundary between the agent, the gateway and the tool server. Rich user interfaces and asynchronous task handling introduce security boundaries that must be designed explicitly. The old model of "secure the model and you are done" no longer holds.

• Protocol confusion and header injection — attackers exploit ambiguity between HTTP semantics and MCP semantics to bypass validation.
• Unauthorised tool access — agents call tools without explicit consent or proper identity binding.
• Audit trail gaps — tool calls occur but are not recorded or are recorded without cryptographic proof of authenticity.
• Shared credentials across agents — multiple agents use the same API key or session token, breaking accountability.
• Misconfigured x-mcp headers — sensitive data leaks through headers that are not validated or sanitised.

What must your gateway enforce?

A gateway that sits between agents and tool servers must intercept every tool call and apply policy at runtime. This is not a firewall; it is a policy engine. The gateway must validate that the agent calling the tool has the identity and permissions to do so. It must record what was called, by whom, when and with what result. It must do this before the tool executes, not after.

The Microsoft Agent Governance Toolkit includes an MCP Security Gateway specification that describes this architecture. The gateway offers identity binding — each agent receives its own cryptographic identity, not a shared key. It offers policy enforcement — rules about which agents can call which tools, under what conditions. It offers audit logging — every call is recorded with proof of authenticity.

What must you be able to demonstrate per integration?

1. Document the agent identity and its scope — record which agent calls which tool, the lawful basis for the data it accesses, and the business purpose of each call.
2. Enforce policy-as-code at the gateway — implement rules that prevent unauthorised calls before they reach the tool server, with evidence that the rule was evaluated and passed.
3. Sign and timestamp every tool call — produce a cryptographically signed audit entry for each call that cannot be altered after the fact and proves the agent, the tool, the input and the result.
4. Bind the agent to a unique identity — ensure each agent has its own credential or certificate, not a shared key, so that accountability is not lost when multiple agents share infrastructure.
5. Verify tool server behaviour independently — where possible, require tool servers to provide evidence of their own compliance with policy, not merely assertions.

How far can tooling take you?

Verification layers and confidential-computing runtimes can make these controls visible and enforceable. A tool server that runs in a confidential-computing environment can enforce governance policies in hardware and produce independently verifiable evidence of every call. A verification layer can make policy checks, corrections and data flows visible per workflow for inspection. But these are support layers, not replacements for your own gateway design and audit discipline. The professional judgement — which tools your agents may call, what data they may touch, what evidence you require — remains yours alone.