A security review that starts at tools/call can start too late. Before a model invokes a tool, the client may fetch server metadata, discover authorization endpoints, open a browser URL, install a package, or launch a local server. Each step crosses a security boundary independently of the model's final choice.
This matters for both inventory scanners and interactive clients. A read-only discovery feature may still make outbound requests or start processes. Read-only describes the intended API permission; it does not automatically describe the collector's network reach or host privileges.
Two paths, two threat models
In the remote path, an MCP client contacts a server and follows metadata needed to establish the connection. A malicious endpoint may influence subsequent fetch targets. In the local path, a client reads configuration that identifies a command or package to execute on the host. A malicious configuration or dependency can influence the process that starts.
The MCP security guidance discusses both SSRF during OAuth-related metadata discovery and local MCP server compromise [1]. The first is about a network-capable component reaching unintended services. The second is about code running with the privileges granted to a local process. A single tool-content scanner cannot be assumed to cover either boundary.
Our analysis focuses on the preconditions defenders should record and the tests that can establish whether a particular implementation constrains these paths. It does not imply that using remote metadata or local servers is inherently insecure.
Remote metadata: validate the destination actually reached
Assume a server can supply a metadata URL that a backend client fetches. If the fetcher can reach internal networks, an attacker-controlled URL can potentially redirect the request toward an unintended service. Whether data is exposed depends on the method, response handling, network access, and target behavior.
Validate schemes, hosts, addresses, and redirects according to a deliberate egress policy. The deployment may legitimately use internal MCP services, so a universal private-address ban can break intended architecture. Define permitted internal destinations explicitly and prevent arbitrary external servers from expanding that set.
Account for DNS changes between validation and connection. A check performed against one resolution does not necessarily constrain a later connection using another. Use a hardened network layer or egress proxy that enforces the destination at connection time. Avoid hand-built URL and IP parsing where established libraries can handle normalization consistently.
Redirects and responses are part of the boundary
Apply the same destination policy to every redirect hop. A public URL that redirects to a restricted address should not inherit permission from its first hop. Bound redirect count, response size, time, and supported content types to reduce resource-exhaustion and parser risks.
Do not reflect detailed internal responses into user-visible errors or model context. An unsuccessful authorization attempt can still disclose service banners, internal hostnames, or response content if the error handling is too verbose. Keep operator diagnostics protected and return a safe correlation identifier to ordinary callers.
Keep credentials scoped to their intended origin and purpose. Metadata fetches should not automatically receive the customer's provider token or arbitrary headers copied from the initiating request. A connection workflow should be explicit about which component sends which credential to which endpoint.
| Surface | Attacker influence | Control to verify |
|---|---|---|
| Metadata URL | Initial fetch target | Scheme and destination policy |
| Redirect chain | Subsequent target | Per-hop and connection-time validation |
| Authorization URL | Browser or opener input | Safe schemes and non-shell opening |
| Local launch configuration | Executable and arguments | Explicit trust, package pin, sandbox |
Local launch is code execution
A local MCP configuration can name a package runner, executable, arguments, working directory, and environment. Approving that configuration is approving a process with those capabilities. The transport label does not make the executable trustworthy or limit what its startup code does.
Show the complete command and material environment access before activation. Resolve package identity and version under a reviewable policy. Avoid automatically launching a newly discovered server simply to enumerate its tools; static inventory and active execution should be separate operations.
Run the process with the smallest filesystem and network access the integration needs. Do not pass the entire parent environment by default when it contains unrelated cloud or developer credentials. Treat privileged sockets, home-directory mounts, and host-administration permissions as material expansions of authority.
Browser-to-process transitions deserve separate review
A client may open an authorization URL or communicate with a local proxy that can spawn processes. Those are distinct privileges. Validate URL schemes and use a platform API that does not interpret the URL as shell code. A malicious endpoint should not gain command execution through the convenience function used to open a browser.
Protect local proxy interfaces with authentication and appropriate origin and network restrictions for the implementation. Loopback binding reduces exposure but is not a complete statement about access from browsers or other local processes. Avoid presenting a local service as safe solely because it is not internet-facing.
If a proxy can launch arbitrary configured processes, compromise of that proxy can have host-level consequences. Restrict its privileges and the allowed launch surface. A process sandbox can reduce blast radius, but its actual mounts and network exceptions must be examined.
Proposed safe validation procedure
Use an isolated test network with controlled public-like, private, redirect, and blocked endpoints. Verify that the discovery client reaches only permitted targets and that blocked response content never appears in the model context or ordinary error response. Include IPv6 and normalized-address cases handled by the chosen networking library.
For local launch, use a harmless fixture process that records its arguments, visible environment names, filesystem access, and attempted connection to a controlled sink. Confirm that unapproved configuration is not executed, the approved command matches what the reviewer saw, and denied resources remain inaccessible.
Do not run unknown packages on an analyst workstation to test whether they are safe. The proposed procedure validates the launch boundary using inert fixtures. Package reputation and vulnerability checks are additional evidence, not permission to execute an untrusted binary with broad host access.
The practical priority
Inventory the work performed before the first tool call and assign each operation an owner and a boundary. Test metadata networking, credential forwarding, URL opening, and process launch independently. A secure tools/call gate remains valuable, but it can only govern actions that reach it. Connection establishment must not become an unexamined route around that gate.