When the port-operations copilot's guardrail blocks a response because the query falls outside its authorized scope (for example, a question asking for a colleague's personnel file), what should the user actually see?

A well-designed guardrail includes a graceful fallback response: a clear, user-facing message stating the request is outside the assistant's scope, phrased in plain language, while deliberately not exposing the internal detection logic, thresholds, or exact triggering criteria -- revealing those details would help someone probe and circumvent the guardrail on a future attempt, while a plain refusal serves the legitimate user just fine. A generic HTTP error with zero explanation leaves the user confused about whether something is broken versus intentionally restricted, which is a poor experience for a legitimate planner who just asked something out of scope by mistake. Surfacing the raw blocked response and an internal error code in the chat window both confuses the end user and leaks implementation detail about the guardrail to anyone using the assistant, which is the opposite of the desired opacity. Silently timing out with no response at all is indistinguishable from a system failure and gives the user no actionable information, which is worse for trust than an honest, bounded refusal. Exam framing: implementing guardrails on output includes designing the refusal behavior itself, not just the detection step -- a refusal is part of the application's user experience and its security posture simultaneously.