AI agent SSRF protection for browser automation

AI agent SSRF protection keeps a browser-capable agent from turning a harmless-looking URL, redirect, or page action into a request to a private service. For a self-hosted agent, the safe default is simple: block private and special-use network destinations, allow only the public hosts the task requires, and treat a browser policy as one layer rather than a firewall.

That boundary became more concrete in OpenClaw v2026.6.34. Its release notes call out safer sandboxed browser routes, trusted DNS targets, custom browser origins, and loopback provider endpoints.

Contents

Why browser agents need SSRF protection

Server-side request forgery, or SSRF, happens when an attacker convinces software that can make network requests to fetch an internal or otherwise restricted destination. An AI browser agent adds a different route into the same problem: it can follow links, process redirects, fill forms, click UI controls, and navigate based on content it encounters.

A public page does not need direct access to an internal service to cause trouble. It only needs the agent to make the request from a machine that does. That might mean a loopback service, a private IP address, a cloud metadata endpoint, an internal dashboard, or a provider endpoint that was supposed to remain local.

The risk is about network authority, not whether the task starts with a trustworthy URL. A research task can land on a page with a redirect. A support workflow can open a link contained in a ticket. A browser automation run can be asked to inspect a URL supplied by an external user. In each case, the agent may have access to a network path that the requester does not.

Browser taskUseful capabilitySSRF question to ask
Visit a vendor portalFollow an authenticated workflowCan navigation escape the vendor’s approved domains?
Review a user-supplied linkLoad external contentCould redirects resolve to a private address?
Run a local model workflowReach a loopback providerIs the local endpoint an explicit operator exception?
Use a remote GatewayControl a browser through a nodeDoes the browser machine have egress controls separate from Gateway policy?

This is adjacent to AI browser agent privacy, but it protects a different thing. Per-tab scope limits the browser context an agent can see. SSRF policy limits where browser traffic can go once the agent acts.

How OpenClaw’s browser policy works

OpenClaw documents a strict browser SSRF policy by default. When browser.ssrfPolicy.dangerouslyAllowPrivateNetwork is unset, private, internal, and special-use destinations stay blocked. The legacy allowPrivateNetwork name remains accepted, but it should not be treated as a convenience switch for a general-purpose browser.

When a workflow genuinely needs a private host, the safer move is an explicit exception. OpenClaw supports allowedHostnames entries, including wildcard patterns such as *.example.com and exact names. That lets an operator describe the hosts a task needs rather than granting access to every private address on the machine’s network.

{
  browser: {
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: false,
      allowedHostnames: ["*.example.com", "example.com"],
    },
  },
}

The configuration is an example of policy shape, not a copy-paste production allowlist. A hostname exception does not authorize one service: it does not constrain destination ports or paths, so localhost can reach multiple loopback services. If a browser workflow needs a local endpoint, pair the hostname exception with service-specific egress controls. A browser that only researches public sites should not receive that exception because another tool on the host happens to use it.

OpenClaw also preflight-checks direct navigation and guards several managed Playwright actions during a bounded action window. The documentation lists clicks, hovers, typing, form fill, and evaluate among the interactions that can intercept denied top-level and subframe document loads before request bytes are sent. That is useful because an agent often reaches a bad destination indirectly, after starting on an allowed page.

For the operator surface itself, keep the Gateway separate from browser traffic. OpenClaw Control UI setup explains why the Gateway should stay loopback-only when possible, with explicit authentication and device pairing for access. A browser request policy does not replace Gateway authentication, origin controls, or a private access path.

A practical AI agent SSRF protection baseline

