Teams building on agent frameworks keep asking the same question in different words: "where do we actually plug a URL policy check into our stack." The honest answer is that it depends on the shape of the stack, not the specific product name. Across the ecosystem, a URL check attaches at one of four structural points — a wrapped tool call, a guardrail hook, a proxy or gateway, or a browser extension. This is a map of those shapes, not a ranking of named products.
None of the 2026 agent incidents were stopped by the framework itself. Each one ran on some agent stack with a hook point available and unused. Our database and egress rules, wired into whichever hook point a given stack exposes, would have prevented almost all of them.
Every agent framework, orchestration library, and deployment pattern has to decide, structurally, how a tool call or a browsing action reaches the network. That structural decision determines where a URL policy check can attach, and it has nothing to do with which framework is "better" — a well-built agent stack of any shape can wire in a page-type check, and a poorly configured deployment of any shape can skip it entirely. What varies across the ecosystem is not whether a hook point exists, but which of four recognizable shapes it takes.
This page deliberately does not name or rate specific frameworks against each other. The shapes below are patterns that recur across the ecosystem regardless of which specific library, SDK, or platform a team has chosen, and the practical task for any team is to identify which shape (or shapes) its own stack exposes, then wire a page-type check into that exact point.
It also helps to be honest about why this shape-based framing matters more than a product-by-product feature comparison would. Frameworks change their APIs, guardrail conventions get renamed, and new orchestration libraries appear regularly enough that a comparison pinned to specific product names goes stale quickly. The four structural shapes described here, by contrast, are a description of how software fundamentally routes a request from an agent's decision to the open internet, and that structure changes far more slowly than any individual framework's naming conventions. A team that understands which shape its own stack exposes can evaluate a brand-new framework against the same four categories the day it is released, without waiting for anyone to publish a comparison of that specific product.
| Dimension | Tool-wrapper | Guardrail-hook | Proxy / gateway | Browser-extension |
|---|---|---|---|---|
| Where it sits | Around one named tool function | At a framework-defined lifecycle stage | On the network path, outside any one framework | Inside the browser, at navigation events |
| What it sees | The arguments passed to that specific tool | The agent's proposed action or output | Every outbound HTTP request, regardless of origin | Every page load and click the browser performs |
| Coverage if agent bypasses the tool call | Gap — only covers requests made through that tool | Depends on whether the hook covers all action types | Full — nothing reaches the network outside the proxy | Full for browser-driven navigation specifically |
| Setup effort | Low — wrap one function | Low to moderate — register a hook | Moderate — route traffic through the proxy | Moderate — instrument the browser layer |
| Framework dependency | Tied to that framework's tool-calling convention | Tied to that framework's guardrail API | Framework-agnostic — works regardless of what calls it | Tied to the browser-automation approach in use |
| Best fit | Single-purpose agents with one well-defined browsing tool | Frameworks that already ship a guardrail lifecycle stage | Multi-framework or multi-agent deployments needing one enforcement point | Computer-use and browser-driving agents specifically |
No single shape is universally correct. A team running one agent through one well-defined browsing tool may find the tool-wrapper pattern sufficient and simplest. A team running many agents across several frameworks typically converges on the proxy/gateway pattern specifically because it does not care which framework generated the request — it enforces on the network path, which is common to all of them.
Most agent frameworks let a developer register a Python or JavaScript function as a callable tool, typically named something like browse_url or fetch_page. The wrapper pattern inserts the policy check as the first line inside that function body, before the actual HTTP request is made, and returns a structured denial the agent's own reasoning can see and act on if the check fails.
Strength: trivial to add to an existing agent with one browsing tool. Limitation: only covers requests that go through that specific tool — a second, unwrapped way to reach the network (a code-execution tool that can itself make HTTP calls, for instance) bypasses it entirely.
Frameworks that ship an explicit guardrail or validation lifecycle stage let a developer register a function that runs before an action is executed or before output is returned, with the ability to block, modify, or flag it. The check runs inside that registered function, evaluating any URL the proposed action would visit.
Strength: integrates with the framework's own safety conventions and error-handling. Limitation: coverage depends entirely on which action types the framework's guardrail stage actually intercepts — if browsing actions route around that stage, so does the check.
All outbound HTTP traffic from the agent runtime, container, or VM is routed through a forward proxy or API gateway configured as the only network egress path. The proxy checks every request's URL against the page-type policy before forwarding it, independent of which tool, framework, or even which of several agents on the same infrastructure generated it.
Strength: framework-agnostic and comprehensive — nothing reaches the network without passing through it, closing the bypass gap the other patterns can leave open. Limitation: requires network-level configuration rather than an in-code integration, which is more setup for a single simple agent.
For agents that operate an actual browser — computer-use style agents, or browser-automation libraries driving a real page — the check runs as an event listener on navigation and click events inside the browser layer itself, before a page finishes loading or an action completes on it.
Strength: sees exactly what the browser sees, including client-rendered content and redirects a network-level proxy might resolve differently. Limitation: specific to browser-driven agents; does not help an agent making direct API or fetch calls outside a browser context.
Take one concrete case: an agent's plan calls for opening what turns out to be a checkout page. Here is how each shape would encounter and handle that exact same request, structurally.
| Hook-point shape | What triggers the check | What the agent sees on deny | What it would miss |
|---|---|---|---|
| Tool-wrapper | The agent calls its registered browsing tool with the checkout URL | A structured error or denial object returned from the tool call itself | A second, unwrapped tool (e.g., raw code execution) that can also make HTTP requests |
| Guardrail-hook | The framework's before-action lifecycle stage receives the proposed navigation | The action is blocked before execution, framework-native error surfaced | Action types the guardrail stage was not configured to intercept |
| Proxy/gateway | The outbound HTTP request reaches the proxy on its way out of the network | A blocked connection or non-200 response at the network layer | Nothing within its scope — it sees every outbound request regardless of origin |
| Browser-extension | The browser is about to navigate to or load the checkout URL | Navigation is canceled before the page renders | Requests made outside the browser context, such as a background API call |
Notice the pattern in the last column: every shape except the proxy/gateway has a specific kind of request it structurally cannot see, because each one attaches to one particular path the agent might take rather than to the point where all paths converge. This is exactly why teams running more than one agent, more than one framework, or an agent with more than one way to reach the network tend to add a proxy/gateway layer even when they already have a tool-wrapper or guardrail-hook in place — not because the other patterns are wrong, but because they are, by construction, narrower in scope.
There is no formula that maps a framework name to a required hook-point shape, but a few practical signals tend to recur across real deployments and are worth checking against your own setup before committing to one pattern.
Most production deployments eventually run more than one shape at once, and that overlap is a feature, not a sign of a wrong initial choice. A tool-wrapper catches the common case cheaply and immediately; a proxy/gateway sitting underneath it catches whatever the wrapper's own scope could not reach. Neither replaces the value of standing the other one up first.
List every way your agent's runtime can reach the network: a browsing tool, a code-execution sandbox, a direct API client, a real browser. Each path needs its own hook or a shared one that covers all of them.
Look for an existing guardrail, hook, or middleware lifecycle stage before building a custom wrapper. Many frameworks already have one; reuse it rather than duplicating enforcement.
Once an agent has two or more ways to reach the network, or you run multiple agents on shared infrastructure, a proxy/gateway closes the bypass gap that per-tool wrappers leave open.
Regardless of hook-point shape, the check itself should default to deny for unclassified or unrecognized page types, not default to allow.
Every one of the four hook points ultimately makes the same call: a single HTTP request to a page-type lookup, evaluated before the agent's own request proceeds. The engineering difference between the shapes is entirely about where that call is triggered from, not what it evaluates or how it decides.
This separation between "where the check attaches" and "what the check decides" is worth keeping distinct when a team is scoping the work. Choosing and wiring a hook point is an integration task, usually a matter of hours once the right shape is identified. Deciding what the check should return for a given URL is a data problem, and it is the part that does not get easier by picking a different framework: it requires a verified, maintained map of page types across however many domains the agent is likely to encounter, which is the part most teams underestimate until they try to hand-maintain it themselves.
Whether it runs inside a wrapped tool, a guardrail callback, a proxy's request handler, or a browser navigation listener, the check is the same request:
High-volume proxy and gateway deployments typically license the full database for a local lookup rather than calling the API per request. Full request and response examples are in the API docs; pricing for both paths is on the pricing page.
For the same hook-point thinking applied to blocking risky AI tools on the human side rather than agent browsing, see AI Tools Blocklist, the sibling product covering 20,000+ AI-tool domains by risk category.
28 page types, 40M+ domains, verified URLs, one HTTP check. Start with the free sample, then pick a lookup plan or a database tier.
