MCP STDIO Launch Boundary

Why this page exists. A STDIO MCP server is a local process. If an agent host accepts a command from config, marketplace metadata, or a one-click install link, it is accepting code execution. The launch boundary gives that moment the same policy discipline as remote MCP authorization.

Rechecked August 23, 2026: MCP 2026-07-28 is still current and stateless. There is no negotiation handshake. Each request carries protocol version and capabilities. Servers MUST implement server/discover. STDIO remains newline-delimited JSON-RPC over a client-launched subprocess. Dual-era clients SHOULD send server/discover first before falling back to legacy initialize. kill_session here is a host-session kill switch, not Mcp-Session-Id.

The product bet

SecurityRecipes is positioned as the secure context layer for agentic AI. That claim is stronger when it governs both sides of MCP adoption: remote tools that need authorization and local tools that need launch control.

The MCP transport spec says the STDIO client launches the server as a subprocess, and the latest MCP security guidance calls out local MCP server compromise, malicious startup commands, sandboxing, consent, filesystem control, and network control. That makes STDIO launch review a natural enterprise product surface: before the agent sees a local tool, the platform can ask for a machine-readable launch decision.

The high-value reviewer questions are straightforward:

Which local MCP server commands are approved to run?
Can the launch install a package, execute a shell, or reach the private network?
Which environment variables and filesystem roots can the subprocess see?
Which launch changes require owner approval or full connector intake?
Which decision should an MCP client enforce before spawning?

Signal
Parse the launch request
Capture client, server ID, executable, argv, package/version, cwd, environment names, transport, user, and purpose.
Scope
Resolve executable trust
Verify absolute or approved path, package manager source, version, digest/signature, ownership, updates, and launcher indirection.
Decision
Inspect process boundaries
Check shell use, argument injection, environment secrets, cwd/workspace access, network, filesystem, subprocesses, and permissions.
Action
Launch or block
Allow a pinned sandboxed process, strip environment, require approval, hold, deny, or kill unsafe startup.
Proof
Record process evidence
Write resolved executable/package, sanitized argv/env names, cwd, permissions, decision, PID/status, and correlation.

Decision gate

Is the resolved launch immutable, shell-safe, minimally privileged, workspace-bounded, and free of exposed secrets?

Proceed

Start the approved STDIO server in its declared sandbox.

Hold or stop

Hold, deny, or kill unknown, mutable, shell-interpreted, secret-bearing, or overprivileged launch requests.

Evidence to retain

resolved command/package identity
argv/env/cwd/permission checks
launch decision and process receipt

Expected outputs

STDIO launch decision
safe client configuration
deny/containment record

Python companion

Run this playbook as a checked scenario

Evaluate an MCP STDIO server launch

Command

python scripts/security_recipes_remediation_suite.py playbook start --playbook mcp-stdio-launch-boundary --workspace . --finding finding.json --run-dir .security-recipes/runs/mcp-stdio-launch-boundary

Python suite guide

What was added

data/assurance/mcp-stdio-launch-boundary-model.json - source model for approved STDIO profiles, launch examples, decisions, red-team drills, and standards alignment.
data/evidence/mcp-stdio-launch-boundary-pack.json - generated launch boundaries, risk findings, source hashes, and reviewer evidence.
recipes_mcp_stdio_launch_boundary_pack, paired with recipes_playbook_plan using playbook id mcp-stdio-launch-boundary.

Run it locally from the repo root:

python3 scripts/generate_mcp_stdio_launch_boundary_pack.py
python3 scripts/generate_mcp_stdio_launch_boundary_pack.py --check

Evaluate the repo-shipped local server launch:

python3 scripts/evaluate_mcp_stdio_launch_decision.py \
  --launch-id security-recipes-local-stdio \
  --command python \
  --arg mcp_server.py \
  --sandboxed \
  --network-egress allowlist \
  --env-key RECIPES_MCP_TRANSPORT \
  --expect-decision allow_pinned_sandboxed_stdio_launch

Launch decisions

