MCP Security Is a Runtime Enforcement Problem

The protocol is fine. The ecosystem is not.

SACR’s runtime identity paper uses MCP as the proving ground for ARISE, and the numbers are why. In the public ecosystem they surveyed, 53% of MCP servers rely on static secrets, only 8.5% implement OAuth, and the MCPTox benchmark showed tool poisoning succeeding 72.8% of the time. Most agents do not check whether a tool result is plausible. They incorporate it and continue.

MCP is not inherently insecure. The specification has room for authentication, authorisation, and credential isolation. The barrier to publishing a server dropped faster than the barrier to operating one like a production dependency. Organisations instantiate community servers and inherit whatever was committed to the repo – including, in documented Smithery cases, database passwords and cloud keys in plaintext.

This post in our ARISE series is failure mode five: cross-protocol visibility gaps. The Playbook’s wording is the one to take to architecture review:

Authentication is one moment. The consequential behavior is everything that follows, and most of it occurs entirely outside your identity governance stack’s visibility domain.

Your IdP saw the user sign in. It did not see the tool call.

Four risk layers, one runtime

SACR splits MCP risk the way you should split the work:

Supply chain. Unregulated servers, poisoned tools, backdoors in community packages. You will not audit every MCP dependency the way you audit npm, and even npm is a stretch. Allow-lists of which servers exist in the enterprise are table stakes. Runtime still has to assume a listed server can return a bad result.

Communication. Indirect prompt injection riding in tool results – the agent reads data that contains instructions to abandon the original goal. We covered the agent-side of that in defending MCP servers against prompt injection. Fast Company’s fire-brigade piece and aizome’s continuity argument both apply: the injection is not always visible at connect time. It appears in a later payload.

Authorisation. Standing access to a server means standing access to every tool that server exposes. Read-a-file and drop-the-production-database are different actions that often share a connection. MCP authorisation vs identity is the longer version: proving who connected is not downscoping what they may invoke.

Credential management. Long-lived secrets in config, env, and git. The maker-identity problem again: the MCP client runs as the developer’s token. Compromise one server, keep every downstream resource that token unlocks. This is borrowed identity with a protocol badge.

The Playbook’s enterprise guide is blunt that every MCP connection is a persistent trust relationship. What happens inside the session – which data, which actions, which instructions – is usually governed only by the MCP server itself. Most identity stacks have no visibility into that layer.

Gateway versus direct access

SACR documents two enforcement philosophies.

A gateway puts a choke point in front of servers: validate, policy, inject credentials. Strength: you can refuse the call. Weakness: you see request and response, not always the full reasoning; shadow agents that never route through you are invisible; if the industry moves from MCP to native “skills” and raw APIs, a gateway that only understands MCP is a lock on a quieter door.

Direct-access monitoring instruments the runtime (Cursor hooks, Claude hooks, endpoint). Strength: session context. Weakness: often reactive – you learn after the tool ran.

Neither is sufficient alone. SACR’s conclusion is the one we agree with: enforcement at the choke point, context from the runtime. RequestRocket is the former for HTTP-shaped MCP and for the APIs those tools call next. Noma, Astrix, Runlayer, and EDR vendors are betting on the latter. Buy both if your agent estate is real. Do not buy a story that one protocol proxy is the whole ARISE programme.

The obsolescence critique is fair and it is also why RequestRocket is not “an MCP product.” If the agent skips MCP and calls the Notion API directly, you still have an outbound HTTP call to an API you do not own. The control point has to survive the protocol fashion.

What to put on the wire without waiting for OAuth everywhere

You do not need every community server to grow up this quarter. You need the traffic you care about to stop carrying the organisation’s secrets and the organisation’s entire tool catalogue.

• Vault the upstream secret. The agent authenticates to you with a caller credential or a JWT from Okta/Entra. The server’s API key never sits in mcp.json. Rotation is one record. This is the same two-credential model as any other vendor API.
• Scope tools as paths and methods. “GitHub MCP” is not a permission. GET on pull requests is a permission. DELETE on repos is a different job. Deny-by-default on the proxy is organisational intent for a tool server. See scope collapse.
• Filter what returns. Tool poisoning and prompt injection both travel in the response. You cannot catch every encoded instruction with a regex. You can strip fields the job does not need, so the blast radius of a poisoned result is smaller. Response filtering is the ARISE-shaped version of data minimisation on this path.
• Meter the session. Recursive tool use is how cost and exfiltration hide in permitted calls. Meters are the envelope.
• Log the tool call as a first-class event your SIEM can join to the human who owns the agent. Authentication was one moment. This is the rest.

We have also written about OAuth-secured remote MCP and two policies every MCP deployment needs. Those remain true. ARISE adds the reminder that a well-authenticated MCP session can still be a poorly governed one.

Shadow MCP is the gateway’s honest limit

SACR’s critique of gateways is the shadow-agent problem: if traffic never hits the choke point, the choke point is irrelevant. Local Cursor, Claude Code, and Windsurf talking to community servers on a laptop are the fastest-growing blind spot in the paper. That is an EDR and MDM discovery problem first. The Playbook’s “start before you buy” list – query EDR for AI clients, pull MDM inventory, review OAuth grants, audit long-lived keys – is how you find those servers.

Once you have found them, you still need somewhere to send the traffic that should be governed. Forcing vendor keys out of local configs and into a proxy is how discovery becomes containment. Agents that keep a private copy of the secret are not “flexibly adopting MCP.” They are ungoverned identities.

Next steps

Inventory MCP servers the way you inventory SaaS: who runs them, which secrets they hold, which tools they expose. Move the secrets. Scope the tools. Assume the protocol will change; keep the outbound policy.

Tomorrow: why prompts are not that policy. Start for free.