Guardrails can inspect a request, validate tool arguments, check a proposed action or screen a response. The mechanism matters. NVIDIA’s self-check rails ask an LLM to assess inputs or outputs. Those judgments can be wrong and need evaluation. A schema validator can check that a call has the required fields, but a correctly formatted call can still request an unauthorized action.
An authorization boundary makes a different decision: whether this identity may perform this action on this resource. OWASP recommends enforcing that policy in downstream systems and limiting the tools and permissions an agent receives. The boundary needs to cover every relevant action path and remain outside the agent’s ability to change it. Putting a check in application code does not establish that its rule, coverage or implementation is correct.
Example: a support assistant drafts an email. A model-based check might miss a confidential detail. Separately, a send operation can require approval for the exact recipient and message before execution. Rejecting the assistant’s final text after the email has been sent cannot undo that send. The Agents SDK guide illustrates why execution order matters: some input checks can run in parallel with an agent, and output checks happen after the work they inspect.
Our suggested review is to ask what each check decides, when it runs, which paths it covers and what happens on a failure or timeout. See the guardrails explainer for a comparison and three boundary questions.
Sources
- NVIDIA NeMo Guardrails: LLM self-check — Describes model-based input and output checks whose performance depends on the LLM.
- OWASP: LLM06:2025 Excessive Agency — Recommends limited tool capabilities and downstream authorization for every action.
- OpenAI Agents SDK: Guardrails — Distinguishes check placement and execution timing, including actions before parallel checks finish.
