← Blog · MCP security · May 16, 2026

Fetch SSRF checklist

MCP fetch tools need egress policy before they need better prompts.

A URL tool can reach whatever the MCP server can reach. If that server runs in a cloud, CI, laptop, VPC, or cluster, open fetch becomes a credential and internal-network boundary. The safe default is to deny dangerous targets before the request leaves the runtime.

Fast answer

→A fetch MCP server is not just a read tool. It is network egress running from wherever the agent host sits.
→SSRF protection has to run before the HTTP request: parse the URL, resolve DNS, classify every resolved address, apply redirect policy, and deny metadata, loopback, private, IPv6 ULA, and in-cluster targets by default.
→Allowing public URLs is not the same as allowing internal services. Internal fetch needs its own route card with caller, tenant, target, credential lane, quota owner, review owner, and receipt fields.
→The pass/fail proof is paired: one allowed external URL and one denied neighbor such as 169.254.169.254 must travel through the same endpoint, gateway, retry, and trace path.

MCP Route Review fit check

Ask for review when the SSRF question has one repeat route.

If the question is no longer “should fetch be allowed?” but “can this agent safely call this fetch route again?”, send the route to MCP Route Review with one allowed public URL fixture, one closest denied neighbor, the credential and budget owners, and the receipt or typed-denial fields you expect to preserve.

The production checklist

URL parse gate

Reject missing schemes, userinfo surprises, encoded host tricks, non-HTTP schemes, overlong inputs, and ambiguous normalization before DNS resolution.

DNS and IP classification

Resolve the hostname at request time, classify every A/AAAA result, and deny link-local, loopback, private, carrier-grade NAT, multicast, IPv6 ULA, and service-network addresses by default.

Redirect containment

Apply the same host and IP policy after every redirect. A safe first URL cannot redirect into metadata, loopback, or private infrastructure.

Credential-lane isolation

Record which server, cloud role, proxy, token, cookie jar, or provider credential would be exposed if the request were allowed.

Internal-route exception

If internal access is intentional, require a named route card with target host/CIDR, caller, tenant, purpose, review owner, credential lane, and quota owner.

Developer-local exception

Treat Docker or loopback access as an explicit deployment-mode assertion, not a URL property. Match only a tiny pre-DNS local host-token set and keep the normal SSRF policy on redirects.

Typed denial receipt

Return a policy denial with raw URL, normalized host, resolved IP class, rule id, blocked credential lane, and recovery hint instead of a generic network failure.

Denied neighbors

Pair every allowed URL with the target class that must fail closed.

Cloud metadata

Examples: 169.254.169.254, metadata.google.internal, instance-data, IMDS-style aliases

Expected: Deny before request; receipt names metadata/link-local policy and credential lane protected.

Loopback

Examples: 127.0.0.1, ::1, localhost, decimal/hex/octal host encodings

Expected: Deny before request; receipt shows normalized host and loopback classification.

Private network

Examples: 10.0.0.0/8, 172.16/12, 192.168/16, fd00::/8, Kubernetes service ranges

Expected: Deny unless a specific internal route card authorizes that target for the caller and tenant.

Redirect into private target

Examples: Public URL returning 30x to metadata, loopback, or RFC1918 address

Expected: Re-run DNS/IP policy on every hop and deny with redirect hop preserved in trace.

Developer-local escape hatch

Examples: host.docker.internal, localhost, 127.0.0.1, ::1 in local MCP development

Expected: Deny by default; allow only when local/dev mode is asserted by deployment config and the pre-DNS host token is in the known-local set.

Trace evidence

The receipt has to prove what did not happen.

Fetch SSRF protection is only operator-grade if the denial is reconstructable. Store enough evidence to show the target was classified and blocked before any credential, proxy, cookie, or cloud role was exposed.

caller / tenant / workspace

tool route and endpoint family

raw URL and normalized URL

normalized host and port

DNS answers and selected address

IP class and policy rule

redirect chain, redirect hop index, and final target

credential lane or server role protected

quota / budget owner

policy decision and typed denial code

response size / timeout / retry envelope

receipt id and recovery hint

Internal exception card

Internal network access is a different route, not a checkbox.

Some agents legitimately need to reach internal services. That should never be granted by weakening public fetch policy. Give the internal lane its own route card, review owner, target scope, credential lane, and expiration.

Internal target / CIDR:
Caller / tenant / workspace allowed:
Business purpose:
Credential lane exposed:
Quota owner / retry ceiling:
Review owner:
Allowed methods and response size:
Forbidden neighboring targets:
Receipt fields:
Expiration / re-review date:

Local development exception

Developer-local is a deployment assertion, not a safe address class.

Docker and local MCP workflows often need `host.docker.internal` or loopback during development. Do not turn that into a broad private-network allow-list. Require an explicit local mode flag, match the pre-DNS host token from a tiny known-local set, and re-run policy on every redirect hop.

In shared deployments, even loopback is part of the attack surface: the agent is reaching the Letta/container host, not the developer's laptop. Keep localhost, 127.0.0.1, ::1, and host.docker.internal separate unless single-tenant deployment proof says otherwise.

Deployment mode flag:
Known-local host tokens:
Allowed port / scheme:
Single-tenant or shared deployment:
Redirect policy per hop:
Denied metadata / private / IPv6 controls:
Typed denial fields:
Positive fixture:
Negative fixtures:

Common misreads

Where SSRF defenses usually collapse.

Calling fetch read-only even though the request originates from a privileged cloud or developer host.

Checking the hostname string but not resolved IPs, CNAME chains, redirects, or IPv6 results.

Calling `host.docker.internal` an address-class allow-list instead of a deployment-mode assertion with a tiny pre-DNS host-token set.

Denying 169.254.169.254 while allowing metadata hostnames, loopback aliases, or private-service DNS.

Letting retries or fallback proxies reissue the request without the same policy bundle.

Logging only request failure instead of the policy decision that protected a credential lane.

Treating internal network access as a boolean feature instead of a separate reviewed route.

Related operator guides