How to Secure MCP Servers for Enterprise Use

An enterprise MCP server is not secure merely because it is inside a private network. MCP turns tools into a programmable interface, and an agent can invoke that interface faster and more broadly than a person. The server must establish who the client is, what resource the token targets, which tools are currently allowed, and which credential may be used upstream.

Axec places an authorization and credential-governance layer between client Applications and upstream systems. Its MCP gateway exposes only approved authority while keeping the Application identity, upstream Connection, Connector contract, and user Grant separate.

Define the Trust Boundaries

Start by documenting four boundaries:

Network location is useful defense in depth, but it cannot answer these questions. Shared API keys are similarly weak because they blur client attribution, user delegation, and upstream credential ownership.

Use Resource-Bound OAuth

A protected MCP resource should publish metadata and challenge unauthenticated clients according to the MCP authorization profile. The client can then discover the authorization server, establish its client identity, and complete Authorization Code with S256 PKCE.

For Axec’s stateless Streamable HTTP transport, a request has this shape:

POST /g/finance-assistant/mcp HTTP/1.1
Host: axec.example
Authorization: Bearer eyJ...
Accept: application/json, text/event-stream
Content-Type: application/json
MCP-Protocol-Version: 2025-06-18

{"jsonrpc":"2.0","id":17,"method":"tools/call","params":{"name":"list_invoices","arguments":{"status":"open"}}}

Validate the bearer signature, issuer, audience, expiry, gateway identity, and principal kind. The authorization request and token redemption should carry the exact Resource Indicator. Reject a token minted for another gateway even if its signature is valid.

Client registration is not resource authorization. Dynamic Client Registration can establish a public PKCE Application, but it must not attach Connectors, create a user Connection, or grant tool authority.

Separate Discovery from Authorization

MCP capability discovery tells a client which tools a server can describe. It does not prove the caller may invoke all of them. Build the visible catalog as an intersection:

effective tools = active connector contract
                ∩ administrator attachment ceiling
                ∩ user-consented grant
                ∩ current credential capabilities

In Axec, Connector and authorization digests make contract changes visible. A prior Grant is not silently treated as approval when the effective contract changes. Reconnecting an upstream account also creates a new Connection identity, so existing Grants cannot drift onto replacement credentials.

Keep Credentials Behind the Gateway

An MCP client generally needs authority to perform an operation, not possession of the upstream token. Store OAuth tokens, API keys, and basic-auth payloads encrypted and return only safe metadata through management surfaces. Select and decrypt the credential only during an authorized execution.

Distinguish credential ownership:

• A Connection belongs to one user and one Connector.
• A Vaulted Credential belongs to the workspace and may be used only through an approved attachment and Grant or eligible Application-principal flow.
• An Application Credential authenticates the downstream client to Axec and is never an upstream credential.

This distinction limits credential sprawl and makes revocation understandable.

Recheck Authority on Every Request

Long-lived agent sessions make issue-time-only authorization unsafe. On each MCP request, reload the live status of the tenant, principal, Application, Application Credential, gateway, Grant, attachment, Connector contract, and selected credential source. Apply request-size limits before parsing and capability checks before upstream execution.

A signed bearer can remain compact while the database remains authoritative. This allows revocation or configuration changes to take effect before token expiry. It also supports tool-decision evidence that records allow or deny, reason, evaluator version, and an outcome correlation without logging secrets.

Practical Deployment Checklist

Protocol controls

• Prefer stateless Streamable HTTP for new integrations.
• Require TLS, strict host handling, bounded request bodies, and explicit protocol versions.
• Validate OAuth issuer, audience, Resource Indicator, PKCE, redirect URI, and client lifecycle.
• Disable unsupported transports rather than leaving ambiguous fallbacks exposed.

Authority controls

• Attach only required Connectors and capabilities to each gateway.
• Prefer session grants and selected providers for interactive workflows.
• Revalidate consent snapshots before creating durable Grants.
• Revoke locally before attempting best-effort upstream token revocation.

Operational controls

• Separate allow/deny decisions from upstream outcomes.
• Alert on refresh-token reuse, repeated denied tool calls, and revoked-credential use.
• Rotate Application and workspace credentials without mutating their historical identity.
• Test revocation while an agent is active, not only during login.

Security Caveats

Tool authorization does not validate tool arguments. Add schema validation and domain constraints for recipients, repository names, paths, monetary values, and destructive flags. Prompt injection remains relevant because malicious content can steer an agent toward an already-authorized capability. Use human confirmation or a narrower purpose-built tool for irreversible operations.

Do not claim group-based access unless it is actually enforced. Axec’s current workspace groups are directory facts, not Application or MCP authority. Application-principal tokens also cannot use user Connections; headless automation must use the Application’s own eligible vaulted or no-auth attachments.

FAQ

Can a reverse proxy authenticate the MCP server?

It can authenticate transport clients, but MCP still needs resource- and capability-aware authorization. Preserve a cryptographically verifiable Application identity rather than trusting an unvalidated forwarded header.

Should an MCP server return upstream access tokens?

Usually no. Execute through the governed gateway when possible. Token delivery expands the trust boundary and weakens runtime revocation and argument-level control.

Is a tool allowlist enough?

No. It is necessary but must be tied to a principal, resource, credential source, consent or workload authority, and current dependency status.

Primary References

• Model Context Protocol: Authorization
• OAuth 2.0 Protected Resource Metadata (RFC 9728)
• OAuth 2.0 Authorization Server Metadata (RFC 8414)
• Resource Indicators for OAuth 2.0 (RFC 8707)