Vaulting a credential stops an agent from reading it. It does not stop a compromised MCP server from taking the data it legitimately fetched and sending it somewhere else. Those are different problems, and the second one is not solved by encryption.

Each managed server has a list of hosts it may reach. Anything else is refused.

An empty list is a real state, not a misconfiguration to warn about. A server that has not been told where it may go does not go anywhere.

The obvious way to build this is a check inside the server: before making a request, consult the list. That works right up until the moment it matters. If an attacker controls the process, they control every check inside it — they open a socket and your allowlist is a comment.

So the list is enforced at a proxy the container does not control, and the container runs with no direct route to the internet. The proxy is the only way out. A server that ignores its configuration does not get further than one that respects it.

Blocked attempts are recorded with the host, port and reason. This is the part teams actually use day to day: a destination appearing there that should be permitted is simply one you have not added yet, and the log tells you rather than leaving you to guess from a timeout.

It also means an exfiltration attempt looks like something. A silent block and a working integration are indistinguishable from the outside; a block you can read is evidence.

Allowlists apply at deploy time. Add a host, redeploy the server, and the panel moves from "not yet enforced" to enforced. The delay is deliberate — outbound policy changing under a running server without a deploy would make the audit trail harder to reason about, not easier.

Servers you host yourself are outside this boundary. Statio still governs who may call them and with which credential, but where your own infrastructure sends traffic is yours to control.