Use case
LLM guardrails that enforce, not just warn
A system prompt asking a model to behave is a request, not a control. A dashboard that flags a bad output after it ships is already too late. Turrigan is a guardrail that sits inline and acts. Every AI output passes one chokepoint that returns allow, block, or escalate in milliseconds, screened by a deterministic detector floor with no LLM in the hot path.
Why prompt-based guardrails are not enough
- A system prompt is an instruction the model can be talked out of. Prompt injection and jailbreaks exist precisely to defeat instructions.
- Sampling makes behaviour a coin toss at scale. The same prompt can pass nine hundred and ninety-nine times and fail on the thousandth. Guardrails that live inside the model inherit that variance.
- An LLM checking an LLM adds latency, cost, and its own nondeterminism to the very thing it is supposed to make reliable.
What Turrigan screens on every output
Eight deterministic detectors, in English and Arabic, run inline and outside the model:
- Personal data, with redaction spans.
- Prompt injection.
- Unsafe content (safety screening).
- Unverifiable claims, checked against a source of truth you supply. See grounded verification.
- Excessive agency, for what an agent is about to do.
- Uncertainty abstention, so a low-confidence answer is held rather than shipped.
- Fairness tagging.
These map to the OWASP LLM Top 10, so the risks you already track have an enforced control behind them rather than a line in a policy.
Allow, block, or escalate
Each output gets one verdict. Critical findings block. Uncertainty escalates to a human. The floor fails closed, never open, so a detector that cannot reach a confident verdict holds the output for review instead of letting it through. This is the difference between a guardrail that watches and one that acts.
Deterministic by design
The detector floor is deterministic and offline. There is no cloud LLM in the hot path, so verdicts land in milliseconds instead of seconds, there is no per-token cost, and the same output always produces the same verdict. It is ReDoS-safe and has been hardened against five thousand-case adversarial corpora across the floor. It can run self-hosted or air-gapped with no external AI service in the decision path.
Guardrails for agents, not just chat
AI agents call tools on their own. Those tool calls pass the same chokepoint, so a guardrail is not only something that reads text. It governs what an agent is about to do, before it happens.
Every verdict leaves evidence
A guardrail you cannot audit is a promise. Every Turrigan verdict lands in an append-only, hash-chained log, redacted and explainable, and mapped to the exact control it satisfies. Tampering is mathematically detectable, so months later you can prove not just what was blocked, but that the guardrail was in force when it mattered.
Frequently asked questions
Are these guardrails just a system prompt?
No. The detectors are deterministic and run inline, outside the model. A jailbreak or prompt injection that fools the model does not bypass them, because they screen the output rather than instructing the model.
Does Turrigan add noticeable latency?
No. The core is deterministic with no LLM in the hot path, so verdicts land in milliseconds, not seconds, and there is no per-token cost.
Can guardrails run without sending my output to an external service?
Yes. The deterministic core can run self-hosted or air-gapped with no external AI service in the decision path, which supports confidentiality and data-sovereignty requirements.
What happens when a detector is unsure?
The output escalates to a human. Critical findings block, and the floor fails closed, never open, so a low-confidence output is held for review rather than shipped.