Project 08: Policy Router Orchestrator

Build a policy router that orchestrates multiple guardrails frameworks into a single pipeline.

Quick Reference

Attribute	Value
Difficulty	Level 5
Time Estimate	3-4 weeks
Main Programming Language	Python
Alternative Programming Languages	JavaScript, Go
Coolness Level	5
Business Potential	5
Prerequisites	Experience with at least one guardrails tool
Key Topics	orchestration, policy routing, risk scoring

1. Learning Objectives

By completing this project, you will:

Compose multiple guardrails checks
Normalize risk scores into a common scale
Implement policy routing logic
Measure latency and decision consistency

2. All Theory Needed (Per-Concept Breakdown)

Guardrails Control Plane Fundamentals

Fundamentals A guardrails control plane is the set of policies, detectors, validators, and decision rules that sit around an LLM agent to ensure it behaves safely and predictably. Unlike traditional input validation, guardrails must handle probabilistic outputs, ambiguous intent, and adversarial prompts. The control plane therefore spans the entire lifecycle of an interaction: input filtering, context validation (including RAG sources), output moderation, and tool-use permissioning. Frameworks such as Guardrails AI and NeMo Guardrails provide structured validation and dialogue control, while models like Prompt Guard or Llama Guard provide detection signals that must be interpreted by policy.  The core insight is that no single framework enforces safety end-to-end; you must compose multiple controls and define how they interact.

Deep Dive into the concept A control plane begins with policy: a formal definition of what is allowed and why. Governance frameworks like the NIST AI RMF and ISO/IEC 42001 provide the organizational structure for this policy layer, while OWASP LLM Top 10 provides a security taxonomy for risks.  Policies must be translated into guardrail rules that are actionable: detect prompt injection in untrusted data, validate output schemas before tools execute, and block unsafe categories. This translation is non-trivial because LLM outputs are probabilistic and context-sensitive. A policy such as “never leak secrets” must be expressed as a chain of checks: input scanning for malicious prompts, context segmentation for untrusted data, output moderation to catch leakage, and tool gating to prevent exfiltration. Each check introduces uncertainty and cost, which means policy must include thresholds, confidence levels, and escalation paths.

Detectors such as Prompt Guard, Lakera Guard, or Rebuff provide risk scores and categories for injection attempts.  These detectors are probabilistic and therefore require calibration. The control plane must normalize detector outputs into a shared risk scale, define what “block” vs “review” means, and log the decision context for later auditing. Output guardrails such as Llama Guard or OpenAI moderation detect unsafe content in generated responses.  These checks must be aligned to your own taxonomy; the model’s categories may not map exactly to your policy. This is why evaluation and red-teaming are crucial: without testing, you do not know if your thresholds or taxonomy mappings are effective.

Structured output validation adds determinism to a probabilistic system. Guardrails AI uses validators and schema checks to ensure outputs conform to an expected structure, enabling safer tool calls and data extraction.  NeMo Guardrails extends this by introducing Colang, a flow language that constrains dialogue paths and allows explicit safety steps, such as mandatory disclaimers or confirmation prompts.  These frameworks provide building blocks, but they do not decide how to integrate them into a business context. For example, a schema validator can ensure a tool call is syntactically correct, but only policy can decide if that tool call should be allowed at all. This is why tool permissioning and sandboxing are critical complement pieces that most guardrails frameworks do not provide natively.

Evaluation is the evidence layer. Tools like garak and OpenAI Evals allow you to run red-team tests and custom evaluation suites to measure whether guardrails are actually working.  Without these tests, guardrails may create a false sense of security. Monitoring and telemetry are the final layer: you must log guardrail decisions, measure false positives and negatives, and track drift over time. Guardrails AI supports observability integration via OpenTelemetry, which can feed monitoring dashboards for guardrail KPIs.  The control plane is therefore a loop: policies drive controls, controls generate evidence, and evidence updates policies. This loop is the only sustainable way to manage guardrails in production.

How this fit on projects

You will apply this control-plane model directly in §5.4 and §5.11 and validate it in §6.

Definitions & key terms

Control plane: The policy-driven layer that decides what an agent may do.
Detector: A model or rule that assigns risk categories or scores. 
Validator: A structured check that enforces schema or constraints. 
Tool gating: Permissions and constraints for tool execution.
Evaluation suite: A set of tests that measure guardrails effectiveness. 

Mental model diagram

Policy -> Detectors -> Validators -> Tool Gate -> Output
 ^ | | | |
 | v v v v
