Build1 publisher3 min readPublished
Kong AI Gateway hides the rollback tool from Muse Code's investigator by filtering tools/list per identity
Meta's docs say Muse Code's MCP tools skip its sandbox and approval prompts, so one builder moved the permission check into Kong AI Gateway. For ops tools that can change production, an enforceable check has to sit on the tool side of the connection.
The Engineer · Build desk
What happened
- According to the author, setting shell_execute and file_write to ask in Muse Code's settings does not put any prompt in front of an MCP tool call.
- Kong's conversion-listener mapped each endpoint of an ordinary REST ops API to an MCP tool, so no MCP server had to be written.
- The gateway authenticates each caller, decides per tool, forwards allowed calls as ordinary HTTP requests and writes an audit entry for every decision.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Muse Code's ask settings cannot be the control for an ops tool with production write access, so the check has to live on the tool side, at a gateway or inside the MCP server.
- decision Teams wiring Muse Code to ops tools now choose between permission checks coded into every MCP handler and gateway ACLs that trim the tool list per caller.
- cost The gateway route turns permissions and tool routing into config that someone has to maintain and test, including route prefixes and the descriptions the model acts on.
The design starts from a line in Meta's documentation. According to the post's author, it says MCP tools operate outside Muse Code's sandbox and approval mechanisms and run as unrestricted child processes or network connections [2]. Muse Code reaches remote MCP servers over streamable_http [1]. A tool served that way is a network call that the client's controls do not cover [2]. The author wrote: "If one of your MCP tools can roll back a production deployment, the agent can roll back a production deployment, and nothing in the client will stop it." [4]
The documentation rules out the client as the place for the check. It does not say where the check should go instead. The author considered a bespoke MCP server with a role check in every handler. They wrote that it works, but every permission decision then lives in code that needs tests, and every caller sees the same tool list [5]. A shared API key was ruled out: "That is all or nothing. Anyone with the key gets every tool." [6] Kong AI Gateway 2.0 won because of one behavior: it applies per-tool access control lists per identity, and it applies them to tools/list itself [7]. So the evidence supports moving the boundary off the client. By the author's own account, a custom server would also have enforced it [5].
Filtering the tool list and rejecting a call are separate properties, and the author wanted both [16]. On the filtered list, the author wrote: "It cannot propose calling something it was never shown." [15] I think both are needed. The filtered list limits what the model plans with. Refusal at the gateway still stops a call that arrives anyway. The identities are also split along the right line. The investigator can write, because it opens the incident, but it cannot change production, and the author says a plain read-only key gets that distinction wrong [9].
Adopting this means keeping gateway config correct. Route /ops-mcp plus upstream url .../v1 plus tool path /ops-mcp/errors/summary resolves to http://host:9110/v1/errors/summary, and writing path: /errors/summary gets a 404 [11]. As permission-layer mistakes go, a 404 is a polite one. The author also wrote that "The description is not decoration." [13] The description for get-error-summary tells the model to use five-minute buckets to find the exact onset time and to see "which error type is actually growing rather than which is merely loudest" [12].
The goal was narrow: the first ten minutes of an incident, lining up a deploy timeline against an error timeline to find the change to blame, without fixing anything [17]. It ran against a mock ops API. That API is published in the kong-muse-oncall-toolkit repository along with the gateway config, a verification script and real agent transcripts [14]. The post includes a step that checks the boundary with the model out of the loop [18]. The available text of the post ends before that check's output. Moving the pattern to a real ops API adds one condition. The gateway has to be the agent's only network path to that API, because Meta's docs describe MCP tools as unrestricted network connections [2].
What to watch
- Whether Meta changes Muse Code's documentation or behavior so that MCP tool calls fall under the client's sandbox or approval settings.
- The output of the verification script in the kong-muse-oncall-toolkit repository, specifically whether a direct rollback call from the investigator identity is rejected at the gateway.
- A run against a real ops API with network rules that leave the gateway as the agent's only path to it.