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.
These local worksheets turn the review questions into a plan. They do not inspect or change the actual account or environment.
Prepare the research environment ↗
Check authorization, source, credentials, egress and disposal for the actual lab boundary you will use.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
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
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.