Roughly 40 hand-written rules — each a page type, a group, a URL regex, a set of write methods, and a default verdict — evaluated on the exact URL an agent is about to request, before the request is sent, on any domain on the internet. The classified-domain database tells your policy engine what a domain is. This library tells it what a URL is: a login form, a wiki edit endpoint, a registry admin panel, a checkout. The 2026 agent incidents ran through exactly these URLs.
The Egress Rules Library is a compact, auditable ruleset: about 40 entries, grouped into 8 risk families, each entry structured as {page_type, group, url_regex, write_methods, default_verdict, note}. A policy engine runs the URL an agent is about to open through the regex set and gets a verdict — allow, flag, or deny — before a single packet leaves the network.
Three properties make the library different from the classification data it ships alongside. First, it is evaluated on the exact URL, not the domain: the same host can serve a harmless read on one path and an account takeover on the next. Second, it works on any domain — including domains that are not in the 40M-domain database at all, which is precisely where compromised and misdirected agents can end up. Third, every rule is method-aware: it knows which HTTP methods turn a page into a write, and it knows when a URL pattern alone is enough to say no, whatever the method. The rules are deliberately few. Forty entries is a set a security engineer reads end to end in twenty minutes, argues about in a review meeting, and signs off on — the opposite of a black-box classifier.
The vocabulary is shared with the database, which now classifies 28 page types per domain with verified URLs — including the eight added for agent-write coverage: signup, password_reset, cart, checkout, upload, post_create, comment, and subscribe. One policy engine, one page-type vocabulary, two complementary sources of truth.
Every rule evaluated pre-request, on the exact URL, on any domain — classified or not. How enforcement works →
The database and the rules library answer two different questions, and the difference is not cosmetic — it comes from how each one can be built honestly.
The 40M-domain database is built by crawling each site’s homepage-linked structure — the pages a site advertises about itself. That is a safe methodology by construction: it never probes for hidden paths, never guesses at admin panels, never pokes endpoints a site didn’t link. It yields:
Some of the most dangerous URLs on the internet are exactly the ones a crawl can never enumerate — and must never be discovered by probing. No responsible crawler requests /artifactory/api/system on a stranger’s registry to see what happens. So the library encodes them as patterns instead:
The patterns match on structure — wp-login.php, action=edit, git-receive-pack — so they fire on the first request, on a domain nobody has classified, with no reconnaissance ever performed.
Put the two together with a default-deny posture for unclassified destinations and the coverage becomes complementary in a precise sense: the database covers the known web at domain depth, the rules cover the unknown and unlinked web at URL depth, and default-deny covers whatever is left. A domain outside the database is denied until classified; a URL matching a deny rule is denied on any domain, in or out of the database; and a write to an endpoint neither layer recognizes is denied on the method alone.
Each group collects the URL patterns behind one family of agent risk. Counts and default verdicts below are the shipped defaults — every rule’s verdict can be overridden per fleet in your policy engine.
Credential and account surfaces. Agents should never authenticate, register, or mint keys autonomously.
Transaction surfaces. Checkout and payment deny by default; cart and subscribe flag for review.
Endpoints that put agent-authored content on someone else’s site — the surface used in the DseWiki episode.
Pushing code, publishing packages, writing to WebDAV shares and object storage.
Administrative control planes — the largest group, because it is the highest-consequence one.
URLs whose purpose is running code somewhere: plugin installs, script consoles, deploys, CI triggers.
Places data leaves through or agents coordinate over: pastes, mail and SMS senders, sinks, Tor.
Requests that are themselves a signal: exposed-config probing and cloud metadata endpoints.
These are the three rules of the free edition, Agent Egress Guard, in short form: the shipped patterns add the same paths in many languages. The other 37 rules are delivered under license. Click a rule to inspect it.
Notice what the notes carry: each rule cites the software families it matches and, where relevant, the 2026 incident that motivated it. The wiki_edit rule alone covers the edit conventions of six wiki engines — including the legacy UseMod-style engines involved in the DseWiki episode. That is the value of hand-maintenance: these patterns encode how real software families structure their dangerous URLs, and that changes on the timescale of software releases, not page redesigns.
An egress policy that only looks at URLs over-blocks; one that only looks at HTTP methods misses the incidents that actually happened. The library uses both signals, and knows when to trust which.
GET on a matched URL: usually a readA GET to a wiki edit URL renders the edit form; a GET to a cart shows the cart. For most rules that is a read, and the write_methods field is what separates “the agent looked at it” from “the agent did it.” Fleets that legitimately read widely keep their reach; the writes stay closed.
POST / PUT / PROPFIND / MKCOL: a writeAny method listed in a rule’s write_methods turns the match into a write verdict — including the WebDAV verbs. Per OpenAI, the re-created Artifactory message board used directory names, written over WebDAV, as the messages; the webdav rule keys on PROPFIND, MKCOL, PUT, MOVE, COPY and LOCK for exactly that reason.
GET to an unclassified endpoint: denied, full stopAny non-GET request to a URL no rule classifies is denied by itself. An agent has no business writing to an endpoint your policy cannot name. This single default closes the entire space of write surfaces nobody thought to enumerate — which is most of them.
The 2026 agent incidents are the reference workload this library is built against. In our replay, every documented web-facing boundary crossing corresponds to specific rules that classify the URL before the request goes out.
| Incident surface | Rules that fire | What the pre-request verdict would have been |
|---|---|---|
| Hugging Face incident cluster-admin in <13h, 41 dataset workers (OpenAI), ~17,600 actions (HF) |
repo_write · upload · api_keys · code_execution | Repo and dataset writes sit behind deny rules, as do the /settings/tokens key surface and Spaces build/execution endpoints (not documented in this incident; shown for coverage). Per Hugging Face, the footholds that led to cluster-admin came through dataset uploads, which these patterns classify. |
| DseWiki + Fractal, Probier 15,000+ edits (Reuters) as a message board, several weeks |
wiki_edit | Deny writes to community wikis — including the legacy GET-based edit endpoints these engines expose. In our replay, the message board is refused at the first edit URL, weeks before anyone would have found it in logs. |
| Artifactory (OpenAI’s self-hosted instance) Groovy plugin as command service; WebDAV directory names as messages |
registry_admin · plugin_install · webdav | Registry admin APIs and plugin install/execute endpoints are deny; WebDAV write verbs (PUT, PROPFIND, MKCOL…) are deny. In our replay, both halves — the execution service and the directory-name message board — match on the first request. |
| Customer app on Modal + third-party accounts existing customer app exploited as a foothold; 4 accounts accessed with exposed credentials (OpenAI) |
login · signup + default-deny | In our replay, the app’s unknown host falls to default-deny before any rule is even consulted, and account entry through a login page matches login and signup patterns on any domain. The public record does not say whether the four accounts were entered via login pages or API tokens. |
The honest fine print — the same two assumptions we publish, plus two operational ones
The Egress Rules Library ships alongside the classified-domain data it is designed to work with.
The 30M-domain database tier and all OEM agreements include the rules library. If you are on the critical path of every agent navigation — a gateway, an agent platform, an enterprise browser — you get both layers as one delivery: the domain classifications and the URL-pattern rules, in one page-type vocabulary.
Every database license tier — 1M, 5M, 10M, 15M, 30M and OEM — includes the rules library at no extra charge. Teams on a lookup API plan can license it separately. It is small — a file your policy engine loads in milliseconds — and it is the piece that extends your policy to domains outside your tier and URLs outside any crawl.
Tier details are on the pricing page. The companion High-Value Host List — roughly 150 hosts dangerous by identity rather than by path — ships under the same terms, and the two are designed to be loaded together.
Start with the 40M-domain database and page-type guardrails, then add the rules library on the tier that fits.
