AI agent guardrails: what they are, the main types, and where each one has to live
Guardrails is one word for very different controls: filters, prompt rules, containment, gateways, approvals, budgets. The main types, with examples, and which ones a manipulated agent cannot bypass.
Listen to this article · 5 min
AI-generated narration of the full article.
“Guardrails” has become the default answer to every question about AI agent risk, and the word now means almost anything. For one team it is a content filter on the model’s output. For another it is a paragraph in the system prompt telling the agent what not to do. For a third it is the permission screen of the agent platform. All three are guardrails. They do not protect against the same things, and only some of them survive an agent that has been manipulated.
This guide sorts the main types, with examples from products and cases we have analyzed, and ends with the one test that separates a real control from a hopeful instruction.
What an AI agent guardrail is
A guardrail is any control that limits what an AI agent can say or do, or how much it can do, regardless of what it was asked. The useful distinction is where the control runs:
- Inside the agent’s reasoning: instructions in the prompt, rules the model is asked to follow. The agent reads them, so the agent can be talked out of them.
- Around the model: filters that inspect inputs and outputs, such as blocked topics, sensitive data detection or checks that an answer is grounded in its sources.
- Outside the agent: controls the agent cannot see or change, enforced by the operating system, the runtime, a gateway, an identity system or a person.
Where agent guardrails live, from strongest to weakest against manipulation
Identity and permissions
- Who the agent acts as
- What its credentials reach
Enforced by systems of record
Runtime containment
- Files, network, processes the agent can touch
Enforced by the OS or runtime
Tool and model gateway
- Which tools and models, how often, at what cost
Enforced on every call
Model input and output filters
- Blocked topics, sensitive data, grounding checks
Prompt instructions
- Rules the agent is asked to follow
Read by the agent, so it can be argued away
The main types, with examples
1. Prompt and policy instructions. The system prompt says “never share customer data” or “only answer HR questions.” Cheap, useful for behavior and tone, and not a security control: a prompt injection in a document the agent reads can override it. We explained why in prompt guardrails are not a security boundary.
2. Model input and output filters. Products such as Amazon Bedrock Guardrails and NVIDIA’s open source NeMo Guardrails check prompts and responses for denied topics, harmful content or sensitive data, and can check whether an answer is supported by its sources. Good for content risk; blind to what the agent does with tools.
3. Runtime containment. The operating system or runtime limits which files, networks and processes the agent can reach. Examples: Microsoft’s Execution Containers in Windows and NVIDIA’s OpenShell, which ServiceNow uses to govern its Arc personal agent. This is the layer that limits damage when everything else fails.
4. Tool and model gateways. Every tool call or model request passes through a gateway that allows, blocks or logs it. Microsoft’s Agent 365 can block the MCP tools an agent calls at the gateway; AI gateways enforce which models a team can use and at what cost.
5. Sequence and context rules. Some actions are safe alone and dangerous in combination: reading a customer file and then emailing outside the company. AWS’s Strands Box makes authorization depend on what the agent just did.
6. Human approval. A person approves before the agent sends, pays, deletes or deploys. Strongest when it uses the approval process the company already audits, such as change management, and weakest when the approver cannot see what they are approving.
7. Budgets and rate limits. Spend and volume limits stop runaway loops and abuse. Databricks found that friction that ramps up works better than hard caps for people; for autonomous agents, hard limits remain a sensible backstop.
The test that matters
For each guardrail, ask one question: if a malicious document convinced the agent to do the forbidden thing, would this control still stop it? If the answer is no, it is a behavior guideline, valuable for quality and useless for security. Types 1 and 2 mostly fail that test. Types 3 to 7 mostly pass it, because they run outside the agent.
The second question is ownership. These controls answer different questions, run on different clocks and should be held by different teams; we laid that out as six independent authorities over an agent.
A minimum set for a production agent
- An identity of its own, with permissions scoped to its task.
- Containment that limits what it can touch, enforced outside the agent.
- A gateway that logs every tool and model call.
- Human approval for actions that are hard to reverse.
- A budget with an alert and a hard ceiling.
- Prompt instructions and output filters for behavior and content, on top of all that, not instead of it.
Guardrails are not one product or one layer. The agents that fail safely are the ones whose limits do not depend on the agent agreeing to them.