Input Guardrails in Practice

Imagine you have built a simple application. A person types a question, the question is passed to a model, and the model's answer appears on the screen. Nothing in the design looks broken. Yet the design 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. This article follows one request through a simple application, explains what a guardrail is and whose risks it covers, and shows how the two broad families of guardrails divide the work between them. Keep the simple two-point flow in mind, text comes in and text goes out, because the rest of the article builds on it.

The best way to see how guardrails fit into an application is to follow one request from start to finish. Read the trace below as a sequence of states. At each step, ask which exposure is currently active, meaning which point in the system could let something go wrong, and which guardrail, if any, is responsible for it.

Notice that the trace has two edges that matter most. The first is where text enters the application. The second is where text leaves it. Those two edges are where the two families of guardrails are placed, as the next sections explain.

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.

Because a guardrail is defined by what it prevents rather than what it adds, you can test any proposed guardrail with one question: which specific risk does this contain, and where in the flow does it contain it? If you cannot answer both parts, the proposal is still a wish, not a guardrail.

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.

Now trace the same request again, this time with the two families placed on it. The input guardrail handles the question on its way in, before it reaches the model. The output guardrail handles the reply on its way out, before it reaches the screen. Each guardrail covers a distinct stretch of the flow, so they never handle the same data at the same moment.

The table makes a point easy to miss when the two families are studied in isolation. They share a purpose and differ only in position. That is why a complete design usually considers both, and why the placement rule about exposures is what decides how many guardrails are needed.