Reading Paths¶

This site covers a lot of ground. These curated paths help you find what matters most based on what you are trying to achieve. Each path is a suggested sequence, not a strict order. Skip what you already know, dive deeper where you need to.

Shipping your first LLM feature?

If you need a short, opinionated list of controls to put in place before going live, start with AIRSLite. Seven controls, one checklist, one decision tree for whether you need to go deeper.

Looking for role-based guidance?

The Stakeholder Views pages provide tailored entry points for security leaders, risk teams, architects, engineers, product owners, and more. Each one includes a starting path, concrete first actions, and answers to common objections.

The Golden Thread: Guardrails, Judges, and Why They Work Together¶

This is the core reading path. It takes you from "why do I need runtime security at all?" through each control layer, how they reinforce each other, and the evidence that the approach works. Each article answers a question the previous one raises.

Start here if you are new to the framework, or if you want to understand the reasoning behind the architecture before diving into controls and checklists.

The path follows the same logic you would in practice. Act I: understand the behaviour you need to secure. Act II: choose the right guardrails and judges for that behaviour. Act III: monitor, learn, and improve.

Act I: Know the behaviour¶

Before you pick controls, you need to understand what you are protecting. What does the agent do? What was it supposed to do? How would you tell the difference between it working and it failing?

#	Article	What it argues	What it sets up
1	Why AI Security Is a Runtime Problem	AI is non-deterministic. Pre-deployment testing cannot prove future safety. You must observe behaviour continuously because you cannot predict it in advance.	We need to watch behaviour at runtime. What does "good behaviour" even mean for an agent?
2	Containment Through Declared Intent	An agent without declared purpose is uncontrollable. Intent gives every control layer its reference point: guardrails know what to block, the Judge knows what alignment looks like, humans know what to escalate.	We have defined intent. But knowing what to look for is not the same as knowing how to look. What do we observe?
3	Process-Aware Evaluation	Evaluating what an agent produced matters less than evaluating how it got there. The full trace (tool calls, data accessed, reasoning steps, delegation decisions) is where the real failures hide. Correct outputs from compromised processes are still failures.	We understand intent and behaviour. How do we choose controls that match?
4	The Constraint Curve	Early constraints deliver outsized security at minimal cost. Late constraints destroy the value that justified using AI. The art is proportionality: enough control to manage risk, not so much that you kill the use case.	We know what to protect and how much to constrain. Now, what are the actual controls?

Act II: Choose guardrails, semantic checks, and judges¶

With behaviour understood and proportionality in mind, now select and configure the control layers. Each article explains a layer, what it catches, and what it misses.

#	Article	What it argues	What it sets up
5	Why Your Guardrails Aren't Enough	Guardrails catch known-bad patterns. Three classes of failure walk past them: novel attacks, semantic violations, emergent behaviour at scale. Necessary, not sufficient.	What should guardrails actually cover?
6	Practical Guardrails	Guardrails work in two classes (security, data protection) at five pipeline points. International PII, secrets detection, RAG filtering, exception governance. Build them well.	Guardrails handle known-bad patterns. What catches the same intent in wording they have never seen?
7	The Semantic Firewall	Semantic checks and context validation. Classify the intent of a request against a declared taxonomy and validate it against the deployment's declared scope, catching known-bad intent in novel wording in 15 to 30ms. It sits between guardrails and the Judge and narrows what reaches the expensive layer.	Fast semantic checks catch known-bad intent. What catches the genuinely unknown-bad behaviour?
8	The Judge Detects. It Doesn't Decide.	The Judge runs asynchronously, detecting unknown-bad without blocking. It evaluates against the declared intent and behavioural trace. It informs human decisions rather than replacing them.	How do we know the Judge actually works?
9	Judge Assurance	Validate the Judge against human ground truth. Track agreement, false negatives, drift. Different model family from the generator. Calibrate continuously.	The Judge can be validated, but can it be attacked?
10	When the Judge Can Be Fooled	The Judge is itself an LLM. It can be manipulated through output crafting, prompt injection, and shared blind spots. Mitigations exist but perfection does not.	If no single layer is reliable on its own, what holds the system together?
11	Humans Remain Accountable	Humans own outcomes. The Judge makes oversight scalable, not optional. Regulation requires it.	We have layers. How do we enforce them outside the agent's control?
12	Infrastructure Beats Instructions	Telling agents what not to do fails. Make violations technically impossible through network controls, access restrictions, and action allowlists enforced outside the agent.	Controls are in place. How do they stay effective over time?

