blastdoor

Overview ¶

Command blastdoor is the k8s MCP-gateway companion to the cloudops demo. Where cloudops enforces an incident grant at a cluster control plane, blastdoor adds the three things an MCP tool gateway uniquely provides:

1. tools/list FILTERING — the agent connects to a kubectl/helm MCP server THROUGH Legant; the gateway returns only the tools the delegation allows, so destructive tools (kubectl_delete, helm_uninstall) and the flag-injection surface kubectl_generic (cf. CVE-2026-47250 in the Flux159 k8s MCP server) are never even DISCOVERED by the agent.
2. A change-FREEZE window — a cluster-wide deploy-window policy (the Legant TimeWindow primitive) the gateway enforces on MUTATING tools, so during a freeze the agent can still read logs but cannot scale or restart.
3. A mid-loop offline kill — the token the agent already holds is refused at the gateway, offline, in the middle of a remediation loop.

Everything is enforced OFFLINE from the signed token via the public SDK; there is no callback to Legant. No database, no Docker:

go run ./examples/blastdoor
# or
make demo-blastdoor

NOTE (honest): filtering tools/list is defense-in-depth, not the security boundary — the allow-list in the signed token is. An agent that guesses a hidden tool's name and calls it directly is still refused by the token, as shown below. Legant can't constrain an agent that bypasses the gateway to hit the API server with a raw kubeconfig; it's the authority/constraint layer on top of k8s RBAC.