Implementing Guardrails

Imagine you have built an application in which a person types a question, the question is passed to a model, and the model's answer appears on the screen. The design looks finished. Yet it raises an uncomfortable question: what happens if the text coming in is harmful, misleading, or simply not something the application should handle? And what happens if the text going out is the problem?

Guardrails are the design answer to that question. Keep the simple two-point flow in mind, text comes in and text goes out, because the rest of this article builds on it. Each point in that flow is a place where something can go wrong, and each is a place where a guardrail can be placed.

The word mechanism matters. A guardrail is not a single rule written in a document. It is a component of the system that actively limits what can go wrong. Its job is defensive. It does not make the application more capable, faster, or more interesting. It exists so that when a risk is present, the consequences of that risk are contained before they reach a user or the operator running the system.

The phrase protect you and your users captures two audiences. The builder is exposed to risks such as an application behaving in ways that reflect poorly on the product or create legal or operational trouble. The users are exposed to risks such as receiving harmful content or having their own information handled carelessly. A well-placed guardrail considers both audiences, because a risk to one is usually a risk to the other.

The source gives a clear placement rule: guardrails should be put wherever there is an exposure to risk. This turns a vague worry into a concrete design task. Instead of asking whether the application feels safe, you walk through the system and ask at which points risk can enter, travel, or leave.

An exposure is a point in the system where something could go wrong and cause harm. Exposures are not all the same size. Some sit at the edges of the system, where data arrives from outside or leaves to the outside. Others sit inside the processing itself. The placement rule asks you to put a guardrail at each exposure you can identify, rather than relying on one check at the very beginning and hoping it covers everything.

Read the diagram as a list of places to check. The request enters at the edge, is passed inward toward the model, and the reply travels back through the application to the screen. Each arrow is a point where data moves, so each arrow is a candidate exposure. The design task is to decide which of those points need a guardrail, and the placement rule says to cover every one you can identify.

The best way to see how the two families of guardrails fit together is to follow one request from start to finish. Read the trace as a sequence of states. At each step, ask which exposure is currently active and which guardrail, if any, is responsible for it.

The source states that, in general, guardrails can be grouped into two categories: guardrails around inputs and guardrails around outputs. This grouping follows the direction of data through the system. Data either comes into the application or goes out of it, and the two families are named for the side of the flow they protect.

A guardrail on the input side does not have to do only one thing with a request. The flowchart below shows one illustrative set of outcomes for an incoming prompt. The branches are a generated teaching example of how an input check might respond. The source establishes the placement and the two families; the specific outcomes shown here are one way to read the design.

Notice that a blocked request never reaches the model, so the output side has nothing to check for that prompt. An allowed or modified request does reach the model, and its reply then passes through the output check. Both families remain relevant to the same interaction, each covering its own stretch of the flow.