In part 1 I went through the transport change in the MCP 2026-07-28 specification: protocol sessions are gone, requests are self-describing, and MCP servers scale like ordinary HTTP services. That part got most of the attention.
The change I think matters more for enterprise security is quieter. The same release added HTTP metadata that exposes the MCP operation to infrastructure. A gateway can now see which method is being invoked, and which tool is being called, without parsing the JSON-RPC body at all.
That is the difference between "an agent sent something to /mcp" and "the FinanceCopilot agent, on
behalf of Alice, is calling approve_payment". Once infrastructure can see the second
version, most of the governance problems around agentic AI become solvable with tools security
teams already own.
Headers that infrastructure can read
The new Streamable HTTP transport carries two headers that matter here:
POST /mcp HTTP/1.1
Host: tools.contoso.com
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: approve_payment
Authorization: Bearer eyJ...
Content-Type: application/jsonThe official MCP material describes these as letting gateways, load balancers, and rate limiters understand MCP operations without reading the body. (Model Context Protocol blog) Cloudflare demonstrated the same model against the new specification. (Cloudflare)
The body still says the same thing, but the gateway no longer has to buffer and parse it to find out:
{
"jsonrpc": "2.0",
"id": 42,
"method": "tools/call",
"params": {
"name": "approve_payment",
"arguments": { "invoiceId": "INV-2026-8841", "amount": 750000 }
}
}Per-tool authorization becomes practical
Take an enterprise MCP surface exposing something like read_user,
reset_password, create_user, delete_user,
read_invoice, approve_payment, search_document, and
send_email. Those calls do not carry equal risk, and treating them identically because
they all arrive as POST /mcp is how you end up with an authenticated agent that can do
far more than anyone intended.
| Risk tier | Example tools | Suggested gateway control | Rate budget |
|---|---|---|---|
| Low | search_document, read_user, read_invoice |
Authenticated agent identity, standard logging | 500 per minute |
| Medium | create_user, send_email |
Group membership check, argument logging | 60 per minute |
| High | reset_password, delete_user, approve_payment |
Stronger authentication context, human approval, alert on every call | 5 per minute |
With Mcp-Name visible, those rules become ordinary gateway policy rather than custom
middleware. In pseudo-policy form:
if Mcp-Name == "approve_payment" and identity.group != "Finance":
deny
if Mcp-Name == "delete_user":
require step-up authentication context
if Mcp-Name == "search_document":
rate limit 500/min
else if Mcp-Name == "approve_payment":
rate limit 5/minThis is Conditional Access thinking applied to agent tools. The authorization decision stops being
"is this agent authenticated" and becomes a function of user identity, agent identity, tool
identity, tool risk, requested action, data classification, and runtime context. Alice calling
read_invoice from a compliant device is not the same request as
approve_payment for 750,000 euros from an external network, even though both arrive as
a POST to the same URL.
Traditional applications run predetermined flows. A developer decided that the code calls API A, then B, then C. An agent decides at runtime which tool to call, what arguments to send, whether to call something else afterwards, and whether to feed the output of one tool into another. That is exactly why per-tool governance is not optional here.
OAuth gets stricter
The 2026-07-28 specification also tightens the authorization model. The changes discussed by InfoQ and in the specification work include RFC 9207 authorization server issuer identification, RFC 8707 resource indicators, changes to client registration, and stronger server-to-resource binding. Dynamic Client Registration is being deprecated, with the transition plan running into 2027. (InfoQ)
RFC 8707 is the one I would prioritise. A token should not just mean "this client holds a valid token". It should mean "this client holds a token intended for this resource".
This matters more for MCP than it does for a normal API, because MCP servers are bridges into valuable systems. An MCP server may sit in front of Microsoft Graph, SAP, ServiceNow, GitHub, SQL, Azure, AWS, CRM, HR, financial, or security platforms. A wrongly scoped MCP credential has a much larger blast radius than a token for a chatbot.
Trusting headers on their own is a bypass waiting to happen
Moving metadata into headers improves visibility, but it also creates a classic split-brain problem. Suppose an attacker sends:
Mcp-Method: tools/call
Mcp-Name: read_documentwhile the body says:
{
"method": "tools/call",
"params": { "name": "delete_database" }
}If the gateway authorises on the header and the backend executes the body, you have a policy bypass that looks perfectly clean in the logs. The specification accounts for this: transport metadata and body must stay consistent, and servers are expected to reject requests where they disagree. The release-candidate documentation states this explicitly. (Model Context Protocol blog)
If you are building an MCP gateway policy today, write the mismatch check into your acceptance tests before you write the allow rules. A gateway that trusts a client-supplied header without a backend that verifies it is worse than no gateway, because it produces confident, wrong audit records.
The gateway becomes the control point
Put the pieces together and the enterprise MCP architecture starts looking familiar to anyone who has built an API platform. The difference is that the consumer is an agent making its own decisions, not an application executing code somebody reviewed.
The gateway is where the organisation finally knows who called, which tool, through which agent, against which resource, and under which authorization context. For enterprise agentic AI, that is close to a foundational control point.
Azure API Management fits this shape
This direction lines up neatly with where Microsoft has been going. Azure API Management already provides AI gateway capabilities for models and MCP servers, described as a governed runtime boundary covering authentication, routing, request and token rate limits, IP filtering, monitoring, MCP tool publishing, and policy enforcement. The AI Gateway tier is currently in preview. (Microsoft Learn)
Cost note: the AI Gateway tier is a dedicated, always-on API Management deployment, not a per-call add-on. Budget for it the same way you budget for a Premium or Standard v2 APIM instance running 24/7, plus the log ingestion cost of per-tool telemetry. Preview tiers also carry no production SLA, so treat the first deployment as a pilot rather than a platform commitment.
The more interesting capability is that API Management can expose existing REST operations as MCP
tools. Operations such as POST /users/resetPassword, GET /customers/{id},
and POST /tickets become reset_password, get_customer, and
create_ticket without rewriting the backend into an MCP-native service. (Microsoft Learn)
That gives a realistic migration path. Instead of building hundreds of new MCP services, you expose a selected, governed subset of an existing API estate to agents, and keep the controls that estate already has: backend authentication, private networking, API policies, rate limiting, logging, monitoring, and managed identities. You are adding an agent-facing protocol layer, not replacing the platform.
Microsoft Foundry and tool governance
Foundry moves in the same direction. Microsoft documents routing MCP tool access through an AI gateway so that authentication, rate limits, IP restrictions, and audit logging apply centrally rather than being reimplemented inside every individual MCP server. (Microsoft Learn)
The resulting split of responsibility is clean. The MCP server answers what tools exist, what they do, what schema they use, and how to execute them. The enterprise platform answers who can reach it, which agent can invoke it, how often, from where, under which identity, how it is monitored, and which policy applies. That is how mature API platforms evolved, and MCP is arriving at the same separation.
Telemetry your SOC can actually use
Transport metadata also improves detection. Cloudflare has demonstrated inspecting hostname, path,
authorization, MCP-Protocol-Version, Mcp-Method, and Mcp-Name
to identify and control MCP traffic. (Cloudflare)
Instead of five identical POST /mcp lines, the SOC gets events like this:
{
"user": "alice@contoso.com",
"agent": "FinanceAgent",
"mcp_server": "finance-tools",
"mcp_method": "tools/call",
"mcp_name": "approve_payment",
"source_ip": "203.0.113.20",
"result": "allowed",
"latency_ms": 184
}That is an event you can hunt on. It lets you ask questions that were previously unanswerable without instrumenting every MCP server yourself:
- which agents invoke privileged tools, and how often
- which tools generate the most failures
- which identities suddenly changed their tool usage pattern
- which tools are being called outside normal working hours
- whether an agent is enumerating tools it has never touched before
- whether invocation rates look anomalous for the agent or the user
- whether a compromised agent is attempting lateral movement through MCP
That moves MCP activity squarely into SIEM and XDR territory, which is where it needs to be before anyone runs autonomous agents against production systems.
What stateless does not fix
Operational simplification is not security simplification, and I want to be careful not to oversell this. The 2026-07-28 model makes the control plane much easier to architect. It does not remove the risks that come with giving a language model the ability to act.
An enterprise MCP design still has to account for tool poisoning, direct and indirect prompt injection, overprivileged tools, confused deputy attacks, credential forwarding, OAuth audience mistakes, cross-tool data leakage, agent impersonation, user identity propagation, sensitive tool arguments landing in logs, supply-chain risk in tool packages, malicious MCP servers, shadow MCP usage inside the organisation, tool schema manipulation, and unsafe autonomous actions.
If anything, as MCP adoption grows the gateway becomes one of the most security-critical components in the whole agent architecture. Concentrating policy there is the right design, but it also concentrates the consequences of getting it wrong.
My take
I think the 2026-07-28 specification is a clear improvement. The original design solved a real interoperability problem, but some of its transport assumptions made large remote deployments harder than they needed to be. The new model separates the concerns properly: MCP defines agent and tool semantics, HTTP moves requests, OAuth handles authorization, gateways enforce enterprise policy, applications own their state, and observability platforms watch the whole thing.
For Microsoft environments the shape of a governed agent platform is now reasonably clear. Entra ID issues agent and workload identity, Foundry hosts and orchestrates the agents, API Management sits in the middle enforcing authentication, per-tool authorization, rate limits, networking, and telemetry, and only approved MCP tools reach enterprise systems behind it.
The lesson I take from this release is that securing agentic AI will not come down to deciding whether an agent is trusted. It will come down to controlling which identity is acting, which tool it is trying to invoke, what resource that tool can reach, what context the request carries, and which policy applies at the moment of execution.
MCP going stateless sounds like a transport detail. It is bigger than that. It moves MCP from a convenient protocol between agents and tools toward something that can genuinely sit inside enterprise identity, security, networking, and governance architecture. That is where it starts getting interesting.
If you missed the transport background, part 1 covers what the specification removed and why the old session model caused so much operational pain.