The model's own training is one line of defence, and users will find the gaps in it — deliberately with jailbreak attempts, or accidentally with inputs that steer it somewhere you did not intend. Guardrails are the layers you add around the model so that a bad input is caught before it reaches the model, or a bad output is caught before it reaches the user. Defence in depth is the whole idea.
Input guardrails
Check the request before you spend a token on it. Screen for disallowed content, obvious prompt-injection and jailbreak patterns ("ignore your instructions", embedded instructions in retrieved documents), and inputs that are simply out of scope for your product. Catching these early saves cost and stops a hostile prompt from ever reaching the model.
Output guardrails
Never assume the generation is safe just because the input was. Screen the output too:
- Moderation — run generated text through a moderation check for disallowed categories before display.
- PII leakage — scan for and redact any sensitive data the model may have surfaced or echoed.
- Format and scope — validate the output is on-topic and in the expected shape; a support bot should not be writing poetry.
- Grounding — for factual features, check claims against your retrieved sources rather than trusting free generation.
Prompt injection is the hard one
Prompt injection — malicious instructions hidden in user input or, worse, in retrieved/third-party content — is an unsolved problem you mitigate rather than eliminate. Keep the system prompt and untrusted content clearly separated, never let a tool-using agent take irreversible actions without a confirmation step, and treat any text the model did not originate as untrusted. Assume the model can be talked into ignoring instructions, and make sure that on its own it cannot do real damage.
When a guardrail blocks a request or the model declines, that is expected behaviour, not an exception to swallow. Return a clear, honest message, log it for review, and make sure legitimate users caught by a false positive have a path forward. Silent failures and cryptic errors turn a working guardrail into a support ticket.
Layer the defences — input screening, a constrained system prompt, output moderation, and PII redaction — because any single layer will miss something. And decide your policy deliberately: what is disallowed, what is redacted, and what a blocked user sees. Guardrails are a product decision expressed in engineering, not a library you switch on.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.