Keep AI Link Fetchers Out of Your Private Network

“Read this supplier's report” sounds like a modest permission. Yet if an assistant downloads the link from an application server, the request uses that server's network position—not the user's laptop. A service reachable from the server may be invisible to the person who supplied the URL. Approving the reading task does not authorize all those destinations.

This guide addresses that implementation decision, not a reported ZharfAI incident: should a request use an isolated public-web fetcher, a named authenticated connector, or neither? The important boundary is the connection actually opened after parsing, name resolution and redirects. A plausible domain displayed in chat is only the beginning of that process.

Give public reading and internal access different tools

OWASP's SSRF prevention guide describes server-side request forgery: an application can be induced to contact an unintended destination. It distinguishes integrations with known destinations from features that accept arbitrary external addresses, and recommends application and network defenses. For an AI product, the model adds another source of proposed URLs; it does not change who must enforce access.

ZharfAI's recommended split is deliberately narrow. A public fetcher has no enterprise credentials and no route to private services. A connector performs a specified business operation on an authorized resource. A request that fits neither is rejected or sent back for clarification. Do not turn the public fetcher into a universal client by adding an “internal access” checkbox.

The tool-permission guide explains authorization of the requested action. This design adds an independently enforced answer to “where may its network request go?” Both are necessary: a permitted read can still be sent to a forbidden receiver.

Parse once, then apply a smaller product policy

A URL parser establishes structure, not trust. The WHATWG URL Standard explicitly distinguishes a validation error from parser termination: some unusual input is normalized rather than rejected. Therefore, “the library accepted it” is not a security decision. Nor is a regular expression looking for a familiar domain anywhere in the string.

Choose a maintained parser compatible with the transport and evaluate its parsed scheme, hostname, port and user-information fields. For this proposed public-report tool, allow HTTPS on explicitly approved ports, reject embedded credentials, and reject control characters or ambiguous backslash input before parsing. These are deliberately stricter product choices, not claims that every rejected URL is invalid under the standard.

Define normalization once. Compare normalized hostnames with exact approved names or properly bounded subdomains, not loose suffix matches. Internationalized names should pass through the same hostname normalization used by the connection layer. A name that looks familiar to a reviewer receives no special privilege.

Pass the approved structured request forward; do not later rebuild it from the original model string. If the HTTP library, proxy or redirect handler parses the address differently, the first check may describe a different request. Reject unsupported schemes outright. A report reader has no reason to interpret a URL as a local file or an arbitrary protocol command.

Bind name resolution to the connection

DNS converts a hostname into candidate addresses. The security check must cover the addresses the connector can actually select, including IPv4 and IPv6. Checking one answer and then letting a different component resolve the name again leaves a gap between the checked destination and the contacted destination.

The IANA IPv4 special-purpose registry and IPv6 registry document address classes and their properties. They are reference data, not a permission list for your organization. A globally reachable address is not automatically an approved destination, and private services can also occupy publicly numbered space.

Use maintained address classification and a reviewed network policy. Cover loopback, private, link-local, unspecified, multicast and other disallowed special-purpose ranges; handle IPv4-mapped IPv6 and environment-specific translation paths consistently. Add your organization's management and service ranges, even when their addresses look public. Review exceptions rather than copying a few familiar prefixes into application code.

For the public fetcher proposed here, a mixture of permitted and forbidden DNS answers fails closed. Every fallback address must be authorized. Bind the approved address selection to the component opening the socket, while preserving the original hostname for TLS server-name indication and certificate verification. Never “fix” address pinning by disabling certificate checks.

If a proxy owns resolution and connection establishment, enforcement belongs there too. An application inspecting its own DNS answer cannot certify a proxy's separate choice. Connection pooling, alternate transports and failover paths must preserve the same policy; a previously accepted hostname is not a permanent exemption.

Treat a redirect as another request proposal

Disable automatic redirect following for the simplest public reader. If useful sources require redirects, implement a bounded loop whose every hop repeats parsing, destination policy, address resolution and connection authorization. Resolve a relative redirect against the current approved URL, then evaluate the resulting address in full. A same-host redirect still does not grant unlimited ports, paths or future addresses.

RFC 9110's redirect semantics discuss rebuilding redirected requests, removing or reconsidering sensitive headers, and detecting loops. The application should explicitly choose its own narrower behavior rather than assume a library's defaults match its security policy.

Our proposed public tool permits a fixed read method, no caller-supplied body and only a small tool-controlled header set. It carries no cookies, authorization headers or organization secrets between destinations. Do not forward the user's conversation as a referrer or debugging header. Even a GET request can trigger behavior on a badly designed endpoint; method restriction reduces capability but does not make destination authorization optional.

Choose hop, total-time and transfer limits for the workload. Count the entire chain against one budget; resetting the deadline at every redirect defeats the limit. When a redirect is refused, return a clear access-policy outcome. Do not ask the model to try an alternate spelling or a different protocol until something gets through.

Cloud metadata defenses are a second boundary

A worker without ordinary environment secrets may still run beside a platform metadata service. That makes deployment identity and network placement part of the fetcher's design, not just its URL validation code.

