LLM Guardrails Pipeline

01What exactly does this wrap — one chatbot, or every LLM call in the company?

One shared pipeline wraps every prompt and every response: applications declare a policy, and the same rails run for chat, RAG (answers grounded in retrieved documents), and agents — safety logic exists once, not re-invented per team — and the rails include topical bounds (keeping the conversation inside declared subject areas), not only harm screening.

02What happens to a prompt before the model ever sees it?

Input rails classify the prompt for injection and jailbreak attempts and detect PII, masking it before the prompt ever leaves our boundary for a model provider.

03The user pastes a document — is that treated like their own words?

No: pasted and retrieved content is data, never instructions — a retrieval rail scans it for embedded commands, because indirect injection rides in on documents, not on what the user typed.

04What happens to the model’s answer before the user sees it?

Output rails redact PII, classify the text against policy, and check grounding against the sources — an answer that leaks a phone number or invents a claim is caught before display, not after.

05The model wants to call a tool — does it just run?

Never directly: every tool call passes a gate — allowlist, schema-validated arguments, and a risk tier where destructive actions require explicit confirmation or a human.

06What does a blocked user actually see?

A safe, specific message with a retry or appeal path — and the decision is logged with detector scores and the policy version that made it, so a wrong block can be explained and fixed.

01How much latency may safety add to each request?

A bounded slice of time-to-first-token: detectors run in parallel and cheap-first, so the input rails add tens of milliseconds — never a second of serial checks.

02The answer streams token by token — when do you check it?

Before display, always: tokens release through a small buffer window, because a token the user has already seen cannot be taken back — retraction after display is an incident, not a control.

03A detector times out mid-request — block or pass?

Decided per surface, in advance: tool execution fails closed (a missed check on a destructive action is unacceptable), plain chat may fail open with a loud alert — never an accident of whichever error path ran.

04How many legitimate users is the pipeline allowed to block?

A tracked budget, not a hope: false-positive rate is measured per rail and per surface, because 0.5% of ten million requests is fifty thousand blocked legitimate users a day.

05A policy change ships — how do you know safety improved?

Every decision is logged with scores and a policy version, and a red-team eval suite plus false-positive tracking gates each new version — coverage is measured, never assumed.