Drel vs. runtime AI firewalls and LLM guardrails

Runtime AI firewalls and LLM guardrails are purpose-built for inline enforcement at inference time. They are good at:

• Prompt injection detection and blocking. Identifying and stopping attempts to override system instructions, whether direct or indirect via retrieved content.
• Output filtering. Scanning model responses for PII, toxicity, off-topic content, or policy violations before they reach the user.
• Topic restriction enforcement. Keeping the model within a defined scope — refusing to answer questions outside the permitted domain.
• Rate limiting per user or session. Throttling inference requests to prevent abuse or runaway costs.
• Real-time anomaly detection on inputs and outputs. Flagging unusual patterns in what users send and what the model returns.

The question they answer is narrow and precise: is this specific inference safe to execute or return? That precision is their strength.

A runtime firewall that blocks prompt injection is a control. But the governance record must do more than implement a control — it must specify that the control is required, what it must cover, and what evidence proves it is operating. Runtime firewalls do not produce that record.

1. They do not produce a Risk Disposition memo. There is no artifact that says this system was reviewed, the decision was conditional proceed, and the conditions were these specific controls. The firewall logs what it blocked; it does not record why the system was cleared to operate in the first place.
2. They do not tell the AI Committee whether the system was reviewed. A runtime firewall can be deployed without any governance review having occurred. Its presence does not imply that a CISO, AI Governance lead, or DPO has seen the system and accepted its residual risk.
3. They do not record who reviewed the system, or under what conditions it was cleared. The sign-off log — who approved, in what role, on what date, with what caveats — is a governance artifact. It does not exist inside a firewall product.
4. They do not encode re-assessment triggers.If the model changes, a new tool is added, or the autonomy level increases, the firewall continues operating. Nothing in the firewall says “this clearance expires if the model is swapped.”
5. The firewall is the implementation; Drel is the record that the implementation was specified, verified, and accepted. An auditor asking for evidence of your AI risk management process cannot be handed firewall block-rate logs. They need the control plan that named the firewall as a required control, and the evidence that it was configured and verified against that specification.

The relationship between Drel and a runtime AI firewall is not competitive — it is sequential. Drel's control plan names the required runtime controls. The firewall implements them. The evidence pack references the firewall configuration as proof that the control is in place.

In practice, this means:

• The Drel control plan for a customer-facing LLM feature might specify: “output filter for PII before returning to user” and “prompt injection detection on all user inputs.” Those are required controls, not optional recommendations.
• The runtime firewall implements those controls. Its configuration is the evidence that the control is in place. The Drel evidence pack references that configuration by artifact ID.
• When the AI Committee reviews the disposition, they see: control required, control implemented, evidence verified. The firewall logs are the supporting artifact, not the primary record.

A system with a runtime firewall but no governance record has enforcement with no accountability. A system with a governance record but no runtime firewall has a control plan with a gap. Both gaps are problems; they are different problems.