Evidence <- Logs <- Thresholds <- Decisions <- Monitoring

How it works (step-by-step)

Define policy risks and acceptable thresholds.
Select detectors and validators aligned to those risks.
Normalize detector outputs and enforce schema rules.
Apply tool permissions based on risk and context.
Log decisions and run evaluation suites continuously.

Minimal concrete example

Guardrail Decision Record
- input_source: retrieved_doc
- detector: prompt_injection
- score: 0.84
- policy_action: block
- tool_gate: deny
- audit_id: 2026-01-03-0001

Common misconceptions

“A single framework solves guardrails end-to-end.”
“Moderation is enough to prevent prompt injection.”
“Validation guarantees correctness without policy.”

Check-your-understanding questions

Why is a policy layer required in addition to detectors?
How do validators reduce tool misuse risk?
Why is evaluation necessary even if detectors exist?

Check-your-understanding answers

Detectors provide signals, but policy decides actions and thresholds.
Validators ensure structured, safe tool inputs before execution.
Detectors can fail or drift; evaluation reveals blind spots.

Real-world applications

Enterprise assistants with access to sensitive data
RAG systems ingesting third-party documents
Autonomous workflows with high-impact tools

Where you’ll apply it

See §5.4 and §6 in this file.
Also used in: P02-prompt-injection-firewall.md, P03-content-safety-gate.md, P08-policy-router-orchestrator.md.

References

NIST AI RMF 1.0. 
ISO/IEC 42001:2023 AI Management Systems. 
OWASP LLM Top 10 v1.1. 
Guardrails AI framework. 
NeMo Guardrails and Colang. 
Prompt Guard model card. 
Llama Guard documentation. 
garak LLM scanner. 
OpenAI Evals. 

Key insights Guardrails are a control plane, not a single model or API.

Summary A layered control plane combines policy, detection, validation, and evaluation into a continuous safety loop.

Homework/Exercises to practice the concept

Draft a policy map with three risks and a detector for each.
Define a monitoring dashboard with three guardrail KPIs.

Solutions to the homework/exercises

Example risks: injection, data leakage, tool misuse; KPIs: block rate, false positives, tool denial rate.

3. Project Specification

3.1 What You Will Build

A multi-guardrail orchestrator that runs input detection, output moderation, and tool gating.

3.2 Functional Requirements

Accept input, run detection, and route decisions
Apply output moderation and schema checks
Gate tool calls based on risk
Log all decisions

3.3 Non-Functional Requirements

Performance: End-to-end guardrail pipeline under 2 seconds
Reliability: Deterministic decisions for identical inputs
Usability: Clear policy audit logs

3.4 Example Usage / Output

$ guardrail-router run --policy enterprise
Decision: ALLOW
Checks: input=pass output=pass tool=approve

3.5 Data Formats / Schemas / Protocols

Decision record: {input_risk, output_risk, tool_risk, final_action}

3.6 Edge Cases

Conflicting detector signals
Latency spikes
Missing detector outputs

3.7 Real World Outcome

This section is the golden reference. You will compare your output against it.

3.7.1 How to Run (Copy/Paste)

Configure policy router
Run with sample prompts
Review logs

3.7.2 Golden Path Demo (Deterministic)

Run a fixed prompt set with expected decision outcomes.

3.7.3 If CLI: Exact Terminal Transcript (Success)

$ guardrail-router run --policy enterprise
Input Check: PASS
Output Check: PASS
Tool Gate: APPROVED
Final: ALLOW

3.7.4 Failure Demo (Deterministic)

$ guardrail-router run --policy enterprise
Input Check: FAIL
Final: BLOCK

Exit codes: 0 on allow/block, 5 on orchestration failure

4. Solution Architecture

The orchestrator is a policy-driven pipeline coordinating multiple detectors and validators.

4.1 High-Level Design

┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Input │────▶│ Policy │────▶│ Output │
│ Handler │ │ Engine │ │ Reporter │
└─────────────┘ └─────────────┘ └─────────────┘

4.2 Key Components

Component	Responsibility	Key Decisions
Input Layer	Runs injection detectors	Source-aware thresholds
Output Layer	Runs moderation	Category mapping
Tool Gate	Approves actions	Risk-based rules

4.4 Data Structures (No Full Code)

Policy decision record: checks, scores, action, latency

4.4 Algorithm Overview

Run input checks
Run output checks
Gate tool calls
Emit final action

5. Implementation Guide

