ServiceSandboxConfig exposes mcp as a single boolean: the construct MCP server is either injected into the session's harness or it is not. The design describes this axis as "mcp tools — allowlist which MCP servers/tools the session may call".
The gap is real but narrower than it first looks, and the boundary is worth stating precisely so this is not over-implemented:
fleet_control and mcp both currently gate fleet access — the daemon's own tools, and the construct MCP server that is how some harnesses take that same access. They are two doors to one room.- An allowlist over arbitrary MCP servers is a different feature: those come from the harness's own configuration, not from the service definition, and confining them means the service definition constraining what the harness may load.
Worth deciding whether this is (a) per-tool granularity on construct's own MCP surface — e.g. read-only fleet visibility without agentd_send_input — or (b) a general allowlist over every MCP server a service session may reach. (a) is a natural extension of what shipped in #1111. (b) is a larger boundary question.
Note the sibling axes are deliberately absent and should stay absent: filesystem and network egress are not service-configurable on purpose, because the harness sandbox already confines writes to the session cwd and denies egress, and a service definition must not be able to relax a boundary the harness enforces (spec 0170).
ServiceSandboxConfigexposesmcpas a single boolean: the construct MCP server is either injected into the session's harness or it is not. The design describes this axis as "mcp tools — allowlist which MCP servers/tools the session may call".The gap is real but narrower than it first looks, and the boundary is worth stating precisely so this is not over-implemented:
fleet_controlandmcpboth currently gate fleet access — the daemon's own tools, and the construct MCP server that is how some harnesses take that same access. They are two doors to one room.Worth deciding whether this is (a) per-tool granularity on construct's own MCP surface — e.g. read-only fleet visibility without
agentd_send_input— or (b) a general allowlist over every MCP server a service session may reach. (a) is a natural extension of what shipped in #1111. (b) is a larger boundary question.Note the sibling axes are deliberately absent and should stay absent: filesystem and network egress are not service-configurable on purpose, because the harness sandbox already confines writes to the session cwd and denies egress, and a service definition must not be able to relax a boundary the harness enforces (spec 0170).