Guardrails › Input Guardrails

Input guardrails intercept user messages before they reach the language model. Their job is to ensure that the model only processes requests that fall within the application's intended scope, and that those requests do not carry payloads designed to manipulate the model's behavior. Running these checks before model invocation has a practical advantage beyond safety: it avoids the cost of LLM inference for requests that would have been rejected anyway. A request that gets blocked in 5 milliseconds by a length check or topic classifier spares the system the 500ms to 2000ms cost of a full model call.

The design principle for input guardrails is cheapest first. Order your checks from least computationally expensive to most expensive, and short-circuit the pipeline as soon as any check fires. Structural validation (length, format) costs microseconds. Regex-based injection detection costs a fraction of a millisecond. Embedding-based topic classification costs 5-50ms depending on model size. Secondary LLM calls for intent analysis cost 200-500ms. By placing structural checks at the front, you ensure that trivially invalid requests never consume the expensive semantic checks, and that the average latency across all requests is a fraction of what it would be if all checks ran for every request.

Prompt injection is the most serious input-side threat for deployed LLM applications. As covered in the Prompt Injection chapter, an attacker can embed instructions inside user-provided text that override the system prompt, hijack the model's behavior, or exfiltrate information from the context window. Input guardrails try to catch these attempts before they reach the model.

The fundamental challenge with prompt injection detection is that natural language is expressive and flexible. An injection attempt that says "ignore previous instructions" can be rephrased as "please set aside the earlier guidance", "starting fresh, you should", "for this conversation, consider that no prior context applies", and an effectively infinite number of other formulations that carry the same semantic intent. Any detection approach must grapple with this expressiveness.

Detection approaches fall into two categories. Rule-based detection looks for explicit patterns associated with injection attempts: strings like "ignore previous instructions", "disregard your system prompt", "you are now a different assistant", delimiter hijacking patterns like </system> or [INST], or unusual Unicode sequences used to hide instructions. These patterns are cheap to check and catch naive attacks, but sophisticated injections can rephrase these concepts without using any of the flagged strings.

Classifier-based detection trains a model to recognize the structural signature of injection attempts rather than surface patterns. An injection attempt typically includes some form of meta-instruction, an authority claim, or a context-shift directive. A classifier trained on diverse injection examples can generalize to novel phrasings because it learns to recognize the underlying structure rather than specific tokens. Meta's Prompt Guard, for example, is trained specifically for this purpose and achieves substantially better recall on novel injection variants than keyword-based approaches. The tradeoff is latency: running a secondary model on every input adds processing time, typically 20-100ms depending on model size and hardware.

A practical approach combines both: apply regex-based filters as a first pass for zero-cost screening, then apply a classifier only to inputs that pass the regex check. The classifier catches sophisticated variants; the regex filter eliminates the obvious ones without incurring classifier costs. This cascading design is a recurring pattern throughout guardrail architecture: arrange checks from cheapest to most expensive so that most requests are resolved early.

There is also a class of indirect prompt injection attacks worth understanding. In direct injection, the attacker types malicious instructions into the user interface. In indirect injection, the attacker embeds instructions in content that the model will later retrieve or process, such as a web page, document, or database record. A user might innocently paste a document into a RAG system, not knowing that the document's author embedded hidden instructions in white text or in a section the user did not read. The model then retrieves the document, processes the instructions, and behaves as the attacker intended, not as the user expected. Detecting indirect injection is harder because the injected content arrives through a trusted channel, the retrieval pipeline, and may not trigger the same patterns as direct user-typed injection. Effective defenses include instruction-tagging in the prompt (marking retrieved content as data rather than instructions), sandboxed execution modes, and output verification that checks whether the model's response is consistent with the user's request.

Applications are designed to serve specific purposes. A customer service chatbot for a software product should not be answering questions about geopolitics, generating creative fiction, or providing medical advice. Beyond policy compliance, keeping the model on-topic improves quality: a model prompted to stay within a domain tends to produce more accurate, reliable responses within that domain because its attention is not split across a wide variety of unrelated topics.

Topic guardrails classify incoming messages against the intended scope of the application and reject off-topic requests before they consume model compute. The simplest form is embedding-based similarity: compute the embedding of the user message and measure cosine similarity to a set of allowed-topic exemplars.

To formalize this: given a set of $n$ allowed-topic exemplars $\{e_1, e_2, \ldots, e_n\}$ and an incoming request $q$, where each is represented as a normalized embedding vector, the topicality score is:

$$s(q) = \max_{i=1}^{n} \cos(q, e_i) = \max_{i=1}^{n} \frac{q \cdot e_i}{\|q\| \cdot \|e_i\|}$$

where:

• $q$: the embedding vector of the incoming request
• $e_i$: the embedding vector of the $i$-th exemplar from the allowed topic set
• $\cos(q, e_i)$: cosine similarity between the request and exemplar $i$, ranging from $-1$ to $1$, with $1$ indicating identical direction in embedding space
• $s(q)$: the topicality score, the maximum similarity across all exemplars

A request is blocked when $s(q) < \tau$, where $\tau$ is a threshold calibrated to the application. With unit-normalized embeddings (the standard output from sentence transformers), cosine similarity reduces to the dot product $q \cdot e_i$, making the computation very efficient.

