Secure MCP Integrations: OAuth Is Only the Beginning

MCP makes tools easier to discover and connect, but interoperability does not remove the need for authorization design. A client, resource server, and authorization server each have distinct responsibilities, and shortcuts between them create exactly the token leakage and confused-deputy problems standards are meant to prevent.

Bind every token to its resource

A token issued for one service should not be accepted by another. Validate issuer, audience, expiry, scopes, and the intended resource on every request. Never pass a client token through to an unrelated downstream API.

• Use OAuth 2.1 flows appropriate to the client type
• Request the narrowest scopes required for the current job
• Store tokens outside model-visible context and redact them from traces
• Validate tool arguments server-side even when the model produced them
• Separate user consent from the agent’s decision to call a tool

Authorization is not tool policy

A valid token proves the caller may access a capability; it does not prove every invocation is appropriate. Add application policy for dangerous parameters, rate limits, data classification, approval thresholds, and tenant boundaries.

Make the audit trail legible

Record who authorized access, which scopes were used, what tool was called, which validated arguments reached the server, and what changed. Logs should support investigation without capturing secrets or unnecessary personal data.