What Are AI Agent Guardrails?

AI agent guardrails are runtime controls that sit around an agent and decide what it may read, do, and say on every request. They run in three layers: input guardrails catch prompt injection, PII, and unsafe prompts before the model sees them; action guardrails enforce which tools and data the agent may use and hold irreversible operations for human approval; and output guardrails scan responses for leaked data and policy violations before they reach a user. The key thing to understand is that they live around the model, not inside it, so they still hold when the model is manipulated into ignoring its own instructions.

That last point is where guardrails differ from prompt engineering. A well-written system prompt is a request. A guardrail is enforcement. If you tell the model in its prompt to never call the delete tool, a clever injection can talk it out of that. If a guardrail blocks the delete tool at the action layer, the injection can convince the model all it wants and the call still does not go through. That gap between an over-provisioned agent and the damage it can do is what OWASP calls excessive agency.

The three types of AI agent guardrails

Guardrails split by what they govern: what the agent reads, what it does, and what it says. Miss any one layer and you have left a gap that either an attacker or an ordinary model mistake will eventually find.

Input guardrails

These inspect everything the model is about to read: the user's message, documents pulled from a knowledge base, the output of a tool the agent just called. All of it is untrusted, including text the agent fetched itself, because an instruction hidden in a web page or a retrieved file reads to the model like a command. That is the mechanism behind indirect prompt injection, and it is why the input layer cannot be skipped. Input guardrails catch prompt injection and strip or flag sensitive data before it ever reaches the model. This is the layer most people picture when they hear the word guardrail, and on its own it is not enough.

Action guardrails

This is the layer that general-purpose guardrail products most often skip, and it is the one that matters most for an autonomous agent. When an agent can call tools, the dangerous event is not a sentence, it is an action: a refund issued, an email sent with a customer list attached, a shell command run, a table dropped. Action guardrails enforce which tools and data each agent may use, block calls outside that policy, and hold irreversible operations for a human. No amount of input or output text scanning constrains an action; you need policy on the action itself.

Output guardrails

These check what the agent sends back to a user or forward to another system. They catch leaked secrets, personal data, and off-policy content before it leaves, and they validate output that will be rendered or executed downstream so it cannot carry an attack further. Output guardrails are the safety net for anything the earlier layers did not stop.

Why output filtering alone leaves you exposed

A lot of teams equate guardrails with output filtering: scan the answer, redact a phone number, block a toxic response. For a text-only assistant that answers questions from your internal knowledge, that may be most of the job, and a well-built assistant that searches company documents needs strong input and output guards to keep sensitive content from leaking through an answer. Tools like an enterprise search assistant that finds answers across your internal systems live and die on that content layer.

But the moment an agent can act, output filtering stops being sufficient. The refund fires during execution, not in the final response, so an output scanner never sees it in time to stop it. The current standard is defense in depth: input guards, action and tool gating, output guards, human approval on high-risk actions, and monitoring, each catching what the others miss. Input filtering cannot catch every unsafe model response, and output scanning cannot stop an agent from using the wrong tool mid-task.

Where guardrails should live

Put the controls in a control plane in front of the agent, not in the agent's own code or prompt. Two reasons. First, prompt-level rules bend under injection, and code-level checks scattered across each agent are inconsistent and easy to bypass. Second, a single enforcement layer applies the same policy to every agent and records every decision, which is what makes guardrails auditable rather than a matter of trust.

That is the model behind AI agent guardrails as a runtime layer, with the content side handled by the AI guardrails control surface and the action side by least-privilege tool permissions. Start with input and output guards, add action gating and human approval, and keep everything logged. Try Agentshield against a live injection in the console above to see the input layer work.