Who Guards the Guardrail? Why a Second LLM Watching the First Is Not Governance

Blog · Conversational Agents

Your AI Guardrail Is Just Another AI You Also Can't Trust.

By Rohit Gupta7 min read

Short answer

The category wraps every agent in a supervisor — or compiles policy into the agent itself. Both lower the odds of a bad action. Neither makes it impossible, because the thing deciding to act is still a model.

Every serious agent platform now ships a guardrail. One camp wraps each production agent in a supervisor that audits its every action. Another compiles policy into the agent itself so the model, they say, cannot override it. Both genuinely lower the odds of a bad action. Neither makes a bad action impossible — because the thing deciding to act is still a model, and the guardrail still lives inside or beside the very agent it is meant to police.

The trust-layer camp's promise is elegant: every production agent is managed by supervisory agents that audit what it does — an observe-to-intercept loop that catches the model before it goes wrong. Give them credit. This works more often than it doesn't. A second model scoring the first's proposed output is a real improvement over an unmonitored agent, and across high-volume support queues it prevents a large number of genuinely bad actions.

But look at the topology. A probabilistic actor proposes; a probabilistic observer judges. Both are language models with, by construction, a non-zero error rate. "Observe-to-intercept" only intercepts if the observation completes before the side effect commits — and if the observer does sit synchronously in the path of the action, you have not removed the model from the decision, you have added a second one. The supervisor is not a gate the action must pass. It is a watcher standing around the action, hoping to tap the brakes in time. When it misses — and anything probabilistic misses some of the time — the connector call has already left the building.

The governance-first camp saw this and moved the control earlier. Their argument is one we largely agree with: prompts are not a control plane, and natural-language instructions are a weak place to put a policy. So they compile the policy into the agent, hand-script the critical branches, and validate the whole artifact before launch. Compiled guardrails and scripted decision paths are meaningfully more robust than a system prompt full of "please do not." This is the camp closest to our own thinking, and it deserves a precise critique rather than a lazy one.

Here is the structural limit, and it holds regardless of any product's roadmap. Governance authored into the agent at design or compile time is authored by the builder — and the same hand that authored it can loosen it: widen a threshold in the next release, add an exception branch, ship a variant with the check relaxed. "Validated before launch" is a statement about the build; the action happens at runtime. Nothing compiled into the agent is a party the agent must satisfy that is independent of the agent. It is the agent grading its own homework with a better rubric. A rubric is not a gate. A gate is something outside the actor that the action must physically pass through — and that the actor cannot rewrite on its way through.

You do not have to take our word for the gap — the category is documenting it. The governance-first camp's own research has found that most failed autonomous actions had safeguards in place beforehand, and that a majority still executed consequential actions despite those safeguards. Read that twice: the safeguards were present and the actions fired anyway. From the other direction, the autonomy-forward camp openly concedes that models hallucinate and leans on after-the-fact quality assurance to clean up what slips through.

Both admissions point at the same architectural fact: a safeguard that lives inside or beside the agent shares the agent's failure modes and its blind spots. When the agent is wrong in a way its own design did not anticipate, a guardrail built from the same assumptions tends to be wrong right along with it.

OBSERVE-TO-INTERCEPT the action can still fire Supervisor LLM Conversational agent watches External API / system fires PROPOSE → GATE → ACT a non-compliant action cannot execute Atomic Agent proposes GATE approval seg. of duties threshold HITL Governed Connector immutable per-action audit utterance → intent → gate → connector → effect

There is a distinction the marketing blurs, and it is the whole game. Deterministic access control is real: many platforms can say, with certainty, that a given identity may read from or write to a given system of record. That is worth having. But controlling whether an identity can reach a system is not the same as controlling whether a specific proposed action is allowed to execute at this moment.

Consider a voice agent asked to issue a refund. The caller's identity may be fully entitled to issue refunds — deterministic ACCESS to the billing system is satisfied. And still this particular refund may be over the caller's authority limit, may require a second approver it does not have, may violate a separation-of-duties rule, may breach a policy threshold. Deterministic ACCESS answers "can this badge open this door?" Deterministic GATING of the ACTION answers a harder question: "should this specific action, with these parameters, in this sequence, pass — right now?" A platform can nail the first and never once ask the second.

This is the difference Entroid is built around, and it is architectural, not aspirational. In our fabric, a conversational agent is not a product bolted on top of your systems. It is an Atomic Agent with a dialogue interface — a first-class primitive inside one governed runtime, composed with the others rather than wrapped by them.

Follow a single utterance-to-action through it. Three primitives carry the load:

  • Intelligence Orchestration binds the proposed action to the invoking identity's real entitlements — the agent inherits the caller's authority, not a service account's. It decides the path; it does not do the work.
  • Deterministic Workflows enforce the gate inline — approval, segregation of duties, authority and threshold limits, human-in-the-loop checkpoints — so a non-compliant action is impossible, not merely detected after it fires.
  • Governed Connectors are the only primitive that touches an external system, and they execute only after the gate is cleared, under real authentication, authorization, and rate limits.

Human-in-the-loop here is a routed step that pauses before the irreversible action and resumes only after a decision — not an escalation reached after the agent has already given up, and not a rubber stamp on something already done. Every step, utterance to intent to gate to connector call to system effect, is bound in an immutable per-action audit.

Take the refund again. In the supervisor topology it fires and is, hopefully, caught. In the inline-gate topology the proposal halts at the threshold gate and routes to a human checkpoint before any Connector writes a cent. The agent can be as wrong, as jailbroken, as hallucinated as you fear; the non-compliant action still cannot execute, because the gate is a runtime primitive the agent can neither author, loosen, nor bypass. The agent proposes. The workflow disposes.

Be honest about what this is and is not. It is not zero integration — the fabric executes over your existing systems through governed Connectors, with real plumbing behind them. What changes is not the amount of plumbing; it is where the decision to act is made. In the supervisor and compile-time models, the moment of action is a probabilistic event with a watcher nearby. In ours, the moment of action is a deterministic gate the action must pass — or it does not happen. The question stops being "does the agent converse and resolve well?" and becomes "can it be trusted to act — correctly, authorized to the caller's real entitlements, provably, every time, across any enterprise process rather than just the support queue?"

A supervisor lowers the odds of a bad action. A gate removes the possibility. That gap is where governance actually lives.

See what this looks like for your enterprise.

Not a demo. A strategic conversation about how your enterprise could operate
when every process runs on one governed fabric.

Start the Conversation