Five questions to answer before you put MCP in production

Description and use

Deploying MCP in a multi‑tenant environment requires strict access control, secure secret handling, outbound traffic restrictions, audit logging, and replayable tool calls.

Problem

Deploying an MCP (Model Control Plane) server in a multi‑tenant environment raises security, credential, egress, audit, and replay concerns that are not addressed by the default MCP implementation.

Outcome

By treating MCP as a namespaced plugin, enforcing secret‑only credentials, applying a strict egress policy, and recording detailed audit logs and metrics, the organization safely moved MCP to production while maintaining security, observability, and replayability.

Workflow

• 1. Configure MCP as a plugin artifact with namespaced tool references (mcp_tool:{server}:{tool}).
• 2. Replace plaintext auth with secret_id references; only bearer, api_key, and oauth2 (client_credentials) are supported.
• 3. Enable SOIT’s egress policy: set enable_egress_policy=True, define domain allowlists/blocklists, and enforce global IP checks after DNS resolution.
• 4. Configure the HTTPX client to use an event hook that authorizes every outbound request and disables automatic redirects.
• 5. Persist each tool call as a run step, recording gateway audit logs, step metrics, cost entries, and OpenTelemetry spans.
• 6. Assign an idempotency key to each tool call (default tool:{run_id}:{tool_call_id}) to allow safe replay and caching.
• 7. Verify that all security questions are answered and document the configuration in the SOIT repository.

Evidence

SOIT rejects this outright. _build_auth_headers checks for a token or value field in the auth config and raises: MCP credentials must use secret_id

Source

SOIT’s egress policy is deny‑by‑default, in three layers.

Source

SOIT persists each tool call as a step of a run, and writes two pieces of evidence per call: Gateway audit and Step metrics.

Source