API discovery: Qwen Code’s public Tool Guard documentation describes a deliberately narrow interposition point for a managed agent. Start qwen serve in required mode with a loopback provider URL. The provider completes POST /v1/handshake at startup, then answers POST /v1/prepare before each supported top-level managed tool invocation reaches the executor.
The prepare request carries a session ID, prompt ID, tool-call ID, canonical tool name, and final arguments. A minimal affirmative reply is { "protocolVersion": 1, "requestId": "<echo>", "allowed": true }. Timeouts, malformed responses, a mismatched request ID, and a denial all stop execution. The companion capability protocol says the daemon advertises the feature only after the required startup handshake succeeds.
Try it as a tiny change-control desk
Build a loopback-only provider that lets read-only inspection proceed but asks a small local policy service to decide when an agent wants to write a file, invoke a shell, or call a connector. The useful prototype is not a magical security oracle. It is a visible decision record: “this is the final tool name and arguments Qwen Code was about to execute; allow or deny it here.” Use a disposable workspace and a local secret, because the guard receives final arguments that may contain sensitive application data.
Copy-paste agent instruction
Build a disposable, loopback-only Qwen Code Tool Guard provider for a test workspace. Implement POST /v1/handshake and POST /v1/prepare with bearer-token authentication, protocolVersion 1, and exact requestId echoing. Log only the tool name and a redacted decision summary; do not persist final arguments. Default to deny on timeout, malformed input, or an unknown tool. Configure qwen serve with required Tool Guard mode, then demonstrate one allowed read-only tool call and one denied write-like call. Document every command that remains outside this guard boundary.Test caveat
This is a source-level API discovery, not a claim that a policy service is ready to deploy. Qwen Code’s docs cap request and response sizes, require an operator-managed bearer token, and specify a per-call timeout; your setup may still fail on credentials, process startup, latency, or tool semantics. More importantly, the source says Tool Guard does not sandbox a command, does not govern hooks, and does not cover every side effect. Treat it as one final-call control, then test its gaps before you call it a safety boundary.