Guardrails, Monitoring & Detection
Input and output checks, plain-code limits, what to log and what to alert on.
Guardrails check inputs and outputs, but they are only one layer. Plain-code limits such as rate limits and allow lists are the most reliable. Log who, what, which tools and which decisions, without secrets. Watch for spikes and odd tool use, give alerts an owner and measure false alarms.
- Guardrail
- A check around the model that can block, change or flag.
- Allow list
- A list of the only things permitted.
- False alarm
- A good request that a guardrail blocked.
Prevention will not catch everything. You also need to see attacks as they happen, and to stop the worst of them automatically. This lesson covers guardrails, which filter and shape what goes in and out, and monitoring, which tells you when something odd is going on.
What a guardrail is
A guardrail is a check around the model. It can look at the input before the model sees it, or at the output before the user sees it. It can block, change or flag. Guardrails are useful, but they are one layer. They can be fooled, so never use them as the only protection.
Input guardrails
- Detect likely injection attempts, using rules or a classifier, and flag or block them.
- Remove or mask private data the model does not need.
- Limit length and rate, to stop abuse and runaway cost.
- Reject unsupported file types and oversized files.
- Check that the request fits the product's purpose.
Output guardrails
- Scan for secrets, personal data and banned content before showing the answer.
- Check that required parts are present, such as a citation or a disclaimer.
- Validate structure so other code can trust it.
- Remove or block links and images to unknown addresses.
- Hold risky answers for review.
Limits that need no AI
The most reliable guardrails are plain code. Rate limits. Spend budgets. Allow lists of tools and addresses. Permission checks. They do not argue, and they do not get tricked by clever wording. Build these first. Add AI-based filters on top.
What to log
LOG, WITH PRIVACY RULES APPLIED - Who (user id, customer id), when, from where - The request and the version of prompt and model used - Retrieved documents (ids, not full text) - Every tool call: name, arguments, result code - Guardrail decisions: what was blocked or flagged and why - Approvals: who approved what - Cost and time per run DO NOT LOG - Secrets, keys, full card numbers - Personal data you do not need; mask or hash it - More than you can protect and afford to keep
What to watch for
- Spikes in blocked or flagged requests from one user or address.
- Prompts that contain known attack phrases, or very long and strange input.
- Unusual tool use: new tools, large amounts, odd hours, many failures.
- Answers that contain secret-like strings or other customers' names.
- Sudden rises in cost or traffic.
- A model or prompt change followed by new kinds of failures.
Alerts and ownership
An alert nobody reads is noise. Decide which signals page a person at once, such as a leak of a secret or a customer-isolation failure. Decide which go to a daily review. Name an owner for each. Test the alert path with a drill.
Measure your guardrails
Track how often guardrails block good requests, which is a false alarm, and how often they miss attacks. Use your attack test set to measure. A guardrail that blocks too much hurts the product. One that misses too much gives false comfort.
- ✓Guardrails check inputs and outputs, and are one layer only. Plain-code limits are the most reliable ones.
- ✓Log who, what, which tools, which decisions and what it cost, with privacy rules applied and no secrets.
- ✓Watch for spikes, strange prompts, unusual tool use, secret-like strings and cost jumps.
- ✓Assign owners to alerts, drill the alert path, and measure false alarms and misses with your attack set.
Design the guardrails and the alerts
- Pick an AI assistant with two tools.
- List three input guardrails, three output guardrails and three plain-code limits.
- Write the fields you would log, and three things you would never log.
- Write three alerts with an owner and a first action for each.
Q1Why are plain-code limits more reliable than AI filters?show answer
Code limits such as rate limits and allow lists cannot be argued with or tricked by clever wording.
Q2Why should you not log secrets or unneeded personal data?show answer
Logs are widely readable and kept for long. Sensitive data in them becomes another leak path.
Q3How do you know a guardrail works well?show answer
Measure false alarms and misses using a set of known attacks and normal requests.