How to Run MCP Servers as Privileged Workloads

At a Glance

Why This Matters

The default MCP server is a process with a tool list and a secret in the environment. That is enough to demo. It is not enough to operate.

When that process can read a database, open a change ticket, or call an internal API, it is a privileged workload. The host that runs it (a VM, a container, a Kubernetes cluster, or a managed runtime) is a placement decision. Placement is not a security model.

Maya’s pillar piece, MCP for Platform Engineers, names the protocol. This guide is the operator half: identity, authorization, secrets, network, audit, and how the thing fails.

A Privileged Workload, Not a Plugin

MCP defines hosts, clients, and servers over JSON-RPC. The server is a separate process that exposes tools, resources, and prompts. It often holds credentials the calling model never sees.

Treat that process like any other privileged worker:

An agent host with an MCP client sits apart from an MCP server that holds credentials and tools. Downstream APIs sit behind the server. A separate band lists operator controls: identity, secrets, network, and audit. Host placement is labeled as VM, container, Kubernetes, or managed.

ExpandDownload SVG

PS-D-0005

Download SVGClose

Kubernetes is one legal answer to “where does the process run.” It is not the only one, and it is not in scope as a default here. The same five controls apply on a VM, a container host, or a vendor runtime.

Identity and Authorization

Do not confuse three identities:

1. User / initiator: the person or service that started the agent run.
2. Host: the application that embeds the MCP client and decides which servers to attach.
3. Server: the process that actually holds downstream credentials and executes tools.

If the server token can do more than the host will allow the model to request, the effective policy is the server token.

MCP authorization is optional.[1] When you use HTTP-based transports and you do implement authorization, the spec expects OAuth at the transport. When you use STDIO, the spec says you should not follow that HTTP authorization flow and should take credentials from the environment instead. That is a feature of local wiring. It is also how secrets leak into every child process that inherits the environment.

MCP security guidance forbids token passthrough: a server must not accept tokens that were not issued for that MCP server and forward them to a downstream API.[2] Passthrough breaks audience checks, audit, and the trust boundary between client, server, and API.

Approve a server only with a named owner and a named principal. Shared “platform MCP” identities are how one compromised tool catalog becomes every team’s incident.

Secrets and Network

Store server secrets in the secret system you already trust for production workloads. Do not keep long-lived tokens in repo files, chat logs, or unscoped environment blocks copied between hosts.

Rotate on a schedule you can prove. When a tool is retired, retire its credential. A dead tool with a live token is still a live path.

Network is a blast-radius control, not a Kubernetes feature. Wherever the process runs, ask:

• Which destinations can this server reach?
• Which callers can reach this server?
• What happens if it is placed in prod with a staging credential, or the reverse?

Security groups, host firewalls, service mesh policy, and Kubernetes NetworkPolicy are different mechanisms for the same job. Pick the one that exists on this host. Do not wait for a cluster to start bounding egress.

Start read-only. Write tools need an extra approval. Tools that take a URL or a host name need an allow-list, or you have handed the model an SSRF primitive.

Audit

You need a line you can find at 2 AM:

request id → host → server identity → tool name → downstream call → result

If the host and the server do not share a correlation id, you will reconstruct the incident from two log piles and a guess.

Log denials, timeouts, and partial success. A tool that returns “ok” after writing one of three records is a failure mode, not a green span.

The protocol cannot enforce its own security principles. Consent, authorization, and access control are implementor work. If those controls are only in the prompt, they are not controls.

Failure Modes

These show up before architecture diagrams do.

Server token outlives host policy. The host stops offering a tool. The server credential still can.

Environment inheritance. STDIO and poorly isolated containers pass parent secrets to the server. The tool allow-list never sees them.

Token passthrough. The server forwards a client token downstream. Downstream logs name the wrong caller. Rate limits and audience checks no longer apply to the server.

Uncorrelated traces. The host has a run id. The server has a request log. On-call has neither.

Timeouts with side effects. The client times out. The downstream write commits. Retry without idempotency keys doubles the change.

Shared super-server. One process, many teams, one credential. Isolation is a spreadsheet.

Host as talisman. “It runs on Kubernetes” or “it runs in our VPC” used as a substitute for identity and audit.

None of these require a fabricated incident. They are the ordinary shape of privileged processes.

Approval checklist

Before a production host may attach the server:

If a row is “we will get to it after we pick Kubernetes,” the server is not approved.

Recommendation

Platform Signal recommendation

Treat every MCP server as a privileged workload. Bind a named identity, bound network, rotated secret, and a trace you can follow, then pick a host.

Use when

• A server will hold credentials to internal APIs, data, or change systems
• You can name owner, principal, allow-list, and failure behavior
• You are ready to start read-only and expand on purpose

Wait when

• The only control is prompt text
• STDIO is shipping production secrets through inherited environment
• You cannot show a denied or timed-out tool call in a trace
• “We will put it on Kubernetes” is doing the work of identity and audit