Guardrails are rules that stop an agent before it does something it should not. Most articles describe them in the abstract. This page gives 24 concrete examples.
Each example names the rule, what it stops and where to enforce it. The web layer uses page types from an AI agent allow list.
Many so-called guardrails are really instructions. A real guardrail passes all four of these tests.
If a proposed guardrail fails any of them, treat it as guidance for the agent, not as a control.
The agent cannot talk its way past it.
Stopping, not reporting after the fact.
Deterministic, whatever the prompt says.
Every block names the rule that fired.
Rules are written in a simple pseudo-format. Adapt the syntax to whichever gateway, proxy or policy engine you already run.
Start with the web layer. It stops the actions that land outside your company, where mistakes are hardest to undo.
If you can only do eight this month, do these. Together they cover the most common and most expensive failures.
Four of the eight run at the egress point and need no changes to the agents themselves.
All action pages denied. One policy, same day.
High-risk hosts denied, including numeric IP forms.
Own identity per agent.
No production write access for coding agents.
No secrets in prompts.
Alerts on denial spikes.
Guardrails are only as strong as the place they run. Five enforcement points cover all 24 examples.
Put the same rule in two places when you can. If an agent bypasses one enforcement point, the other still decides.
Examples 1 to 6. Sees every web request from every agent.
Examples 7 to 9. Sees every tool call.
Examples 11 to 14. Decides what credentials exist.
Examples 16 and 23. Sees prompts and outputs.
Examples 10, 17 to 21. Limits the agent's own process.
Examples 1 to 6 combined into one per-agent file that the free Agent Egress Guard enforces.
The same file works for every agent with a similar purpose. Change the read types, and it fits another role.
Build your own in the policy builder, or start from the six example files.
These appear in many agent designs. Each fails at least one of the four tests.
Keep them if they help the agent behave, but do not count them as controls in a risk review.
A prompt instruction. Fails test 1.
After the fact. Fails test 2.
Useful, but not deterministic. Fails test 3.
Stops research too, so it gets switched off.
Misses real login pages on subdomains and locales.
No reason logged. Fails test 4.
All agents need the web layer. The rest depends on what the agent touches.
Use the table to pick a short list per agent, then add rules as the agent gains tools.
| Agent type | Most important examples |
|---|---|
| Research or browsing agent | 1 to 6, 20 |
| Coding agent | 5, 13, 17, 18, 19 |
| Support agent | 3, 15, 16, 22, 23 |
| Procurement agent | 2 (with one exception), 8, 22 |
| Operations agent | 8, 12, 13, 18, 21 |
| Vendor agent in SaaS | 11, 14, 15 via tenant settings |
A guardrail nobody has tested is an assumption. Keep one test per example.
Store the tests next to the policy files, so a change to one prompts a check of the other.
Run the tests after every change to a policy, a tool or a model, and on a schedule.
Request a known signup, checkout and upload URL. Expect three denials with the right page type.
Call an unapproved tool and a delete tool. Expect a refusal and an approval request.
Try a credential after its lifetime. Expect rejection.
Send a destructive statement through the database proxy. Expect denial.
Trigger five denials quickly. Expect a pause and an alert.
Order by speed and impact. Each month builds on the work of the last.
By the end of the quarter, every agent should sit behind all six layers, with a test for each rule.
Examples 1 to 6 and 20. Most outside harm stopped.
Examples 7 to 14. Access narrowed.
Examples 15 to 24. Remaining gaps closed.
Guardrails can feel like friction. These answers usually help.
Share the day-in-the-life example above with builders. It shows how rarely guardrails get in the way.
Read pages stay open. Most agents never notice the web layer at all.
You do not need to. Deny the few risky actions and let the rest through.
Models can be persuaded. Rules cannot.
The starter set takes about a week, and four of the eight need no agent changes.
Track these per agent every month, and share them with each agent owner.
A rule that blocks legitimate work too often needs an exception or a narrower scope, not removal.
Rules that never fire may be unnecessary, or untested.
Denials that stopped legitimate work.
One test per example, all green.
Agents behind all six layers.
Short definitions for readers who are new to agent guardrails and enforcement.
Use the same words in policies, tickets and logs so everyone means the same thing.
A rule, outside the model, that stops an action before it happens.
The system where a guardrail runs.
What a URL is on its site, such as pricing or checkout.
A host agents may never reach, such as a metadata endpoint.
How far an agent may act alone.
Giving the same answer every time.
A composite research agent's day, showing which of the 24 examples actually trigger.
The numbers are illustrative. The pattern, long quiet stretches with a few important denials, is typical.
Pricing pages, documentation and blogs. Every request is a read page on the allow list.
A "sign up for the full report" link. Denied as signup, owner notified.
A link to an unknown file host. Denied as unclassified.
The agent tries to leave a comment asking for data. Denied as comment.
Three denials, zero outside actions, one report delivered.
Most guardrails fire rarely. When they do, they stop exactly the actions nobody wanted.
Guardrails spread across systems owned by different teams. Name an owner for each layer.
The agent owner stays responsible for asking for the right guardrails. Layer owners are responsible for running them.
| Layer | Owner | Review |
|---|---|---|
| 1 Web access | Network security | Quarterly, and on new agents |
| 2 Tools | AI platform team | On each new tool |
| 3 Identity | Identity team | Monthly |
| 4 Data | Data protection and database teams | Quarterly |
| 5 Runtime | Platform engineering | Monthly |
| 6 Output | Application owners | Quarterly |
You cannot add code to a vendor's agent. You can still apply several layers.
Record which layers apply to each vendor agent in its registry entry, so gaps are visible.
Browser-based vendor agents pass your egress proxy.
Limit and expire the OAuth grants you give them.
Restrict which data the vendor agent may read.
Ask the vendor which guardrails they run, and for logs.
These need no code in the agent and no new vendor.
Together they cover four of the eight starter examples in a single afternoon.
Examples 1, 4, 5 and default-deny writes, free.
Example 17, with the secret scanner you already have.
Example 20, on logs you already collect.
Example 13, in an afternoon.
The honest fine print — the same two assumptions we publish, plus two operational ones
Free Agent Egress Guard plus page types for 40M+ domains.