Decision	Meaning
`allow_pinned_sandboxed_stdio_launch`	The command, args, package, sandbox, environment, network, filesystem, and evidence all match the registered boundary.
`hold_for_owner_review`	The launch is known, but missing sandbox, approval, network, environment, or profile evidence.
`deny_unregistered_stdio_launch`	The launch ID or profile is unknown. Run intake before allowing it.
`deny_untrusted_package_launch`	The launch uses package-runner bootstrap, floating versions, unverified publisher state, or missing digest/signature evidence.
`deny_shell_or_network_bootstrap`	The launch uses shell wrappers, command chaining, broad network bootstrap, private-network reachability, or command drift.
`kill_session_on_secret_or_privilege_request`	The launch attempts to pass secrets, inherited credentials, root privileges, private keys, tokens, or prohibited data to the subprocess.

What the evaluator checks

Boundary	Examples
Command identity	Exact executable and argument list must match the registered launch.
Package provenance	Package runners such as `npx`, `uvx`, `pipx`, or `bunx` need digest, signature, and verified publisher evidence before they can move to a safer profile.
Environment	Secret-like keys such as tokens, API keys, passwords, SSH agent sockets, and private-key material kill the session unless explicitly allowed.
Network	Wildcard, unrestricted, private-network, or metadata-endpoint reachability is denied for local launches.
Filesystem	Declared roots and modes become the policy surface for endpoint or sandbox enforcement.
Approval	Browser automation, source-control write, registry publish, credential access, broad network, and subprocess-spawn capabilities require typed approval.

Current sample boundaries

SecurityRecipes Local Read-Only MCP Server: allowed when launched from the source-controlled repo with exact command, sandbox evidence, narrow environment, and allowlisted public index access.
Browser Research Package Runner Candidate: denied because npx -y package resolution at launch time, wildcard egress, and private-network reachability are too much trust for local research.
Containerized Registry Publisher STDIO Candidate: denied until the connector is redesigned because registry publish authority, private-network reachability, and the source intake decision make it too risky for local STDIO launch.
Untrusted One-Click Shell STDIO Install: denied because shell chaining, network download, broad filesystem write, and unowned package execution are not acceptable MCP client defaults.

Industry alignment

This feature follows current primary guidance:

MCP Transports defines STDIO as a client-launched subprocess and warns local HTTP transports to avoid DNS rebinding exposure.
MCP Security Best Practices covers local MCP server compromise, malicious startup commands, sandboxing, consent, filesystem control, network control, and scope minimization.
MCP Authorization says HTTP authorization guidance does not apply to STDIO; local credentials come from the environment, so environment policy matters.
OpenAI Agents SDK MCP supports hosted, Streamable HTTP, and STDIO MCP servers, which means enterprise governance needs to cover all transport modes.
OWASP Top 10 for Agentic Applications highlights tool misuse, identity abuse, agentic supply chain, unexpected code execution, cascading failures, and rogue agents.
OWASP Agentic Skills Top 10 treats agent skills as an execution layer and recommends verified publishers, pinned versions, isolated runtime, network restrictions, monitoring, audit logging, and approval workflows.
NIST AI RMF provides the governance frame for mapping, measuring, and managing AI system risks.
Google SAIF reinforces secure defaults, platform-level controls, adaptive mitigations, and business context for AI system risk.

How an MCP client uses it

Register every approved local STDIO server in the launch model with owner, command, args, package provenance, environment policy, filesystem roots, network policy, and evidence.
Generate the launch boundary pack and publish it to the internal MCP client, endpoint policy agent, or platform control plane.
Before spawning a STDIO server, call the evaluator with the actual command, args, environment keys, network posture, sandbox state, and approval record.
Spawn only on allow_pinned_sandboxed_stdio_launch.
Treat hold_for_owner_review, deny_*, and kill_* as enforceable outcomes with audit records.

CI contract

The generator fails if:

The model has malformed standards, profiles, launches, decisions, or red-team drills.
A launch uses an unknown profile or non-STDIO transport.
Required command, owner, evidence, environment, filesystem, or control fields are missing.
The connector intake pack cannot be loaded.
The checked-in evidence pack is stale in --check mode.

That gives SecurityRecipes a credible next product surface: local MCP client posture management, launch receipts, endpoint policy export, and continuous recertification for every subprocess an agent host can start.

MCP STDIO Launch Boundary

The product bet