If you are building AI agents with MCP, there is one detail about STDIO transport that is easy to miss.
The client reads a config value.
That config value contains a command.
The command runs.
Only after that does the client find out whether the command started a valid MCP server.
If the command starts a real MCP server, the agent gets a working tool connection.
If it does not, the agent gets an error.
But the command already ran.
That is the part developers need to sit with. This is not just a bug in one app. According to works.
The short version
published research in April 2026 after auditing MCP for five months.
Their finding was simple but serious:
If attacker-controlled input reaches an MCP STDIO launch command, the attacker may be able to run code on the host.
OX grouped the risk into a few paths:
Direct command injection. Some AI frameworks passed user input into STDIO server configuration without enough validation.
Allowlist bypasses. A product might allow only a trusted launcher such as npx, but still allow attacker-controlled arguments. If the arguments can change what npx runs, the allowlist does not protect much.
IDE prompt injection. A coding agent or IDE may process untrusted content from files, web pages, repos, or tool responses. If that content can cause the agent to modify local MCP config, the next tool launch can become code execution.
One confirmed example was , is that this behavior is expected.
There is some logic to that.
STDIO exists so a client can launch a local MCP server. If the protocol aggressively strips arguments or blocks command patterns, it may break legitimate tool setups.
The counterargument is also reasonable.
A protocol that becomes a default integration layer cannot assume every downstream team will design safe command validation on its own.
Most teams using MCP are not trying to become experts in command execution safety. They are trying to connect an AI agent to useful tools.
That is the supply chain problem.
A risky default at the protocol or SDK layer becomes a repeated bug across many products.
What to check in your own MCP setup
If you are using MCP STDIO, I would start with these tests.
1. Can user input reach the command or args?
Search for places where input flows into values like:
StdioServerParameters(
command=...,
args=...
)
Or the equivalent in your language or framework.
If user input reaches either field, treat that as command execution risk.
Do not only check direct form fields. Also check:
- imported project files
- generated config
- agent-written config
- tool manifests
- marketplace package metadata
- setup scripts
- repo instructions
- issue or PR content consumed by an agent
2. Does your allowlist validate the whole expression?
An allowlist that checks only this:
"command": "npx"
is incomplete.
You also need to validate the args.
Better still, map allowed tools to fixed command templates.
For example:
That is safer than letting user-controlled input build the command.
3. Can the agent silently modify MCP config?
This is the part teams will miss.
The risk is not only "did the user type a bad command?"
The risk is also "can the agent change the config after reading hostile content?"
Config changes that affect STDIO launch behavior should require deliberate confirmation. A silent update to an MCP server command should be treated like a code change.
4. Are MCP servers exposed publicly?
If an MCP-connected service is reachable from the public internet, put authentication and network controls in front of it.
Do not treat AI tooling as a harmless dev utility. These systems often hold API keys, local file access, database handles, or cloud credentials.
5. Where did the MCP package come from?
Treat MCP servers like npm packages.
That means checking:
- publisher identity
- repo history
- install scripts
- version pinning
- package age
- permissions requested
- whether the package is from an official source
A marketplace listing is not enough.
The QA lesson
The most useful test case is not "can I jailbreak the model?"
The better test is:
Can untrusted content cause the agent to create, modify, or launch an MCP STDIO server in a way that changes what code runs?
That gives QA and security teams a concrete workflow to test.
Put malicious instructions in places the agent is likely to read:
- README files
- docs pages
- issue comments
- PR descriptions
- web pages
- tool responses
- package metadata
- generated setup instructions
Then verify that the agent cannot turn those instructions into local MCP config changes or unsafe tool launches.
This is where a lot of AI security testing is going next.
Not just prompt input.
Not just model output.
The whole path from untrusted content to tool execution.
The OWASP mapping
This fits cleanly under .
An agent that can launch local processes through weakly validated config has more capability than most users realize.
That combination is the real issue:
Supply chain risk gives the agent a dangerous tool surface.
Excessive agency lets it use that surface.
Prompt injection gives an attacker a way to steer it.
Bottom line
MCP STDIO is useful.
It is also sharp.
If you use it, do not ask only whether the MCP server works.
Ask what command runs before the server proves it worked.
Because with STDIO, the connector is not just a connector.
The connector is the shell.
Further reading
For more detail, see my full writeup, .
Primary research:
Windsurf advisory: and LLM06 Excessive Agency
SOCIAL SHARE CARD GENERATOR