Don't Put Secrets in MCP Headers — Why Mcp-Method Routing Creates a New Leak Path

One of the best ops upgrades in MCP spec 2026-07-28 is also one of the easiest ways to leak credentials: header-based routing.

Streamable HTTP requests now carry Mcp-Method and Mcp-Name so your gateway, WAF, or rate limiter can route and meter without parsing JSON bodies. That is exactly what platform teams asked for when MCP moved stateless and started behaving like ordinary HTTPS traffic.

The failure mode is predictable: someone maps a bearer token, tenant slug, API key fragment, or session cookie into a custom MCP header “for routing convenience.” Proxies log headers by default. SIEMs ingest them. Support engineers grep them. Your secret is now inventory, not authentication.

This article is the security follow-up we teased in what to rip out before the deprecation clock hits — what belongs in headers, what never does, and how to harden gateways without breaking the spec.

What changed in the spec

Before 2026-07-28, much of MCP’s routing context lived inside JSON-RPC bodies and session state. After the stateless core:

• Mcp-Method — the MCP method being invoked (e.g. tools/call, tools/list)
• Mcp-Name — the tool, resource, or prompt name when relevant
• Parameter headers (where supported) — selected arguments can surface at the edge for routing without full body inspection

That design is intentional. It lets you write rules like:

• Rate-limit tools/call separately from tools/list
• Block destructive tool names at the edge
• Send write-heavy tools to a stricter pool

Good for reliability. Dangerous if “routing metadata” becomes a second place to stash secrets.

The anti-pattern: headers as a secret channel

Teams reach for this when auth feels awkward in JSON or when a gateway vendor says “we can only route on headers.” Common mistakes:

If your access log line includes the full header set, assume every value in that line will eventually be copied into a ticket, a Slack thread, or a vendor support bundle.

What belongs where

Use this split when you design remote MCP hosting:

• Authorization header — bearer tokens, OAuth access tokens. Validate once at the edge; do not duplicate elsewhere.
• Mcp-Method / Mcp-Name — routing and metering only. Non-secret, spec-defined labels.
• Parameter headers — only non-sensitive routing keys (e.g. public tenant slug, environment name staging vs prod). Never secrets, never PII you would not print on a dashboard.
• JSON body — tool arguments. Assume the model and logs may see them; scope tools accordingly.

OAuth scope design still matters — headers do not replace the permission model in OAuth and the over-permission trap. They just give you a new place to get sloppy.

Gateway and logging checklist

Run this before you expose a remote MCP server to Claude, ChatGPT, or org-wide Cursor configs:

1. Log redaction — redact Authorization, Cookie, and any custom auth headers at the load balancer / CDN / API gateway.
2. Allowlist header logging — log Mcp-Method, Mcp-Name, request ID, status, latency — not “all headers.”
3. Separate routing keys from auth keys — if you route by tenant, use an opaque public tenant ID; resolve to credentials server-side.
4. Reject header/body mismatches — if Mcp-Name says delete_repo but the body targets a different tool, fail closed (some gateways can enforce this).
5. Retention — shorter retention on edge logs than on audit tables; tokens should not live in S3 for 90 days because “debugging was hard.”
6. Alert on verbose modes — treat “log full request headers” flags like production firewall disables.

Pair this with allowlists and IdP-managed auth from AI agent tool access as an operating control and enterprise-managed MCP auth — headers are transport hygiene; governance is still who may connect which server.

Builder guidance: safe edge routing patterns

Pattern A — method/name only

Route on Mcp-Method + Mcp-Name alone. Keep auth in Authorization. Simplest and spec-aligned.

Pattern B — public routing labels

Add a non-secret header like X-Mcp-Pool: read-only set by your gateway after token introspection — not by the client. The client never supplies the pool name; the gateway derives it from token claims.

Pattern C — body stays authoritative

Use headers for coarse throttles only. The MCP server still validates tool name and args from the body. Headers are hints, not authority.

Avoid Pattern D — client-supplied secret headers. If the agent or connector can set it, it is not a security boundary.

What security reviewers should ask

Add these to the seven-question MCP audit for any remote server handling sensitive data:

• Which headers does our gateway log, and for how long?
• Does any component copy bearer tokens out of Authorization?
• Can parameter headers be influenced by the model/client without server validation?
• Do we have a tested redaction config in staging that matches production?
• Who gets paged when verbose HTTP logging is enabled in prod?

Quick answers

Are Mcp-Method and Mcp-Name secret?

No. Treat them like HTTP path segments — useful for routing, safe to log.

Can we put a hashed token in a header?

Still avoid it. Hashes of secrets still aid offline attacks and correlate users in logs. Route on opaque non-secret IDs instead.

Does this apply to local stdio MCP?

Mostly no — this is a remote HTTP + gateway problem. Local stdio still has PAT-in-config debt; see demoware vs production-ready.

Where is the spec background?

MCP 2026-07-28 announcement and your rip-out checklist: deprecation clock.

Related reading

• What to rip out before the deprecation clock hits
• MCP Builders Ch. 2: OAuth and the over-permission trap
• MCP Builders Ch. 4: stdio, HTTP hosting, and secrets
• AI agent tool access as an operating control
• Brief: sessions die, HTTP wins

Final thought

Header-based routing is a maturity feature. It means MCP is serious about running behind the same infrastructure as the rest of your APIs.

Do not repay that maturity by piping secrets through headers because it was convenient on a Tuesday.

Route on method and tool name. Authenticate in Authorization. Redact everything else. Then run the audit — before the logs become the breach.