A public-facing LLM application should not send every user query straight to the model. Input sanitization screens and, where appropriate, changes a query before the LLM call. It is the first layer of a broader safety design, alongside controls during processing and validation of the generated response. section 2.1.7 section 13.3.1
An input guard can apply different policies to different findings:
- Detect specified personally identifiable information (PII), such as email addresses, credit-card numbers, and Social Security numbers, and replace it before processing. section 13.3.1
- Check business-specific restrictions, such as competitor mentions, and reject input that fails the check. section 13.3.1
- Validate that a query falls within acceptable bounds before it reaches the LLM. section 13.3.1
Listing 13.13 Validating input by using Guardrails AI for safety
from guardrails import Guard
from guardrails.hub import CompetitorCheck, GuardrailsPII
from guardrails.types.on_fail import OnFailAction
DATAKRYPT_COMPETITORS = [
"AWS KMS", "Azure Key Vault", "Google Cloud KMS",
"HashiCorp Vault", "CyberArk", "Thales", "Venafi"
]
input_guard = Guard().use_many( #1
CompetitorCheck(
DATAKRYPT_COMPETITORS,
on_fail=OnFailAction.EXCEPTION #2
),
GuardrailsPII(
entities=["EMAIL_ADDRESS", "CREDIT_CARD", "SSN"],
on_fail=OnFailAction.FIX #3
),
)
def validate_user_input(user_input: str) -> str:
"""Validate and sanitize user input before processing"""
try:
result = input_guard.validate(user_input)#4
return result.validated_output #5
except Exception as e:
logger.warning(f"Input validation failed: {e}")
raise ValueError( #6
"Input contains prohibited content") #6
The Guardrails AI listing composes a competitor check and a PII validator with `Guard().use_many(...)`. Its `on_fail` settings distinguish rejection (`EXCEPTION`) from repair (`FIX`); `validate_user_input` returns the validated output rather than the original input. section 13.3.1
Run validation before the LLM call, not after tokens have already been spent. Early screening addresses both security and cost, but it is not a complete defense: an input that passes a filter can still lead to an unsafe response. Keep output validation and monitoring in place, and test the pipeline for prompt injection and other adversarial inputs. section 12.5 section 13.3.1 section 13.5