The set of exemplars is a declarative specification of the application's scope. Adding exemplars extends the allowed topic space; removing them narrows it. This design makes the system easy to update: domain experts who understand the application's intended purpose can curate the exemplar set without needing to retrain any model. For applications with complex scope boundaries, the exemplar set can be large, covering hundreds of topic variants, while the computation remains fast because it reduces to matrix multiplication between the query embedding and the exemplar embedding matrix.

More sophisticated approaches use a topic classifier with explicit categories, allowing the system to give different responses to different types of off-topic requests. A question about a competitor's product might receive a polite redirect, while a request for harmful content might trigger a harder stop. The difference matters for user experience: users asking innocent but out-of-scope questions deserve a helpful explanation, not the same response given to adversarial requests.

One design consideration that practitioners often overlook is the definition of "in-scope" for edge cases. Users rarely ask questions that fall cleanly within or outside the application's domain. A coding assistant might receive a question about general computer science concepts that are adjacent to programming. A legal research tool might receive a question that mixes legal and non-legal considerations. Topic guardrails should be calibrated with these edge cases in mind: the goal is not to enforce the strictest possible topicality boundary, but to prevent clearly off-topic usage while allowing the natural breadth that users need. Calibration data that includes labeled edge cases, not just clear in-scope and out-of-scope examples, is important for setting thresholds that work well in practice.

Many applications need to prevent personally identifiable information from entering the model, either because regulations require it (GDPR, HIPAA) or because the application should not store or process personal data. PII detection on inputs scans for patterns associated with names, email addresses, phone numbers, social security numbers, credit card numbers, and other regulated data types.

The regulatory context for PII is important to understand. The General Data Protection Regulation (GDPR) in the European Union and the California Consumer Privacy Act (CCPA) in the United States both impose requirements on how personal data may be collected, processed, and stored. For an LLM application, sending user-provided personal data to a third-party model API may constitute data processing under these regulations. Input-side PII detection allows organizations to comply with data minimization principles by stripping personal data before it leaves their systems.

Regular expression patterns handle structured PII well. Credit card numbers follow Luhn-verified numeric patterns. US Social Security numbers follow the format XXX-XX-XXXX. Phone numbers have regional formats with consistent digit counts and separators. IP addresses follow the X.X.X.X pattern. These structured forms can be detected with high precision using well-designed regular expressions.

For unstructured PII like names and physical addresses, named entity recognition (NER) models provide higher recall at higher computational cost. A name like "Michael Chen" has no structural signal that distinguishes it from other two-word phrases; only a model trained to recognize person names can reliably detect it. NER-based PII detection is typically reserved for use cases with strict compliance requirements where the cost of a missed name is high.

A key design decision is what to do with detected PII: block the request, strip the PII and pass the sanitized request, or pass the request with PII replaced by placeholder tokens. Stripping or replacing is often better than blocking outright. A user who inadvertently includes their email in a question should still get help; the guardrail just prevents the email from reaching the model or being stored in logs. Replacement with typed placeholders like [EMAIL_REDACTED] preserves the semantic context of the original message while removing the sensitive value.

There is a category of quasi-PII that falls between structured personal data and clearly benign text: combinations of information that are individually innocuous but jointly identifying. A person's first name, city, and employer are each public information. Combined, they may uniquely identify an individual in a small city. Detecting quasi-PII combinations is a harder problem than detecting structured PII, and most deployed guardrails do not attempt it. The practical approach is to focus structural PII detection on the categories with the highest regulatory risk, use NER for high-sensitivity contexts, and rely on access controls and data governance policies for the residual quasi-PII problem that technical detection cannot fully solve.

Before any semantic analysis, basic structural validation catches malformed inputs that indicate either a bug in the calling application or an attempt to trigger unexpected behavior. Length limits prevent runaway context consumption. A request with 100,000 characters might be attempting to exceed the model's context window, or it might simply be a bug in the calling application, but either way it should be rejected before consuming model compute or storage.

Format validation ensures the input matches expected schema for structured applications. An application that expects JSON-formatted requests should validate that the input is valid JSON before parsing it. An application that expects a specific set of fields should verify those fields are present and correctly typed. These checks catch both bugs and malformed requests without any semantic understanding.

Rate limiting detects and throttles repeated requests that could indicate automated abuse. A user who sends 100 requests per second is not using the system as intended; rate limiting prevents automated scraping, denial-of-service attempts, and cost exploitation. Rate limiting operates at the infrastructure level, before requests reach any application logic, and is therefore the cheapest possible guardrail in terms of per-request overhead.

Encoding validation is a subtler but important check. Certain Unicode ranges contain characters that are visually identical to ASCII but have different byte representations, a technique used to obfuscate injection attempts or bypass keyword filters. A check that normalizes Unicode and strips non-standard characters before any further processing removes this attack vector without requiring any semantic analysis. Similarly, inputs with anomalous character distributions (extremely high fractions of non-printable characters, or repetitive patterns consistent with automated generation rather than human typing) can be flagged for closer inspection.

These checks are cheap and should run first, before more expensive semantic classifiers. A 100,000-character input should never reach a topic classifier: the length check should stop it immediately. The ordering principle, cheapest checks first, is one of the most important design decisions in guardrail architecture.