Layered Guardrails

Overview

Module 1 introduced guardrails as structure rather than configuration. The previous three topics produced a threat model and two attack classes. This topic assembles the controls into layers and asks the question that keeps a security design honest: what does each layer catch that the one before it did not?

Five layers, and where each sits

graph TD
  A["<b>1 · Input screening</b><br/>pattern detection<br/><i>probabilistic, weakest</i>"] --> B["<b>2 · Retrieval provenance</b><br/>trust labels, tenant scope<br/><i>deterministic</i>"]
  B --> C["<b>3 · Pre-action authorisation</b><br/>limits, allowlists, confirmation<br/><i>deterministic, strongest</i>"]
  C --> D["<b>4 · Output checks</b><br/>disclosure, tool arguments<br/><i>mixed</i>"]
  D --> E["<b>5 · Audit</b><br/>the record, after the fact<br/><i>deterministic</i>"]

  classDef weak fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef strong fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef mixed fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  class A weak
  class B,C,E strong
  class D mixed

Five layers in request order. Colour is reliability rather than importance — the olive layers are the ones that do not depend on a probabilistic component behaving well.

Input screening catches known patterns. Cheap to add, weakest of the five, and the one most teams build first because it feels like security.

Retrieval provenance catches content arriving at the wrong trust level, and cross-tenant access. Deterministic: a tenancy assertion either holds or does not.

Pre-action authorisation is Module 5’s action boundary. Deterministic, and the layer that bounds the consequence of everything the earlier layers missed.

Output checks catch disclosure and unexpected tool arguments. Mixed: a regular-expression check for a payment reference is deterministic, while “does this response reveal something it should not” is a judgement, often made by another model.

Audit catches nothing in real time and is how you find out afterwards. Module 5 specified it; its inclusion here is to make the point that a control which only explains an incident is still a control.

The asymmetry worth internalising

The reliable layers are the deterministic ones.

A model-based guardrail is a probabilistic component protecting a probabilistic component. It has a false-positive rate, a false-negative rate, and no guarantee at all. A limit check in the action layer is arithmetic: the amount is above the ceiling or it is not.

So the design rule is: check deterministically wherever the thing being checked is deterministic. Is this amount above the limit? Is this tenant permitted? Does this device belong to this customer? Is this tool in the allowlist? None of those questions needs a model, and answering them with one is a strict downgrade.

Reserve model-based checks for genuinely semantic judgements — is this response disclosing something, is this content an instruction attempt — and treat their output as a signal with an error rate rather than a verdict.

What the layers cost

Module 1 named three costs; here they are with the detail that decides designs.

Latency. Every check sits in the request path. An input check plus an output check, each a model call, can add meaningfully to a response a user is watching stream — and Module 2’s time-to-first-token budget is the thing being spent. Note the specific conflict Module 2 identified: an output check that must see the whole response before releasing it is incompatible with streaming.

Money. A model-based check costs per call, on top of the call it protects. Two checks around one answer is three calls billed, and Section 1’s per-interaction ceiling has to absorb them. This is the cost line most unit-economics models omit entirely.

False positives. The adoption killer. A personal-data filter in a support tool will flag legitimate requests constantly, because support tickets are made of names and addresses. Module 1’s warning stands: guardrails tuned too aggressively do not fail loudly — they make the tool annoying enough to abandon, and then you have no guardrails and no adoption.

Measuring it

A guardrail with no measurement is an intention. Four numbers, from Module 2’s safety requirements:

Pass rate on an adversarial suite, run every release. Known injection patterns, extraction attempts, tier-escalation attempts.
Leakage counts on real traffic samples, because the suite only contains what you thought of.
Refusal appropriateness — the share of legitimate requests blocked. This needs an owner who wants it low, which is why Module 2 assigned it to the support lead rather than to compliance.
Attempted-and-rejected events, logged and reviewed. A rise is either an attack or a broken control, and both are worth knowing.

The honest caveat, repeated because it matters: passing an adversarial suite is evidence of resistance to known attacks. It is a floor that must not regress, not a safety case. Say that to a compliance reviewer rather than letting them infer something stronger.

The budget argument

One advantage specific to this pillar: the attack surface has a price. An agent that can issue credits, with a limit and a volume, gives you an expected-loss figure — and a security control whose cost can be compared against it.

That is an unusually comfortable position for a security conversation. It converts “we should be careful” into “this control costs this much and bounds that much exposure”, which is a conversation whoever holds the budget already knows how to have.

Five layers, with the deterministic ones named

Layer	What it catches here	Deterministic?	Owner
Input screening	Known injection phrasings in customer messages	No	Lena Fischer
Retrieval provenance	Ticket content treated as instruction; cross-tenant retrieval	Yes — trust label and tenant scope from the session	Lena Fischer
Pre-action authorisation	Credits above the limit; forbidden actions; unconfirmed consequential actions	Yes — limit as configuration, confirmation gate	Dev Raghunathan
Output checks	Personal data from historical tickets; tool arguments carrying customer data	Mixed	Lena Fischer
Audit	Everything, after the fact	Yes	Engineering

The false-positive problem, concretely. Tickets contain names, site addresses, phone numbers and occasional payment references. A personal-data output filter tuned to catch all of it will block a large share of perfectly ordinary support answers, because a correct answer often is “the visit to the Oak Street site is rescheduled for Friday”. Module 2 set the ceiling at ≤ 5% of legitimate requests blocked, with Grace Adeyemi owning it — and that ceiling is the thing that will be hardest to hold.

The cost line nobody budgeted. Two model-based checks around one answer means three billed calls per interaction, against a $1.54 p50 ceiling. The resolution is to make the cheap deterministic checks do as much as possible — pattern matching for payment references, tenancy assertions, limit arithmetic — and reserve a model-based check for the one genuinely semantic question: is this response disclosing something it should not.

The expected-loss argument for Dev. Credits have a limit and a monthly volume, which bounds the exposure from a fully successful attack on that path. The confirmation gate costs deflection — every credit is assisted rather than deflected — and that cost is now comparable against a number rather than against a feeling.

Feeds the workbook

The rubric requires every agent action checked against least privilege, which is layer three. Build the table with the deterministic column — it is the fastest way to find a control that currently depends on a model behaving well.

→ Four topics of security. The last one in this section has a named person who can stop the project. — Privacy by design