A good baseline has a short deny-by-default policy and a review path for exceptions.

  1. List the browser task’s real destinations. Write down the public domains, internal services, and local endpoints the workflow needs. Do not start from the whole network and try to subtract risky hosts later.
  2. Keep private-network access disabled. Leave dangerouslyAllowPrivateNetwork false unless the task has a documented internal dependency.
  3. Add exact hostnames before broad patterns. Use localhost or a named internal host only when needed. If a subdomain pattern is unavoidable, document why every matching subdomain is in scope.
  4. Separate the browser profile from operator services. A browser node or host that can touch many internal services has a larger blast radius than a dedicated automation environment.
  5. Review redirects and popups as part of the task. An allowlist is more useful when the workflow is tested against the way it actually moves between pages.
  6. Re-run the security audit after exposure changes. OpenClaw recommends openclaw security audit --deep after configuration or network exposure changes. Treat a new proxy, bind address, or remote browser node as a meaningful change.

This is also where a self-hosted AI agent security review helps. The browser is one component in a larger chain that includes the Gateway, tools, node pairing, credentials, and the host network. A tight browser allowlist loses much of its value if an agent can later obtain unrestricted host networking through another tool.

Where browser policy stops

Browser SSRF protection is not an egress firewall. OpenClaw explicitly notes that its routing is request-level interception. Redirect hops, a popup’s first request, service worker traffic, code that runs after the bounded guard window, and some background or subresource paths may evade that guard. Final URL checks provide detection and quarantine defense; they do not make those paths impossible.

That limitation should change the deployment decision. If the browser host can reach sensitive internal systems, put an owner-controlled network boundary in front of it: a policy-enforcing proxy, a network namespace, a separate VM, or outbound firewall rules that allow only what the workflow needs. Use the browser policy to catch unsafe application-level navigation, then use network controls for the destinations the browser should never reach under any condition.

The same rule applies to DNS. A hostname allowlist is useful, but it is not a substitute for verifying that the resolved destination and the proxy path match the operator’s intent. OpenClaw’s security guidance recommends keeping trusted proxies tight and treating DNS rebinding and proxy Host-header handling as deployment-hardening work. Avoid a permissive proxy configuration that gives a browser policy an easy path around itself.

Test the boundary before using real accounts

Run a small test on a non-production browser profile before connecting a valuable account or internal service.

TestSetupExpected result
Private address navigationAsk the agent to open a loopback or RFC1918 URL that is not allowedThe navigation is denied and the run records the policy failure.
Approved local serviceUse a required exact hostname such as localhost in a controlled testThe browser policy allows the hostname; service-specific egress controls permit only the documented endpoint.
Redirect chainStart on an approved public page that redirects to a denied targetThe browser does not silently continue to the private destination.
Popup or background requestUse a test page that opens a new window or loads an extra resourceNetwork controls, not just the browser policy, prevent restricted egress.
Remote-node pathRun the workflow through the actual paired browser nodeThe node’s network policy matches the Gateway operator’s assumptions.

Keep the test evidence: the URL, resolved address, browser output, and relevant policy configuration. If the agent needs a new exception later, compare it to this baseline instead of enabling broad private-network access under pressure.

FAQ

What is AI agent SSRF protection?

AI agent SSRF protection limits the network destinations an agent can cause a browser or tool to request. It is meant to prevent untrusted content, redirects, or loose instructions from reaching private, local, or otherwise restricted services through the agent’s own network access.

Does OpenClaw block private browser destinations by default?

OpenClaw documents strict browser SSRF behavior by default: private, internal, and special-use destinations remain blocked when browser.ssrfPolicy.dangerouslyAllowPrivateNetwork is unset. Operators can add narrow hostname exceptions when a workflow has a real internal dependency.

Should I set dangerouslyAllowPrivateNetwork to true for local tools?

Only if the workflow needs broad private-network access and you have separate egress controls. An exact allowedHostnames exception is narrower than enabling the private network, but it still allows every service reachable through that hostname. Use service-specific egress controls when the workflow needs one local provider or endpoint.

Is a hostname allowlist enough to stop SSRF?

No. OpenClaw describes browser routing as request-level interception, not a full network firewall. Combine the allowlist with host or network egress controls, tight proxy settings, and a dedicated browser environment for sensitive workflows.

Sources: