Six ready-made rules files for common agent roles. Each one says which pages the agent may open, what happens to unknown sites, and which narrow exceptions it has.
Every example is checked with the free Agent Egress Guard and uses page types from an AI agent allow list.
A rules file is a promise about what an agent may do on the web. Copy the structure, then change the details to match your agent's real purpose.
Each example below shows the file on the left and the reasoning on the right. Download links give you the exact file, ready to validate.
Each allow list follows the agent's job. A support agent has no reason to open careers pages.
No example allows signup, checkout, upload or posting as a general page type.
The one purchase permission names a page type, a domain and an end date.
And a review date. Validation warns when either is missing.
Compares vendors, reads prices and product pages, writes a summary. Tier 3: it plans its own steps, a person approves anything risky.
Good fit for competitive analysis, analyst research and vendor comparisons.
market-research.jsonAnswers customer questions using vendors' help pages and status pages. Tier 2: it follows a fixed workflow.
Good fit for help desks that answer questions about third-party products.
support-answers.jsonResearches suppliers and places small orders with one approved supplier. Tier 3, with owner approval per order.
Pair it with a spend limit in your purchasing system, so a mistake has a ceiling.
procurement.jsonReads documentation while writing code in a sandbox. Tier 4: it acts on its own for long stretches.
Stricter teams switch unclassified to deny and list their approved documentation domains.
coding-assistant.jsonBuilds account briefs from company websites. Tier 3.
Good fit for account research, lead enrichment and meeting preparation.
sales-research.jsonWatches vendors' legal, security and status pages for changes. Tier 2.
Good fit for vendor risk teams that track terms and security page changes.
compliance-monitor.jsonKeep these next to each file and run them on every change. The expected verdicts assume the page-type database is connected.
| File | Request | Expected |
|---|---|---|
| market-research | GET a vendor's verified pricing page | allow |
| market-research | GET the same vendor's free-trial signup | approval_required |
| support-answers | GET a vendor's status page | allow |
| support-answers | GET a vendor's careers page | deny |
| procurement | GET checkout on approved-supplier.example | approval_required |
| procurement | GET checkout on any other shop | approval_required, then refused |
| coding-assistant | GET an unknown documentation site | allow |
| coding-assistant | POST to a package upload URL | deny |
| sales-research | POST to a contact form | approval_required |
| compliance-monitor | GET a cloud metadata address | deny |
The procurement row shows why owner approval matters: the request reaches a person, who says no, and the refusal is logged.
Add at least one test per page type the agent is allowed, and one per action type it could plausibly meet.
The examples are a neutral starting point. Regulated sectors usually tighten them in these ways.
Move every agent to unclassified: deny, including coding assistants.
Add deny_domains for data brokers and file-sharing sites.
Keep uploads denied everywhere, with no exceptions.
Shorten review dates to 60 days for agents that touch patient data.
Use tier 2 wherever possible, with block rather than ask.
License the page-type data on-premise so no lookup leaves the network.
Allow legal and security pages widely, deny comment and post everywhere.
Record every visit for matter files.
Write the agent's purpose in one sentence, then remove any read type it does not serve.
Replace the owner with one named person from your agent register.
Look at the agent's tools. Browsing plus writing tools usually means tier 3 or 4.
Every domain ending in .example must become a real one, or be removed.
Fix every error. Reply to every warning in the pull request.
One table makes the differences between the six roles easy to see and discuss in a review.
| Agent | Tier | Read types | Unknown sites | On deny | Exceptions |
|---|---|---|---|---|---|
| market-research | 3 | 7 | Deny | Ask owner | None |
| support-answers | 2 | 4 | Deny | Block | None |
| procurement | 3 | 6 | Deny | Ask owner | Checkout, one supplier |
| coding-assistant | 4 | 3 | Allow reads | Block | None |
| sales-research | 3 | 7 | Deny | Ask owner | None |
| compliance-monitor | 2 | 4 | Deny | Block | None |
Notice the pattern. Tier drives on_deny, purpose drives the read types, and only one file needs an action page at all.
That is typical in real deployments. Most agents only need to read, and the few that must act can do so through one narrow, dated exception.
If your own files need many exceptions, the agent is probably doing too many jobs. Split it into two agents with two files.
Three commands take a file from download to a working check.
Use the names from your agent register, so logs and audits match.
Remove any type the agent does not need. Fewer is safer.
Review dates and exception end dates should reflect your calendar, not ours.
Five to ten URLs per file with the verdicts you expect.
Read types can go on an allow list. Action types can only be opened through an exception.
Full definitions: page types explained.
These six mistakes appear again and again in first drafts. Each one widens what the agent can do without anyone deciding it should.
Convenient at first, but the agent then wanders into pages its task never needed.
That opens checkout everywhere. Use an exception for one domain instead.
Temporary permissions quietly become permanent.
Nobody is there to answer, so the agent just stalls.
The shared file ends up as open as the most demanding agent.
An alias cannot be accountable. Name one person.
A file written once and never touched drifts away from what the agent really does. Small, regular habits keep it accurate.
All agent files in one folder, with the agent owners as required reviewers.
A weekly job lists files whose review date is within 14 days.
A monthly job removes expired exceptions in a pull request, so the file matches reality.
Tag the repository when files change, and record the tag in each verdict log.
Auditors can compare two tags and see every permission granted between them.
Removing the file removes the permissions. The history stays in version control.
The read page types an agent may open. Empty means all read types.
What happens on pages no layer can identify: deny, or allow reads.
Block a denied request, or route it to the owner for a decision.
A narrow, dated permission for one page type on one domain.
Each use of the exception waits for the owner to approve.
How far the agent may act alone, from 1 (answers only) to 4 (acts on its own).
The honest fine print — the same two assumptions we publish, plus two operational ones
Free examples, free enforcer, page-type data when you need full coverage.