AWS documents IMDSv2 as session-oriented metadata access using a token, with configuration available to require version 2. Microsoft's Azure IMDS documentation requires a metadata header and rejects requests containing X-Forwarded-For, but also states that the API is unauthenticated and accessible to processes on the VM. These are different mechanisms; a required header is not a user-specific authorization grant.

The engineering implication is not to reproduce metadata requests in the assistant. Remove the public fetcher's need and ability to access metadata wherever the deployment permits, and apply platform hardening as defense in depth. Check the actual hosting model rather than assume every container, function or VM has identical metadata behavior.

Keep privileged connector execution separate. If internal access is genuinely required, the credential-brokering guide describes how a trusted component can exercise narrowly scoped authority without handing a secret to the model. Do not attach that component's identity to every public download for convenience.

Follow one request through a controlled example

Consider a fictional report link that redirects to a download host. The table uses symbolic destinations, not real endpoints or observations from a deployed product. “Private” means forbidden by the stipulated public-fetch policy.

There is one permitted connection in this trace and no connection to the redirected host. Returning an error after downloading from the private address would be too late: the request itself already crossed the boundary. Checking only the final document's content cannot undo it.

The mixed-answer rule trades availability for a simpler guarantee. A legitimate service with unexpected DNS configuration can be blocked. Give the owner a route to investigate and correct the integration, but do not automatically widen policy because the report is urgent. An approved connector is an explicit product decision, not an emergency bypass hidden in a retry.

The downloaded document still has no authority

Network authorization says where bytes may come from. It does not establish that the bytes are accurate, safe to parse, authorized for every employee, or entitled to instruct the model. A successfully fetched page remains external data.

Separate downloading from document extraction. Give the parser no default network access and enforce resource limits on compressed and decoded data, processing time and nested objects. Otherwise an apparently completed fetch can cause additional requests through document resources or conversion tools. If following a referenced resource is necessary, send it back through the same authorized fetching path.

Use an explicit supported-format list. Do not add a full script-capable browsing environment merely because a page returned little extractable text. That is a materially different capability with its own state, network behavior and review requirements. The user-facing result can instead explain that the tool cannot read this source format.

Before indexing or acting on the result, apply the separate knowledge-base admission process. Preserve the distinction between a source's statements and instructions to the assistant. Neither a familiar hostname nor a successful TLS connection grants a document permission to change the user's task.

Test the dialer, not just the validator

A unit test that returns “blocked” from a string-checking function proves little about an HTTP client's behavior. Test the complete enforcement path with a controlled resolver, transport instrumentation and owned fixtures. No test needs to contact someone else's private service.

Include direct disallowed destinations, mixed-family answers, mapped addresses, changed answers between checks, redirects into forbidden ranges, redirect loops, alternate ports and malformed input. Confirm that blocked hops make zero connection attempts. Also test ordinary approved reports and legitimate redirects so the system does not achieve an impressive denial rate by refusing everything.

Exercise proxy resolution, connection reuse and address fallback explicitly. Test whether authorization or cookies appear at another origin; in this proposed public tool neither should be present at the first origin. Confirm that a parser cannot make an unmediated secondary request and that compressed responses cannot evade the decoded-size budget.

These are acceptance-test recommendations, not results of a ZharfAI penetration test. Passing a fixture suite establishes behavior for those cases and that configuration. It does not prove that every future library version, deployment network or hostile input is safe. Keep the fixtures with the transport integration, where changes are most likely to invalidate assumptions.

Record the boundary without recording secrets

A useful fetch receipt connects the caller and task to the normalized destination, policy version, resolver outcome, selected peer, redirect count, bytes processed and terminal disposition. Record whether the enforcing component was the application dialer or a proxy. Retain enough to distinguish a policy refusal from a timeout or unsupported file.

Do not put full signed URLs, query secrets, cookies or document contents into routine logs. Redact sensitive components and use controlled evidence storage when deeper investigation is justified. Access to network traces itself deserves a retention and access policy.

Monitor blocked-hop reasons, unexpected peer destinations, legitimate-source failures, redirect depth and resource-limit refusals. A blocked request is not automatically an attack; a high success rate is not proof of isolation. Review approved-fetch samples as well as refusals, and rerun transport tests after parser, HTTP client, proxy, DNS or hosting changes.

The operating rule is simple: the model proposes a source, policy selects an access path, and the network executor enforces the destination. Keep those responsibilities separate even when the request is only “read this link.”

Source notes — checked September 21, 2026

• OWASP, SSRF Prevention Cheat Sheet: rolling, undated guidance; consulted on the review date.
• WHATWG, URL Standard: living standard displaying an update of September 10, 2026.
• IANA, IPv4 Special-Purpose Address Registry: last updated October 9, 2025.
• IANA, IPv6 Special-Purpose Address Registry: last updated October 9, 2025. Neither registry is an organization-specific authorization policy.
• IETF, RFC 9110: HTTP Semantics, June 2022; especially section 15.4 on redirects.
• AWS, configuring the Instance Metadata Service: rolling, undated product documentation.
• Microsoft, Azure Instance Metadata Service: updated July 29, 2025. The tool split, decision tables, fictional trace and measurement recommendations are ZharfAI analysis, not vendor certification or measured customer outcomes.