Your guardrail said no.Find out whether anything stopped.
Most AI guardrails are obeyed because the calling code chooses to obey them. That holds until the next refactor by someone who did not know why the check was there. This asks one question about each of your gates, and it is not about the gate's logic: who holds the refusal.
A guardrail nobody is obliged to obey is a suggestion.
The usual wiring looks like this: the agent calls a policy check, gets a verdict back, and the surrounding code decides what to do about it. That is a convention between two pieces of software written by the same person on the same afternoon. Nothing in the system enforces it. The tool is still reachable, the timeout path still proceeds, and the component doing the checking is the component being checked.
Who holds the refusal, what happens on a timeout, whether a route around exists, when the verdict is read, and whether an override is recorded.
Two gates in the worked example are identical everywhere except whether the checking code is the governed code. One reads FAIL-OPEN. The other reads DECORATIVE.
A tool takes the reading of the weakest gate in front of it. Adding a flawless fourth guardrail cannot raise it. It can only give you a fourth way to be wrong.
Move custody and watch a guardrail stop being one.
8 gates in total. One tool in the example is protected by a flawless gate and a weak one, and it reads as the weak one. Another gate cannot raise it.
This grades wiring, never people. It says nothing about whether any gate's verdicts are correct.
The full output on the worked example, verbatim.
Eight gates over five tools, one command, no dependencies. This is the complete run, pasted as printed.
GATE-TO-TOOL EXPOSURE KIT - custody report spec_version 1.0.0 | 8 gates read across 5 tools GATE NAME GOVERNED TOOL VERDICT DECIDED BY -------------------------------------------------------------------------------------------------------- G-01 Refund policy gate refund_api FAIL-CLOSED custodian G-02 Refund amount ceiling refund_api FAIL-OPEN custodian G-03 Publish safety check publish_endpoint DECORATIVE self_policing gate G-04 Outbound content filter outbound_email DECORATIVE custodian G-05 CRM write policy crm_write FAIL-OPEN on_gate_error G-06 CRM field validator crm_write DECORATIVE reachable_without_gate G-07 Ledger posting gate payments_ledger FAIL-CLOSED custodian G-08 Email rate guard outbound_email DECORATIVE custodian SELF-POLICING GATE G-03: the code that checks the verdict is the code being governed - decisive UNESTABLISHED ANSWERS (scored as the worst they could have been) G-05: on_gate_error - a better answer would have made this FAIL-CLOSED G-06: reachable_without_gate - a better answer would have made this FAIL-CLOSED G-08: on_gate_error - nothing they could have been would change this row PER TOOL (the weakest gate in front of it) TOOL GATES VERDICT WEAKEST ------------------------------------------------------------ refund_api 2 FAIL-OPEN G-02 publish_endpoint 1 DECORATIVE G-03 outbound_email 2 DECORATIVE G-04 crm_write 2 DECORATIVE G-06 payments_ledger 1 FAIL-CLOSED G-07 ESTATE 1 of 5 tools are held VERDICT: SOME TOOLS ARE HELD FIX FIRST: publish_endpoint (DECORATIVE) - start at gate G-03 REPORTED, NOT GRADED 8 gates in total. This count is reported and compared against nothing. A further gate in front of a tool cannot raise its reading. It can only give you one more way to be wrong. This grades wiring, never people. It says nothing about whether any gate's verdicts are correct.
Note refund_api. It is protected by a gate that reads FAIL-CLOSED and one that does not, and the tool reads as the second one.
Three rules, and the reason each one is not negotiable.
Where the code that reads the verdict is the code the gate exists to restrain, the restraint lasts exactly as long as that code keeps choosing to honour it. This is the one place the instrument overrules everything else on the row, and it only ever lowers a verdict.
If nobody has watched what happens when the gate times out, that is scored as the worse of the two things it could have been. The report then tells you whether establishing it would have changed the row, so you test the ones that matter.
Anything reaching the tool reaches it through the weakest path, so that is the reading. The engine proves rather than asserts this: across every arrangement it tests, adding a gate never raises a tool.
An enforcement check, not a permission layer.
- A read-off of who holds the refusal at each gate in your stack.
- A runnable engine, a workbook that reproduces it, and a demo that agrees with both.
- A per-tool roll-up that tells you which of your tools anything is actually holding.
- An emitter: one flag and the finding comes out as a verdict envelope a machine can be bound by.
- A judge of your gates. A gate with perfect custody and poor logic reads FAIL-CLOSED here.
- A permission layer. It never decides which identity may call what.
- A way to halt an agent already running. That is a different question.
- A scanner. It reads answers you supply about your own wiring and connects to nothing.
Scope: this is an engineering instrument. It grades the wiring around a gate, never a person, and asserts no regulatory position. It does not tell you whether a gate's verdicts are correct, and it is not legal advice.
For the stack where the agent already has the keys.
- An agent in your stack can call something that moves money, changes access or reaches a customer.
- You have added guardrails over time and could not say, today, which of them would actually stop anything.
- You are wiring gates to agents through MCP and want the enforcement contract settled before there are nine of them.
- Somebody asked what happens if the policy service is down, and the honest answer was that nobody has tried.
- Nothing in your stack executes without a person approving it first.
- You want to know whether your gate's decisions are correct. That is a different instrument.
- You are looking for a scanner. Every input here is an answer you supply.
The three it sits between.
The standard this kit emits against. That one asks whether the payload could bind a machine; this asks whether the refusal inside it is enforced.
OpenWhat an already-connected connector is permitted to touch. Permission and enforcement are different questions, and most stacks fail the second one.
OpenWhether the agent works. This assumes it works and asks what stops it when your own gate says it should not.
OpenDirect answers, before you buy.
You will find out eventually.
This is the cheaper way.
One purchase, lifetime access, 12 months of updates. $99, once.
Scope: an engineering instrument. It grades wiring, never people, asserts no regulatory position, and is not legal advice.
Sold by RedHub AI LLC · Secured by Stripe · redhub.ai