They can. One hosted agent firewall documents that it applies only to processes the agent starts through its shell tool, and does not directly cover MCP server processes. Another platform lists connector traffic among traffic that does not follow the environment's domain list. Check how your platform treats MCP traffic before you rely on an egress rule.
Why MCP changes the picture
An MCP server gives an agent tools: read a ticket, query a database, post a message. Each server is a program or a remote service with its own network access and credentials. If the sandbox firewall governs only commands the agent runs directly, a tool call can still reach the network through the MCP server.
That does not make MCP unsafe by itself. It means the set of places an agent can reach is the sum of the sandbox network policy and everything its tools can reach.
What the vendors document
| Platform behavior | Source says |
|---|---|
| Firewall coverage | Applies to processes started through the agent's shell tool, and does not directly cover MCP server processes or setup steps |
| Egress allowlist | Excludes some traffic, such as GitHub proxy traffic and MCP connector traffic, which follow separate rules |
| Disabled network | The model API connection still exists |
The details differ across products, so treat the table as a prompt to ask your own vendor.
How to inventory the gap
- List every MCP server and connector available to the agent, local and remote.
- For each, write down the hosts it can reach and the credential it uses.
- Mark which ones the sandbox firewall governs and which it does not.
- For ungoverned ones, apply controls at the server: read-only scopes, per-tool permissions, and a narrow token.
- Re-run the inventory when a tool list changes, since tools can be added after approval.
Controls that work at the tool layer
OWASP's excessive agency guidance maps well here. Minimize the extensions available and the functions within each, avoid open ended tools like arbitrary URL fetch, grant downstream permissions at the least privilege needed, and require human approval for high-impact actions. Authorization should be enforced in the downstream system, not left to the model.
A short list for MCP in a sandbox:
- Prefer servers with read-only tools for read-only tasks.
- Do not allow a general fetch or shell tool alongside private data.
- Pin the server version and review changes.
- Log each tool call with arguments and result status.
- Keep the credential specific to the server and the task.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for where a server is registered and which tools and scopes it exposes.
Worked example: an inventory table for one agent
An illustrative inventory for an agent that handles bug triage.
| Server | Tools | Reaches | Credential | Inside sandbox firewall? | Control |
|---|---|---|---|---|---|
| Ticket server | Read ticket, add comment | Ticket SaaS | Token scoped to one project | Unknown, ask vendor | Disable add comment unless needed |
| Docs server | Search docs | Internal wiki | Read only token | Unknown | Keep read only |
| Database server | Run query | Staging database | Read only role | No, local process | Restrict to views, log queries |
| Fetch server | Fetch URL | Anywhere | None | Maybe | Remove or restrict to allowlisted hosts |
Two things stand out. The fetch tool is an open ended extension of the kind OWASP advises avoiding, because it can reach arbitrary URLs. And the comment tool is a write path that can carry data out. Removing or narrowing those two reduces risk more than any change to the sandbox firewall.
Steps to bring MCP under control
- Register every server. Keep a list with an owner, purpose, version, host, and credential.
- Classify tools. Mark each as read, write, send, or delete. Reads of private data and sends to the outside are the combination to separate.
- Disable what the task does not need. An unused tool is attack surface.
- Scope credentials per server. One token per server, per task.
- Pin versions. A server that changes its tool list silently is a drift risk, so review changes.
- Log calls. Record tool name, arguments, and result status.
- Require approval for high impact tools. Deleting, sending, and deploying should have a person in the loop.
- Test with hostile input. Put an instruction in a ticket body and see whether the agent acts on it.
Local versus remote servers
A local server runs as a process in the sandbox. It shares the network namespace, so network rules cover it only if the policy applies to that process. A remote server is a service the agent calls over the network. Its own authorization is what protects your data. Each kind needs different controls, and neither is covered by a rule written for the other.
Reading vendor statements
When a vendor says the firewall protects the agent, ask which processes it covers, whether tool traffic is included, whether setup steps are included, and how the platform treats connector traffic. The documentation we reviewed is candid about these limits. Use that candor to ask better questions.
What good looks like
An agent with three narrow, read only tools, scoped tokens, logged calls, human approval for any send or delete, and an inventory that matches reality. That is a design you can describe to a customer without hedging.
Where Safeguard fits
Safeguard's MCP Guardrail and agent identity features are built for this layer. They help you see which MCP servers agents use and control which tools they may call.
Quick check
Is a sandbox firewall enough when MCP tools are enabled?
Not on its own. Confirm whether it covers MCP traffic, and add tool level permissions.
Should every MCP server be blocked in a sandbox?
No. Allow the ones the task needs, with narrow scopes, and log their use.
Should we ban general purpose fetch tools in sandboxes?
For tasks that touch private data, yes in most cases. Where the task needs web access, restrict it to named documentation hosts and keep private data out of that agent's reach.
Sources
- Customize the Copilot cloud agent firewall (GitHub Docs)
- Configure cloud environments (Anthropic documentation)
- Use Claude Code in the cloud (Anthropic documentation)
- OWASP LLM06:2025 Excessive Agency
Last reviewed: 19 October 2026.
