In April 2026, OX Security and CSO Online walked through remote code execution against MCP servers that use STDIO transport. The security community treated it as a vulnerability disclosure. It is not one.
MCP's STDIO specification does not accidentally allow arbitrary local execution. It assumes the calling process is trusted, the configuration file is untampered, and the prompt content is clean. In production all three assumptions are routinely wrong. A junior developer adds an MCP server from a GitHub README. A prompt injection rewrites a config path. A compromised dependency ships a new server entry on npm install. All three failure modes use MCP exactly as specified. None of them are CVEs.
The pattern worth noticing: the agent security surface is not downstream of the model. It is upstream of it. The prompt is the last place a bad thing happens, not the first.
Safety layers patch the wrong end
Most agent security products shipping in 2026 are safety layers. They sit in front of the model, inspect prompts, score outputs, and block obvious abuses. They also assume the thing calling the tool is the agent the user thinks is calling the tool. That assumption is why they fail.
A safety layer cannot tell you that the MCP server your agent just invoked was installed yesterday by a teammate who trusted a README. It cannot revoke a permission that was never granted through it. It cannot produce a log that says "this tool call came from sub-agent B, acting on behalf of user X, at depth 3 of the call chain." That information does not exist in the prompt stream. It has to exist in the infrastructure.
The credible responses treat this as infrastructure
Two governance models worth studying are already doing this.
MetaComp's Know-Your-Agent (KYA) framework, reported out of Singapore, treats every autonomous agent as a regulated entity with an identity, a lifecycle, and a registered set of authorized actions. The explicit reference is FATF Travel Rule work for financial institutions. The agent is the regulated thing, not its output.
Ant Digital's 4R architecture, per their published materials, decomposes agent security into four runtime primitives: Registration, Routing, Rate-limiting, and Revocation. Every tool call passes through all four. The model is a component, not the perimeter. The perimeter is the infrastructure around it.
Both designs share a posture. They assume the model will say something unsafe, that a tool will be misconfigured, that a sub-agent will be subverted. They stop trying to prevent those things at the prompt and start containing them at the identity and permission boundary.
What this means if you are shipping agents now
If you are building on agents today, the uncomfortable call is this: your MCP servers, your sub-agents, and your installed skills are each a trust boundary, not a function call. Treating them as function calls is how you get STDIO RCE.
Three things are worth doing before any of this is regulated where you operate:
- Audit every MCP server your agents can reach. Who publishes it, how is it updated, what can it touch on the host.
- Prefer remote, streamable-HTTP transports over local STDIO where the option exists. Not because STDIO is insecure, but because the trust boundary is easier to draw when the server is not your own process.
- Give every agent and sub-agent an identity that outlives a single request, and log tool calls against it. The log is not optional. If you cannot answer "which agent did that, on whose behalf" after an incident, you do not have agent security. You have a safety layer.
The vendors selling safety layers are not wrong that the model will misbehave. They are wrong that the fix lives at the prompt. The fix lives where the trust boundaries actually are: identity, permission, lifecycle. That work looks a lot more like issuing certificates and running an IAM than it looks like tuning a filter.
Which is precisely why the regulators got there first.