Skip to content

fix: gate piece stdio MCP servers by config#519

Closed
j5ik2o wants to merge 2 commits intomainfrom
fix/piece-mcp-servers-disabled
Closed

fix: gate piece stdio MCP servers by config#519
j5ik2o wants to merge 2 commits intomainfrom
fix/piece-mcp-servers-disabled

Conversation

@j5ik2o
Copy link
Collaborator

@j5ik2o j5ik2o commented Mar 15, 2026

The response policy for this will vary depending on takt's anomaly model. Such considerations may not be necessary if a user with appropriate permissions executes the command.

Summary

  • keep piece-level remote MCP servers (http, sse) enabled by default
  • disable piece-level stdio MCP servers by default because they can spawn local commands
  • add piece_mcp_servers config so project/global config can explicitly allow or deny stdio, http, and sse
  • enforce the policy in the piece loader so raw YAML remains parseable but execution-facing loading applies the transport gate

Why this draft exists

This is a middle-ground security proposal for piece-level MCP configuration.

The original concern is valid: mcp_servers in piece YAML can reach the SDK and, for stdio, that means spawning arbitrary local commands. That is a very different risk level from remote http/sse transports. At the same time, banning all piece-level MCP configuration is probably too strong if pieces are expected to use remote MCP servers as integration points.

Why this middle ground may be the right boundary

This draft separates the transports by actual risk:

  • stdio can spawn local processes, so it is disabled by default for piece YAML
  • http and sse connect to remote MCP endpoints, so they remain enabled by default

If an operator really wants to allow piece-level stdio, they can opt in explicitly in project/global config:

piece_mcp_servers:
  stdio: true

The same config can also disable http or sse if a deployment wants a stricter policy.

What can go wrong without this fix

Without this change, an untrusted or insufficiently reviewed piece can use mcp_servers with stdio transport to launch arbitrary local commands under the operator account. That bypasses the mental model many users will have from permission_mode or allowed_tools, because the process is started as MCP infrastructure rather than as an ordinary Bash tool call.

Defaults in this draft

  • stdio: default false
  • http: default true
  • sse: default true

Testing

  • npm run build
  • npm test -- --run src/__tests__/models.test.ts src/__tests__/it-piece-loader.test.ts src/__tests__/projectConfig.test.ts src/__tests__/globalConfig-defaults.test.ts src/__tests__/permission-mode.test.ts

Tag

  • #14_Untrusted pieces can launch arbitrary MCP server commands.txt

@j5ik2o
Copy link
Collaborator Author

j5ik2o commented Mar 15, 2026

Superseded by #524, which recreates this draft from main with a single clean commit and default-deny policy for all piece-level MCP transports.

@j5ik2o j5ik2o closed this Mar 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant