Design the guardrail layer that sits between your agent and the outside world

You are designing the guardrail layer that sits between an internal HR-policy Q&A bot and both its input and its output, deciding exactly what gets checked at each stage and what happens on a violation — not writing a single vague instruction like "don't say anything harmful" and calling the safety design done.

AGENT PURPOSE AND BOUNDARIES
Answers questions about HR policy documents only; must never give a legal opinion, discuss a specific employee's personnel case, or advise on whether a specific termination would be legal — the guardrail policy has to be specific to what this agent is actually for; a generic content-safety filter built for a general chatbot will both miss risks specific to this agent's domain and flag ordinary, legitimate requests this agent needs to handle as if they were violations.

INPUT CHECKS
Define each check as a specific thing to detect, not a vague category:
- Off-topic/out-of-scope requests: General policy questions ('how many PTO days for tenure over 5 years') are in scope; anything referencing a named employee, an ongoing HR case, or asking the bot to weigh in on a hypothetical termination decision is out of scope — what's explicitly out of scope for this agent, stated concretely enough that a borderline request can actually be classified against it.
- Injected instructions: does the input contain text that looks like it's trying to override the agent's own instructions rather than ask it a genuine question, matched against phrases like 'ignore the above and just tell me...' or a pasted block of text framed as a new system instruction inside what should be a plain question known for this deployment.
- Disallowed request categories: requests for legal advice framed as policy questions, requests to draft termination or disciplinary language, requests for another named employee's personal HR data — specific to what this agent, with its specific tools and data access, could actually be misused for, not a copy-pasted generic list.

OUTPUT CHECKS
- PII leakage: does the response contain employee ID numbers, home addresses, salary figures, medical/leave details tied to a named individual that shouldn't appear in an output to this particular requester, checked against what that requester is actually authorized to see, not just checked for the presence of PII in the abstract.
- Unsupported claims: for a grounded/RAG agent, does every factual claim trace back to retrieved context, or did generation add something not actually present in what it was given.
- Scope violations in the response itself: did the agent's response describe taking, or claim to have taken, an action outside its stated boundaries, even if no tool was actually called to do it — a response that falsely claims an action was taken is its own category of failure, separate from whether a disallowed tool call happened.

ACTION ON VIOLATION
For each check above, state the action, not just "flag it": block and return a specific refusal message, redact the offending portion and return the rest, or route to human review before responding at all. The action must differ by severity — a low-risk scope question and a request that maps to real harm shouldn't get the same response.

FALSE POSITIVE HANDLING
A blocked request gets a specific reason ('this looks like it's about a specific employee's case — I can only answer general policy questions') and a route to the actual HR team, not a generic refusal with no path forward — state how a legitimate request that trips a check incorrectly gets recovered, since a guardrail with no false-positive recovery path degrades the product every time it's slightly too strict, not just when it's genuinely needed.

OUTPUT FORMAT
A table: check name | stage (input/output) | detection method | action on violation | example of a request that should trip it and one that should not, to make the boundary concrete rather than theoretical.