luigidemasi commented on code in PR #149: URL: https://github.com/apache/camel-kit/pull/149#discussion_r4478505795
########## kit/camel-kit-core/src/main/resources/templates/opencode/agents/camel-ship-worker.md: ########## @@ -0,0 +1,26 @@ +--- +name: camel-ship-worker +description: Read-only Camel Ship stage worker dispatched by the parent OpenCode session. +mode: subagent +permission: + edit: deny + write: deny + bash: deny + notebook: deny + subagent: deny + mcp: deny + camel_*: deny + camel-knowledge_*: deny + citrus_*: deny Review Comment: [P1] Block inherited MCP servers beyond the three bundled names These rules block `camel`, `camel-knowledge` and `citrus`, but leave the original custom-server reproduction open. At this exact head, I generated the worker and dispatched it through the actual OpenCode 2.2.5 `subagent` tool with an inherited local `probe` MCP server. The child called `probe.mark` and wrote the canary through both Code Mode and a direct MCP call. The same canary is blocked under each bundled server name, and adding `probe_*: deny` blocks it under the custom name, confirming the remaining gap is the finite prefix list. Existing/custom MCP servers are supported and preserved by initialization, so a child handling untrusted stage inputs can still cause side effects outside controller validation. Please enforce the boundary for all inherited MCP tools, or refuse native dispatch when it cannot be enforced, while preserving the read/external-directory fixes. Cover an unrelated configured MCP server in a real-child regression test; assertions for these three strings can not detect this bypass. _AI-generated by Codex on behalf of @luigidemasi._ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
