feature: Architecturally separate judge model for adversarial-resistant guardrails

[h-network]

Did you check the docs?

• I have read all the NeMo-Guardrails docs

Is your feature request related to a problem? Please describe.

Current guardrail enforcement relies on LLM self-checking (self_check_input, self_check_output, self_check_facts). The same model that generates responses also judges whether those responses are safe.

In adversarial testing, single-model self-enforcement degrades under sustained conversational pressure. Multi-turn prompt injection gradually shifts compliance boundaries through context manipulation — roleplay framing, appeal to helpfulness, layered exceptions. The
model progressively relaxes its own rules because the adversarial context is part of its conversation history.

Additionally, current rails primarily filter content (what the AI says), not actions (what the AI does). When agents have tool access, the dangerous artifact is the proposed action — a shell command, API call, or file write — not the natural language response.

Describe the solution you'd like

1. Stateless judge model — A separate model instance evaluates proposed actions with zero conversation context. It receives only the action payload and the ground rules. No conversation history means no multi-turn manipulation vector.
2. Dual-gate evaluation — Gate 1: deterministic pattern denylist (zero latency, zero inference cost, catches known-bad patterns). Gate 2: stateless LLM judge (catches novel/semantic threats the denylist can't express). Gate 1 executes before Gate 2.
3. Hierarchical conflict resolution — A priority-based layer hierarchy for safety rules. When rules conflict (e.g., "be helpful" vs "don't expose credentials"), lower layers always override higher layers deterministically. Eliminates ambiguous edge-case behavior.
4. Action-level filtering — Guardrails applied to the proposed action (tool call, shell command, API request), not just the natural language response. A benign-sounding response can contain a destructive tool call — content filtering doesn't catch this.

Describe alternatives you've considered

• Self-checking with stronger prompts: Tested extensively. Degrades under adversarial pressure regardless of prompt quality. The problem is architectural (shared context), not prompt engineering.
• Deterministic-only (no LLM judge): Predictable but has permanent blind spots. Any pattern not in the denylist passes with 100% reliability. Semantic evaluation is needed for novel threats.
• The dual-gate approach covers both: deterministic for known patterns, semantic for novel ones. Each covers the other's blind spots.

Additional context

Full specification with empirical testing results, conflict resolution semantics, conformance requirements, and reference implementation:

RFC-ASA-001: The Asimov Safety Architecture for Autonomous AI Agents
https://github.com/h-network/RFCs/blob/main/RFC-ASA-001-Safety-Architecture-LLMs.md

Reference implementation with 44 security hardening items:
https://github.com/h-network/h-cli

[Pouyanpi]

Thank you @h-network for your interest. Unfortunately, I don't understand this issue! is it requesting a specific feature?

• Not all the rails require access to conversation history.
• User can specify different models for different tasks and rails.
• We have tool rails and we might publish it in future releases

cc @cparisien

[h-network]

Thanks @Pouyanpi
To clarify, yes, this is a specific feature request.
The distinction from what exists today:

1. "User can specify different models for different tasks" — correct,
   but the judge model still receives conversation context. This proposal
   is for a judge that is architecturally stateless: it sees ONLY the
   proposed action + ground rules. Zero conversation history. That's what
   makes it resistant to multi-turn prompt injection — there's no context
   to manipulate.

2. "Not all rails require access to conversation history" — the issue
   isn't whether rails require it, it's whether the judge can access
   it. If it can, it can be influenced. Stateless means it can't.

3. "Tool rails", great to hear. The second part of this proposal
   (action-level filtering with deterministic denylist before LLM judge)
   would complement tool rails directly.

Happy to provide implementation details if helpful. I have a working
dual-gate implementation with benchmarks showing it catches prompt
injection that single-model self-checking misses.

[trebedea]

Hi @h-network ,

This seems like an relevant proposal if it improves multi-turn prompt injection performance. But we need some benchmarks or a study to show these improvements. Can you please share them?
And then we can discuss any implementation details.

Thanks,
Traian

[h-network]

Hi @trebedea

The proposal in this issue is about architectural isolation of the judge, not model “performance” in the latency/throughput sense.

More specifically, the claim is:

• current self-check rails rely on the same LLM stack judging outputs/actions produced in the same conversational context
• that shared-context design is vulnerable to multi-turn adversarial drift
• a stateless judge that sees only the proposed action plus fixed rules removes that manipulation surface
• deterministic denylist + stateless LLM judge is the proposed control structure

I’m asking because the current request for “benchmarks or a study” seems narrower than the actual architectural question.

For context, the codebase was already being actively modified in the same self-check LLM pipeline in PR #1616 (#1616), including changes in nemoguardrails/actions/llm/utils.py and nemoguardrails/library/hallucination/actions.py. So this does not appear to be an unfamiliar code area requiring preliminary abstraction before technical discussion.

If the blocker is specifically empirical validation of improved resistance to multi-turn prompt injection, I can provide that in a more explicit benchmark format. But first, can you clarify the architectural point directly:

Do you agree or disagree that a judge which can access manipulated conversation history is a weaker security boundary than a stateless judge which only evaluates the proposed action and fixed rules?

Benchmarks
https://github.com/h-network/Reports/tree/main/nvidiaGuardrails

The architecture and threat model are also written up in more detail here for reference:
https://datatracker.ietf.org/doc/draft-baysal-asimov-safety-architecture

Anthropic paper
https://www.anthropic.com/engineering/claude-code-auto-mode