An MCP server is code running on infrastructure. By default, that code can connect to any IP address or domain on the internet — including yours.
Start for free → | Setup guide →
When people think about MCP security risks, they think about what comes in: malicious tool responses, prompt injection, supply chain attacks. That's the right instinct, but it's only half the picture.
The other half is what goes out.
An MCP server running inside a container — whether on your infrastructure or a managed platform — has outbound network access by default. It can open a connection to any domain, any IP, on any port. If that server is compromised or malicious, it can use that network access to exfiltrate everything it touches: environment variables, secrets, data passed through tool calls, credentials it has been given.
Default-deny egress closes that door.
The Exfiltration Attack Model
The attack is straightforward. A compromised or malicious MCP server:
- Receives data through a tool call — secrets injected into the environment, a user's query, a database response, an API credential
- Opens an outbound connection to an attacker-controlled endpoint
- Sends the data out
The entire attack happens at the network layer. No exploit chain, no persistence mechanism. Just an HTTP POST to a domain the attacker controls.
This isn't theoretical. The Smithery.ai breach — documented by GitGuardian — demonstrated credential exfiltration from a path traversal vulnerability that exposed API keys from thousands of MCP servers. Default-deny egress would not have prevented the initial path traversal, but it would have blocked the outbound call that extracted the credentials. The blast radius shrinks dramatically when the server can't reach arbitrary endpoints.
What "Default-Deny" Actually Means
Standard Docker containers have unrestricted outbound network access. There is no egress configuration by default — a container can connect anywhere. Most MCP server management tools and hosting platforms do not change this. They isolate the container from the host but leave outbound traffic open.
Default-deny egress inverts the model:
- All outbound connections are blocked unless explicitly allowed
- The allowlist is declared at deploy time — not modifiable at runtime
- Connections to undeclared destinations are dropped at the network layer, independent of what the server code does
This means a server that has been fully compromised — where an attacker has arbitrary code execution — still cannot reach an exfiltration endpoint that wasn't declared before the server started. The attacker controls the code but not the network rules.
How mistaike.ai Implements Egress Control
On mistaike.ai, egress enforcement runs through an Envoy proxy that sits between the container and the external network. When you deploy an MCP server, you declare the FQDNs it needs to reach (max 10, no wildcards, no raw IP addresses). The proxy enforces this list; everything else is dropped.
The constraints exist for security reasons:
-
No wildcards —
*.example.comallows too broad a surface, including subdomains you don't control - No IP addresses — raw IP allowlisting bypasses DNS-based controls and is difficult to audit
- Max 10 FQDNs — keeps the allowlist reviewable; a server that needs more than 10 external endpoints is doing more than one thing and should be decomposed
The enforcement happens before traffic leaves the container. It is not firewall rules applied at the host level after the fact — it is the proxy layer that mediates every outbound connection.
This Is One Layer, Not a Complete Defence
Default-deny egress addresses one specific attack vector: uncontrolled exfiltration via outbound network access. It does not:
- Prevent the initial compromise
- Stop data from being included in declared outbound traffic (to an allowed domain)
- Replace DLP scanning
This is why mistaike.ai's sandbox combines egress control with DLP scanning and kernel-level isolation. Each layer addresses different failure modes:
- gVisor (kernel isolation) — limits what system calls the server can make, containing privilege escalation
- Default-deny egress — blocks exfiltration to undeclared endpoints regardless of what the server code does
- DLP scanning — inspects the content of traffic on declared paths, catching credential and PII leakage through legitimate channels
An attacker who compromises a server faces all three controls simultaneously. Bypassing one doesn't make the others irrelevant.
DLP alone is insufficient if the server can reach arbitrary endpoints — you'd have to scan every outbound byte to every possible destination. Egress control reduces the problem to scanning traffic on a declared set of paths. Combined, they catch different parts of the same attack.
What to Look for When Evaluating MCP Hosting
Egress control is not complex to implement, but it requires deliberate design. A platform that has thought seriously about MCP server security will be able to answer:
- What is the default egress policy for hosted servers?
- At what layer is egress enforced? (Application-level filtering is weaker than network-layer enforcement)
- Can servers modify their own egress rules at runtime?
- Is the allowlist declared at deploy time and immutable during execution?
- What happens to outbound connections to undeclared destinations?
If a platform can't answer these questions clearly, the answer is probably "unrestricted outbound."
Egress Control on mistaike.ai
Managed MCP hosting on mistaike.ai includes default-deny egress on every server, every plan. You declare the FQDNs your server needs at deploy time. Everything else is blocked.
This sits alongside sandboxed builds, envelope-encrypted secrets, kernel-level isolation, DLP scanning, and CVE pattern matching — the full architecture is at /security/sandbox.
If you're evaluating MCP hosting and want to understand what's in each layer, the CVE registry shows the patterns we track and update daily.
Start free → | Full pricing → | Setup guide →
Nick Stocks is the founder of mistaike.ai.
Originally published on mistaike.ai
Top comments (0)