What are runtime guardrails and excessive agency?

Beyond permissions, runtime guardrails inspect what actually flows through an agent while it runs, rather than only constraining what it is allowed to hold. NeMo Guardrails, one of the more widely used frameworks for this, names five distinct rails, each checking a different point in the loop.^[3]

• Input rails inspect what the user (or anything acting as the user) sends before the model ever processes it — reject or rewrite it here and nothing downstream is exposed to it.^[3]
• Dialog rails shape whether the model should even attempt to respond or take an action, given the conversation so far — a way to keep the exchange on-topic and inside policy.^[3]
• Retrieval rails check chunks pulled in from a RAG source before they reach the prompt, since retrieved content is untrusted the same way user input is.^[3]
• Execution rails check what goes into and comes out of a tool call specifically — the rail that matters most once an agent can act, not just answer, and the one most guides gloss over in favor of the more visible input/output pair.^[3]
• Output rails check what the model is about to say or return before it reaches the user, catching what earlier rails missed.^[3]

The risk these defend against has a name. OWASP’s Top 10 for Agentic Applications catalogs failure modes including identity and privilege abuse and outright rogue-agent behavior, the dangers that appear specifically when an agent has too much autonomy and too little oversight.^[1] Choosing a tool is its own decision; one comparison advises starting with LLM Guard if you are building a production app with real users and need broad coverage out of the box: prebuilt scanners you turn on, rather than the custom rail logic a more configurable framework expects you to author yourself.^[2]