MCP Security: SSRF Protection and Safe Outbound Calls

Connecting an MCP server means your platform makes outbound HTTP calls to a URL, and any system that fetches a user-influenced URL has a server-side request forgery (SSRF) risk that must be defended. Getting this right is part of what separates a safe agent platform from a dangerous one.

What SSRF is, briefly

Server-side request forgery happens when an attacker tricks a server into making a request to a destination the attacker chose — often an internal address the attacker couldn't reach directly. If a platform fetches a URL a user supplies without validation, an attacker might point it at internal metadata endpoints, private services, or localhost, turning the trusted server into a proxy into your network. For MCP, where users can register server URLs and the agent makes outbound calls, this is a real surface.

Why MCP touches this risk

MCP integrations are outbound by nature. When you connect a custom server, you give the platform a URL it will call. When the agent uses a tool, the platform makes the request. If that URL or its parameters can be influenced toward internal targets, you have an SSRF vector. The convenience of connecting arbitrary endpoints is exactly what creates the exposure, so the platform has to guard it.

The core defenses

Safe outbound calling rests on a few controls. First, validate and resolve the destination: block private and loopback address ranges, link-local and metadata addresses, and anything that resolves to an internal host. Second, do this after DNS resolution, not just on the raw string, to defeat hostnames that resolve to internal IPs. Third, restrict schemes to HTTPS and reject redirects to disallowed targets. Fourth, set tight timeouts and size limits so a malicious endpoint can't hang or flood the fetcher. Together these keep an outbound call from becoming a tunnel inward.

Defense in depth for agents

SSRF protection is one layer; it works alongside the others that make agent tools safe. Credentials for a server are stored encrypted and never logged. Tools are scoped to least privilege, so even a reachable system exposes only what you allowed. And mutating tools run behind write-confirm, so a human approves any action. No single control is sufficient — the safety comes from layering outbound validation, encryption, scoping, and approval.

What to ask a platform

If you're evaluating where to connect MCP servers, ask how outbound calls are guarded. Does it block internal address ranges after DNS resolution? Does it restrict schemes and redirects? Are credentials encrypted at rest? Are writes gated by approval? A platform that can answer those clearly is one that's thought about the threat. A platform that lets agents fetch arbitrary URLs with no guard is one to avoid.

Why this matters more for agents

It's worth being explicit about why SSRF deserves attention specifically in the agent era. Traditional web apps fetch URLs in narrow, well-understood places — an avatar import, a webhook. Agents change the shape of the problem: they make outbound calls dynamically, driven by a conversation and a set of connected servers, so the surface is broader and less predictable. A user can register a server URL; the agent decides at runtime to call a tool. That dynamism is the whole value of agents, but it means the outbound path can't be an afterthought. A platform that treats SSRF as a first-class concern — validating every destination on every call — is one built for how agents actually behave, not how last decade's apps did.

Getting started

AIML.chat applies outbound URL validation, encrypted credential storage, least-privilege scoping, and write-confirm to every MCP connection. Start on the free plan, compare tiers on the pricing page, and read MCP authentication for the credential side.