What is Input Safety?
Also called Input Rails, Input Guardrails, Prompt Filtering.
Input safety refers to checks applied to a message or document before it reaches the model. Typical checks cover injection patterns, prohibited request categories, personal data that should not enter context, oversized or malformed payloads, and rate or quota limits. Blocking at this stage prevents cost, exposure, and the generation of unsafe content in the first place.
Input checks are the cheapest place to stop a problem. Rejecting a request before inference avoids the compute cost, avoids sending the content to any external provider, and avoids creating an unsafe output that then has to be caught downstream. For personal data in particular, filtering at the input boundary is the only way to keep it out of the provider's systems entirely.
The checks fall into rough groups. Structural validation covers length, encoding, file type, and schema. Policy classification covers prohibited categories. Sensitivity screening covers personal and confidential data. Adversarial screening looks for injection and bypass patterns. Abuse controls cover rate limits and quotas per account. Each group has a different tolerance for false positives.
Input safety alone is not sufficient, because a benign-looking request can still yield an unsafe response and because attackers optimize directly against whatever the input filter recognizes. Its counterpart at the output stage catches what slipped through. Systems that rely on one side only tend to fail in the direction of whichever side is missing.
Design details determine whether the layer helps or hurts. A check that blocks silently produces confused users and unreproducible bug reports, so a clear reason and a path to appeal matter. A check that adds significant latency to every request will be pressured out of the critical path. Running independent checks in parallel, with a short timeout and a defined behavior on timeout, keeps the cost bounded.
Key points
- Cheapest stage to block: no compute, no exposure, no unsafe output
- Only place to keep personal data out of an external provider
- Groups: structure, policy, sensitivity, adversarial, abuse
- Insufficient alone, since benign inputs yield unsafe outputs
- Silent blocking creates confused users and unreproducible reports
In practice
A document assistant runs four parallel input checks with a short shared timeout: file type and size validation, a personal data scan, an injection pattern classifier over the extracted text, and a per-account rate limit. A contract upload trips the personal data scan on signatory names. Rather than rejecting the file, the pipeline tokenizes those spans and proceeds, and the user sees a note that names were masked.