5.1 Development Environment Setup

mkdir policy-router && cd policy-router

5.2 Project Structure

project/
├── router/
├── detectors/
├── validators/
└── logs/

5.3 The Core Question You’re Answering

“How do I compose multiple guardrails frameworks into a single policy-driven pipeline?”

Orchestration creates defense-in-depth across input, output, and tools.

5.4 Concepts You Must Understand First

Policy routing (NIST AI RMF Manage) 
Multi-guardrail consistency

5.5 Questions to Guide Your Design

Order of checks
- Which checks must run first?
- Which can run in parallel?
Conflict resolution
- What if detectors disagree?

5.6 Thinking Exercise

Pipeline Design

Draw a pipeline with three guardrail layers.

Questions to answer:

Where do you insert tool gating?
Which layer must be last?

5.7 The Interview Questions They’ll Ask

“Why is defense-in-depth important for LLMs?”
“How do you resolve conflicting detector results?”
“How do you balance latency vs safety?”
“What is policy routing?”
“How do you test orchestration logic?”

5.8 Hints in Layers

Hint 1: Normalize scores Convert to a shared scale.

Hint 2: Define precedence rules Block overrides allow.

Hint 3: Parallelize checks Reduce latency.

Hint 4: Log decisions Audit every step.

5.9 Books That Will Help

Topic	Book	Chapter
Risk management	NIST AI RMF 1.0	Manage function 

5.10 Implementation Phases

Phase 1: Router Core (1 week)

Goals: pipeline skeleton. Tasks: input/output/tool stages. Checkpoint: baseline flow works.

Phase 2: Score Normalization (1 week)

Goals: unified risk scale. Tasks: mapping rules. Checkpoint: consistent decisions.

Phase 3: Performance Tuning (1 week)

Goals: reduce latency. Tasks: parallel execution, caching. Checkpoint: latency targets met.

5.11 Key Implementation Decisions

Decision	Options	Recommendation	Rationale
Conflict resolution	majority vs max risk	max risk	safety first
Parallelization	none vs partial	partial	latency

6. Testing Strategy

6.1 Test Categories

Category	Purpose	Examples
Unit Tests	Validate core logic	Input classification, schema checks
Integration Tests	Validate end-to-end flow	Full guardrail pipeline
Edge Case Tests	Validate unusual inputs	Long prompts, empty outputs

6.2 Critical Test Cases

Conflicting signals: block wins
All pass: allow
Detector missing: fail safe

6.3 Test Data

Prompt set with known risk labels

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall	Symptom	Solution
Inconsistent thresholds	Unpredictable decisions	Normalize scores
Excess latency	Slow pipeline	Parallelize checks

7.2 Debugging Strategies

Inspect decision logs to see which rule triggered a block.
Replay deterministic test cases to reproduce failures.

7.3 Performance Traps

Avoid serial detector calls when independent.

8. Extensions & Challenges

8.1 Beginner Extensions

Add a new detector
Add metric dashboards

8.2 Intermediate Extensions

Integrate with evaluation harness
Add human review tier

8.3 Advanced Extensions

Policy-driven A/B testing
Distributed deployment

9. Real-World Connections

9.1 Industry Applications

Enterprise guardrails: Centralized safety enforcement
Agent platforms: Shared guardrails across apps

Guardrails AI: Validation framework 
NeMo Guardrails: Dialogue control 

9.3 Interview Relevance

Systems design: Pipeline orchestration
Risk management: Policy decisioning

10. Resources

10.1 Essential Reading

NIST AI RMF 1.0. 
OWASP LLM Top 10. 

10.2 Video Resources

LLM guardrails orchestration talks
Safety platform design talks

10.3 Tools & Documentation

NIST AI RMF docs. 
OWASP LLM Top 10 docs. 

Project 2: Prompt Injection Firewall
Project 9: Red-Team & Eval Harness

11. Self-Assessment Checklist

11.1 Understanding

I can explain the control plane layers without notes
I can justify every policy threshold used
I understand the main failure modes of this guardrail

11.2 Implementation

All functional requirements are met
All critical test cases pass
Edge cases are handled

11.3 Growth

I documented lessons learned
I can explain this project in an interview

12. Submission / Completion Criteria

Minimum Viable Completion:

Router pipeline built
Risk scores normalized
Decision logs captured

Full Completion:

All minimum criteria plus:
Latency target met
Conflict resolution documented

Excellence (Going Above & Beyond):

Multi-tenant policy routing
Dynamic policy updates