The One Rule That Matters Most
Only calls routed through MCP Boundary are checked.
If your agent still has a direct MCP entry for the downstream server, that direct path bypasses the boundary and is not seen, checked, or recorded.
What MCP Boundary Is Not
- a hosted gateway or cloud service
- a multi-tenant gateway
- a replacement for your MCP server
- a sandbox for arbitrary downstream server internals
- a remote approval service or generic run-anyway console
- a dashboard tool runner; approval and execution are separate steps
What It Does Not Claim
- production-grade security
- data-loss-prevention guarantees
- prompt-injection protection
- universal provider support
- safe-by-default sending or deletion
- full Google Workspace / Gmail / Outlook / GitHub / database support
- a guarantee that email, databases, GitHub, browsers, or files are safe
What It Cannot Automatically See
- a direct agent connection to the original MCP server when both entries are active
- downstream internal effects hidden behind one outer tool
- provider-side automations that run after the MCP server returns
- retries that may duplicate an uncertain side effect
Human Approval Limits
Human approval is local and beta. Pending approvals and approvals live with the running Boundary process. The dashboard can approve or reject when configured with the operator token, but it does not run the tool. The agent must retry with approval_retry metadata before approved work can execute. See the concrete retry shape in the FAQ.
How Claims Are Made
When a path is verified, it is documented as exactly that path — with the server, auth model, tool, and limitation named. A successful test of one tool does not become a broad provider-support claim.
For the exact evidence standard and what has actually been tested, see Tested Servers And Limits.