Write the MCP STDIO Install Record Before Local Execution

A local MCP server is not just a tool. It is a command your client may launch.

Short answer: Before adding an MCP STDIO server, write an install record. Capture the server source, exact command, arguments, config scope, exposed tools, credentials, filesystem access, network access, sandbox, approval owner, change triggers, and removal path. If nobody can explain why this local process should run, it should not be installed.

MCP makes tool setup feel lightweight.

That is useful. It is also where teams skip the wrong step.

A remote MCP server raises questions about OAuth, scopes, token audience, and consent. A local STDIO server raises a different question first:

What command are we about to let the client run on this machine?

If the answer is copied from a README, pasted into a config file, and approved with a vague prompt, the review is too thin.

STDIO means local process execution

The MCP transport specification defines STDIO as a transport where the client launches the MCP server as a subprocess. The server reads JSON-RPC messages from standard input and writes responses to standard output.

That detail changes the review.

The agent may see friendly tool names and descriptions. The operating system sees a process. That process has a command, arguments, working directory, environment, inherited credentials, file access, network access, and whatever permission boundary the host gives it.

So the first approval should not be "can the model call this tool?"

The first approval should be "should this local process exist in the agent environment at all?"

Why install records matter now

The public security record is already noisy enough to justify a stronger default.

OWASP's MCP Security Cheat Sheet treats MCP as a real permission surface. It calls for least privilege, sandboxing local MCP servers, inspecting tool descriptions and schemas, pinning tool definitions, reviewing consent and installation, logging, and supply-chain controls.

OX Security's public advisory on MCP STDIO command injection reports affected integrations where command and argument values in MCP STDIO configuration paths led to command injection or remote command execution.

Cloud Security Alliance's research note frames the same class of risk bluntly: command parameters in MCP STDIO server definitions should be treated as untrusted execution surfaces, and unapproved STDIO server entries should be blocked at the configuration level.

One MCP client implementation also shows why scope matters. Its MCP server setup documentation distinguishes local, project, and user scopes for server configuration. It also describes local STDIO servers as programs started as subprocesses on the user's machine.

That means the risk is not only malicious servers.

It is also sloppy installation, shared project config, stale server definitions, broad inherited environment variables, and local processes that outlive the review that approved them.

The install record

An MCP STDIO install record should be boring and specific.

The record does not need to be a huge governance artifact.

It needs enough evidence that a reviewer can answer three questions later:

1. What process did we allow?
2. What could that process reach?
3. What would force us to review it again?

What to review before adding the server

Start with the command.

Do not approve a generic command string because it appears in setup instructions. Resolve the executable. Check whether it calls a shell. Check whether arguments can be changed by the model, user input, project files, or environment variables. Prefer pinned versions and paths over floating names.

Then review the config scope.

A local user-only entry is different from a project-scoped entry that travels with a repository. A repository config can turn a clone into an approval prompt for every teammate. That does not make it bad. It makes the review record more important.

Then review what the process inherits.

A local server may see the user's working directory, shell environment, cloud credentials, SSH agent, git credentials, editor settings, browser profile paths, package-manager tokens, and other material that was never meant for an agent tool.

The install record should say what the server gets by design and what it is denied by default.

Safer default policy

Use this default until you have a stronger one:

1. No STDIO server without an install record.
2. No project-scoped server without human review of the exact config file.
3. No floating command path when a pinned path or locked version is possible.
4. No broad environment inheritance for servers that do not need it.
5. No home-directory read access by default.
6. No network access unless the server needs a named endpoint.
7. No secrets unless they are task-scoped and documented.
8. No tool description changes without re-review.
9. No command or argument changes without re-review.
10. No shared config that cannot be removed cleanly.

This is not anti-MCP.

It is pro-accountability.

MCP makes agent tooling easier to compose. The install record makes local execution easier to defend.

Red-team checks for MCP STDIO setup

If you are reviewing a local MCP server, test the setup before putting it into a normal developer or CI environment.

1. Can a project file change the command or arguments used to start the server?
2. Can a malicious tool description persuade the agent to add or modify another server definition?
3. Can the server read files outside the intended workspace?
4. Can it read cloud, Git, SSH, package-manager, or editor credentials from the environment?
5. Can it make outbound network requests when the workflow is supposed to be local?
6. Can a project-scoped config make other users approve a server they did not review?
7. Can a server update change tool descriptions or schemas without detection?
8. Can the server write to agent config, hooks, shell startup files, or workspace automation files?
9. Can logs show who approved the server, when it ran, what tools were exposed, and how it was removed?
10. Can the server be disabled without breaking unrelated agent workflows?

These checks are not theoretical paperwork. They find the boring paths that turn a helpful local integration into host-level access.

Evidence versus opinion

Evidence from the cited sources supports these points:

• The MCP STDIO transport launches a local server subprocess.
• MCP server configuration can define commands and arguments.
• MCP client configuration can have local, project, and user scopes.
• OWASP recommends least privilege, sandboxing, consent and installation review, supply-chain review, logging, and tool metadata review for MCP systems.
• OX Security and Cloud Security Alliance report serious vulnerability classes around unsafe MCP STDIO command handling in affected integrations.

VibeSec Advisory's opinion is the implementation rule:

Do not let the first real review happen after the server has already been added. The install record should exist before local execution, because command review, config scope, inherited credentials, sandboxing, and rollback are security decisions. They are not documentation chores.

Related field notes

• Write the MCP Consent Record Before Remote Tool Access
• MCP Tool Annotations Are Hints, Not Approval Gates
• Tool Results Are Agent Input, Not Ground Truth
• Sandbox Profiles Before Shell Access for AI Coding Agents

Sources

• MCP transport specification
• OWASP MCP Security Cheat Sheet
• OX Security advisory on MCP STDIO command injection
• Cloud Security Alliance research note on MCP STDIO risk
• MCP client setup documentation

Free next step

Review an MCP. Pick one local STDIO server you already use or plan to add. Write the install record before approving the next run, then compare the command, arguments, config scope, credentials, sandbox, and removal path against the record.

Browse the VibeSec Advisory Skill Library for more free agentic AI security patterns.