Match the review control to latency and accuracy

The Judge is one review process among several, and it is the slowest and least independent of them, because a second LLM shares the first one's blind spots. Every control trades latency against accuracy and against how much it actually reviews. Pick the one that fits the claim and the risk tier, not the one you reach for by habit.

Review process	What it reviews	Added latency	Accuracy	Best for
Guardrails	Known-bad patterns	10-50ms	~85%	Cheap deterministic first pass
Semantic Firewall	Known-bad intent, novel wording	15-30ms	High on a declared taxonomy	Narrowing what reaches the Judge
Knowledge-graph or API lookup	Factual claims	50-100ms	~92%	Facts in a covered domain
Token-level uncertainty	Model confidence in RAG	80-160ms	~96% signal	RAG with source documents
Formal verification	Documented-rule compliance	200-500ms	~99%	Regulated, well-documented policy
Model-as-Judge	Unknown-bad behaviour	500ms-5s	~80%	Behavioural alignment, not facts
Human review	Judgement calls and edge cases	Minutes+	Highest, does not scale	Critical-tier sampling and escalation

Cheaper checks sit at the top, more independent fact checks in the middle, the Judge near the bottom because it shares the generator's blind spots, and humans as the backstop. No single control covers everything, so high tiers combine independent ones. The Verification Gap has the full matrix and how to combine them; the reviewing reading path walks the sequence.

Act III: Monitor and improve¶

Controls degrade. Attackers adapt. Models drift. The system only stays effective if every layer feeds information back into the others.

#	Article	What it argues	What it sets up
13	The Feedback Loops That Make It Work	Four feedback loops at different speeds (judge signals tighten guardrails, human labels calibrate the judge, human insight updates policy, downstream outcomes validate decisions) create a self-improving system. Without them, every layer degrades independently.	How does this all fit together as architecture?
14	Architecture Overview	Guardrails prevent. Judge detects. Humans decide. Circuit breakers contain. Single-agent and multi-agent variants with PACE resilience for graceful degradation.	Does it actually work in practice?
15	What Works	Organisations using runtime controls detect breaches 108 days faster. Guardrails block millions of attacks daily. Judges catch hallucination in production. The evidence is clear, but adoption is low.	You are now ready to implement. Start with the Quick Start or Implementation Checklist.

Reading time

The full path is roughly two hours. Act I (articles 1 through 4) sets the foundation in about 25 minutes. Act II (articles 5 through 12) covers the control layers in about 55 minutes. You can stop after article 13 and have the complete picture of how the system works and self-corrects.

By goal¶

"I need to review and verify what the AI produced"¶

Reviewing AI output is not a single tool, and reaching for an LLM Judge by default is the most common mistake. The Judge is the right tool for some checks and the wrong one for others. This path starts with the verification spectrum, so you can match the method to the kind of claim you are checking, then covers what the Judge is for, how to validate it, where it breaks, and why a human stays in the loop.

The Verification Gap: the spectrum of verification methods, from fully dependent (Model-as-Judge) to fully independent (formal verification, knowledge-graph lookup), and how to match each to your claims.
The Judge Detects. It Doesn't Decide.: what the Judge is actually good at, namely detecting unknown-bad behaviour against declared intent, without blocking.
Process-Aware Evaluation: review the full trace, not just the final output. Correct answers from compromised processes are still failures.
Judge Assurance: validate the Judge against human ground truth before you trust it, and keep calibrating.
When the Judge Can Be Fooled: the Judge is an LLM, so it inherits LLM weaknesses. Know them before you rely on it.
Humans Remain Accountable: human review is part of the toolkit, not a fallback. The Judge makes oversight scalable, not optional.

Pick the tool for the claim

Use risk tiers to decide how much independent verification a deployment needs, and judge model selection when an LLM Judge genuinely is the right tool. For the wider catalogue of techniques, see the current solutions reference.

"I need to understand the threat landscape"¶

"I need to secure multi-agent systems"¶

"I need templates and practical artefacts"¶

"I want to see real-world examples"¶

Still not sure where to start?

The Quick Start guide gives you a condensed overview you can read in a few minutes. The FAQ answers common questions about scope, applicability, and how the framework relates to existing standards.

References