A one-line omission in an MCP tool definition is enough to make an AI agent's approval gate silently disappear. Here's how I found it, closed it three ways, and then built a suite whose only job is to attack my own fix.
There is a function in TrueForge, the open-source agent harness, that decides whether an AI agent is allowed to touch your production systems without asking you first.
A tool that publishes no annotations at all matches none of those predicates. And the default approval policy is a list of tags:
So a rollbackdeployment tool that forgot its annotations does not get gated. It does not error. It does not warn. It fires straight at production, silently, and nothing in code review looks wrong. The tool is correct. The agent config is correct. The gate simply never triggers.
sentinel-agent is an autonomous incident responder. Hand it a production incident, and it investigates end-to-end — reads the incident, characterises the symptom, enumerates recent deployments, reads the actual diffs, exports raw metrics and computes the magnitude in an isolated sandbox — then correlates all of it into a root cause with a stated mechanism and a confidence number.
It will not change production state on its own authority. Ever. A human authorises that.
The split is the entire product: investigation is automated, execution is authorised.
That sounds like a nice slogan. The rest of this article is about why a slogan is worth nothing, and what it took to turn it into something a judge can actually check.
When checkout latency triples, an on-call engineer opens five tabs. Dashboards for the shape of it. The deploy log for what changed. GitHub for the diff. A terminal to compute whether the change is big enough to matter. And then a decision — roll back, or keep digging — made under time pressure with partial evidence.
Either the tool only reports — a dashboard summariser that leaves you exactly where you started. Or it acts autonomously, and now an LLM's inference is wired directly to your production control plane.
Neither is the interesting engineering problem. The interesting problem is the boundary between them, and where you enforce it.
This is the realisation the whole project reorganised around, and it did not come from design. It came from a code review finding.
My MCP server bound to 0.0.0.0 and served /mcp unauthenticated. Qodo flagged it. My first instinct was "it's a simulated estate, low severity."
The gate is enforced by the harness, not by the MCP server. So anything reaching the MCP server directly never encounters it.
Binding to all interfaces didn't weaken the safety model. It offered a way around it entirely.
That reframes the question. "Is rollbackdeployment gated?" stops being a property of a tool and becomes an empirical question with a potentially different answer for every route the harness can invoke it through.
Which means you cannot reason your way to the answer. You have to go and measure it.
Before measuring, I had to make the hole structurally impossible. Structural. Every tool is built through a defineTool where risk is a required field, and annotations are derived from it. There is no code path that registers a tool without them. Tested — against TrueForge's own predicates. This is the part I'd argue matters most. The test suite does not assert on my risk labels. It reimplements TrueForge's isWrite / isDestructive and asserts against the annotations the wire will actually carry. If my mapping is wrong, the test catches it rather than confirming it. Belt and braces. Destructive tools are named literally in requireapprovalfortools as well as covered by tag, so the gate holds even if an SDK version drops annotations in transit.