# Agents, localhost and internal networks: enforce what the executor can actually reach Canonical: https://www.web3sec.news/blog/agent-localhost-network-boundaries Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Agent network isolation Published: 2026-11-08 Updated: 2026-11-08 Protect local bridges, development services, cloud metadata and internal APIs with explicit network and application boundaries. ## The short answer Restrict agent network access at the component that makes requests, including browsers, URL-fetch tools and local bridges. Validate destinations and redirects, isolate internal and metadata services, and authenticate local APIs. Test with operator-owned endpoints and synthetic data; a public-site allowlist or browser-origin policy alone does not constrain every server-side executor. ### Diagram: Investigate untrusted code in an isolated place. Keep research environments disposable and separate from host identity. ![An untrusted repository enters a disposable sandbox with no host secrets, no writable host mounts, and restricted egress. Only reviewed findings leave the sandbox; running a repository is not a reason to expose credentials.](https://www.web3sec.news/diagrams/research-sandbox.svg) [Full-size SVG](https://www.web3sec.news/diagrams/research-sandbox.svg) · [PNG download](https://www.web3sec.news/diagrams/research-sandbox.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Map every requester and its network position Assign a network-boundary owner and list the processes that can fetch URLs: browser automation, server-side preview tools, MCP servers, command runners, document converters and local bridges. Record where each executes and the networks it can reach. A public browsing task can still cause an internal request if a backend helper runs beside production services or inherits a cloud workload identity. Inventory local development servers, administrative dashboards, debugging ports and bridge APIs. Determine which require authentication and which assume that anything on the host is trusted. Bind services to the intended interfaces and remove unused listeners. Do not equate loopback binding with authorization: another local process or a network-enabled tool acting on untrusted instructions may be able to exercise the same sensitive endpoint. ## Validate destinations and enforce network policy OWASP’s SSRF guidance addresses destination validation, allowlists and the risks of server-side requests influenced by untrusted input. Apply controls in the executor, not only in the agent prompt. Restrict schemes, destinations and ports to the task’s needs, check redirects and account for address resolution. A permitted initial hostname must not become a blanket authorization for every subsequent destination or alternative request path. Use network enforcement to restrict private, loopback and link-local destinations unless specifically required by the authorized task. Test IPv4 and IPv6 behavior and the actual proxy or container routing in use. Browser-origin controls, server-side fetch rules and operating-system network restrictions have different coverage. Review uploads and response forwarding as well as GET requests, and avoid allowing an unrestricted shell tool to bypass a carefully constrained URL tool. ## Protect metadata and local bridges independently AWS documents IMDSv2’s session-oriented metadata access and configuration options for the instance metadata service. Review the deployment’s actual metadata settings, workload role and container access needs. Do not assume a metadata protocol upgrade compensates for a broadly privileged workload or an executor allowed to perform arbitrary requests. Remove access where the workload does not need it and constrain the role’s downstream authority. For local bridges, require an explicit authentication and authorization model, validate request origins where applicable and restrict the operations exposed. Review token storage and how a browser or remote connector obtains access to the bridge. Keep debug and administration endpoints out of the general agent interface. Protocol behavior differs by transport and version, so document the tested implementation instead of claiming that a familiar local URL or integration name guarantees isolation. ## Test the boundary without probing unrelated systems Build an operator-owned lab with one allowed endpoint, one denied internal-style endpoint, a controlled redirect and dummy metadata. From each executor, verify that allowed work succeeds and prohibited access is blocked before sensitive content is returned. Inspect network and application logs, including whether a denied URL can be reached through another tool. Keep tests limited to endpoints and environments you control or are explicitly authorized to assess. When a bypass appears, disable the affected executor path, preserve the request trace and determine whether real internal data or credentials were reached. Revoke exposed authority and review completed downstream actions from a trusted environment. Repair the shared network or authorization boundary and rerun the full requester matrix. Closure should identify the enforced destinations for every execution component, not merely the one URL parser that rejected the original test. ## Controls to take away - Network risk follows the executor, not the agent’s displayed URL. - Loopback and CORS are not substitutes for API authorization. - A denied request through one tool may remain reachable through another. ## Work through the boundary Local planning worksheets; they do not inspect or change accounts or environments. - [Prepare the research environment](https://www.web3sec.news/tools/research-preflight): Check authorization, source, credentials, egress and disposal for the actual lab boundary you will use. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Inventory browsers, fetchers, bridges and command runners by network position. - [ ] Authenticate sensitive local endpoints and remove unused listeners. - [ ] Enforce destination, redirect and address restrictions in the requester. - [ ] Review metadata access and downstream workload permissions. - [ ] Test each requester against controlled allowed and denied lab endpoints. ## Common questions ### Is a service safe because it listens only on localhost? Loopback binding limits network exposure, but software on that host may still reach it. An agent’s browser, local bridge or command executor can create another path. Use authentication and explicit authorization for sensitive local operations. ### Does CORS prevent an agent from calling an internal API? CORS constrains specific browser interactions; it is not a network firewall or a general server-side authorization rule. Check the actual requester, reachable addresses and API authentication rather than relying on one browser mechanism. ### Should I test an agent against real cloud metadata credentials? Use a controlled metadata-like test endpoint with dummy data in an authorized lab. Verify denial without collecting real credentials, and review the actual cloud instance and workload identity configuration separately. ## Sources & further reading - [OWASP: server-side request forgery prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) - [AWS: instance metadata service and IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)