Compare
Regulus vs NeMo Guardrails / Guardrails AI / generic guardrails libraries
Guardrails libraries operate on the prompt/response boundary. Regulus operates on the full agent trajectory — purpose limitation, residency, dual-control, audit envelopes.
Pick Regulus when
- You're building a regulated agent on Google ADK and need audit evidence mapped to specific regulation clauses, not just prompt-level safety.
- You need fail-closed residency, dual-control kill switches, GRC adapter dispatch — controls that live deeper than the model boundary.
- You're targeting EU/UK regulators (AI Act, GDPR, DORA, FCA SYSC) where the audit trail is the deliverable.
Pick Guardrails libraries when
- You're shipping a single-turn chatbot where the main concern is what the model outputs, not what tools it dispatches.
- You're not on ADK and don't want to be — guardrails libraries are largely runtime-agnostic.
- You need only prompt-level safety filtering (toxicity, jailbreak detection) and have your own audit infrastructure.
The surface area difference #
Guardrails libraries — NeMo Guardrails, Guardrails AI, similar — sit on the prompt/response boundary. String in, string out. They’re good at: prompt-level safety (toxicity, jailbreaks, hallucination detection on factual claims), output schema enforcement, and deterministic refusal patterns. None of these are bad things to have.
Regulus plugs into Google ADK’s plugin SPI, which means it sees
the full agent trajectory: BeforeAgentCallback, BeforeModelCallback,
BeforeToolCallback, AfterToolCallback, plus the service-extension
seams on session, memory, and artifact services. That’s where the
regulation evidence actually has to land.
What lives deeper than the prompt boundary #
A regulated AI agent’s compliance story isn’t about whether the LLM output is rude. It’s about:
- Purpose limitation (GDPR Article 5(1)(b)). Whether the tool call the agent is about to make is in-scope for the declared purpose of the processing.
- Fail-closed residency on memory and artifact services. Whether a memory write that’s about to happen is allowed in the resolved region. Guardrails libraries don’t see memory or artifact writes.
- Dual-control kill switches. Whether the agent’s tool surface has been collapsed by two authorised principals. Guardrails libraries don’t have an identity model.
- Hash-chained audit envelopes with framework citations attached. Guardrails libraries don’t emit audit events; if they do, the events don’t map to specific regulation clauses.
What this means concretely #
A guardrails layer can catch “don’t book a credit limit increase for
a customer who shouldn’t have one” if the model says so out loud. A
guardrails layer cannot catch “the customer’s purpose-of-processing
claim doesn’t authorise credit decisions, so the tool call must be
denied even though the model wants to proceed.” That’s a
BeforeToolCallback decision, on a Principal, against the active
profile. It’s structurally outside what guardrails libraries do.
Use them together #
Both layers can live on the same agent. Guardrails handles prompt- level safety. Regulus handles trajectory-level compliance. Each emits into the same audit chain when properly wired. There’s no either/or — there’s a layering question.
Where we differ honestly #
Guardrails libraries are easier to adopt. They don’t require ADK. They have well-developed prompt-engineering toolchains. If you’re not on ADK and don’t have regulator-level audit obligations, guardrails libraries probably solve the problem you actually have.
Regulus is the right answer when the obligations are EU/UK regulatory, the audit trail is the deliverable, and you’re shipping on Google ADK.