Closed
Conversation
Collaborator
Author
|
Superseded by #524, which recreates this draft from main with a single clean commit and default-deny policy for all piece-level MCP transports. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
http,sse) enabled by defaultstdioMCP servers by default because they can spawn local commandspiece_mcp_serversconfig so project/global config can explicitly allow or denystdio,http, andsseWhy this draft exists
This is a middle-ground security proposal for piece-level MCP configuration.
The original concern is valid:
mcp_serversin piece YAML can reach the SDK and, forstdio, that means spawning arbitrary local commands. That is a very different risk level from remotehttp/ssetransports. 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:
stdiocan spawn local processes, so it is disabled by default for piece YAMLhttpandsseconnect to remote MCP endpoints, so they remain enabled by defaultIf an operator really wants to allow piece-level
stdio, they can opt in explicitly in project/global config:The same config can also disable
httporsseif 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_serverswithstdiotransport to launch arbitrary local commands under the operator account. That bypasses the mental model many users will have frompermission_modeorallowed_tools, because the process is started as MCP infrastructure rather than as an ordinary Bash tool call.Defaults in this draft
stdio: defaultfalsehttp: defaulttruesse: defaulttrueTesting
npm run buildnpm 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.tsTag