Credentials

An MCP server needs a credential for whatever it talks to. The question is who holds it. In Statio the answer is never the agent.

The guarantee

A credential you add to Statio:

• is encrypted at rest in the vault;
• is injected into the upstream request by the gateway at proxy time;
• is never returned by any API, to any caller, including you;
• is never sent to the agent, which receives only the upstream's response.

The practical consequence: a compromised agent cannot leak the credential, because it was never given it. It can only make the calls it was already permitted to make, and those are logged.

Adding one

Open a server, go to Credentials, and add the value the upstream expects. That is the last time it is visible. To change it, replace it; there is no read path.

Servers you connect with OAuth

Some catalog servers are hosted by the vendor and sign in with OAuth instead of an API key; Linear is the first. There is no key to paste:

1. Install the server from the catalog.
2. Press Connect, approve access on the vendor's own page, and you land back on the server.

The connection belongs to the organization: one person with permission to manage credentials connects it once, and every member and key that has been granted the server uses it. Statio registers itself with the vendor automatically, so there is no OAuth app for you to create.

The tokens follow the same guarantee as any credential: encrypted at rest, attached by the gateway, never returned and never sent to the agent. Statio refreshes them before they expire.

If the vendor revokes access, calls stop with a message saying the server needs reconnecting in Statio, and the server page shows Reconnect. Disconnect removes the connection and its tokens.

What the agent sees

Nothing. The agent sends a tool call to the gateway and gets the upstream's response. Headers carrying the credential are added after the permission check and are not visible in anything returned to the caller.

Egress control

A managed MCP server runs with no direct route to the internet. Its outbound traffic goes through a proxy that enforces an allowlist you set.

That matters because credential injection alone would not stop a compromised server from sending your data somewhere else. The allowlist is enforced outside the container, so it holds even when the server itself is doing something it should not.

• api.example.com allows exactly that host.
• *.example.com allows subdomains, and not example.com itself.
• An empty list means the server cannot reach anything.

Blocked attempts are recorded. A destination appearing there that should be allowed means it is missing from your list.