MCP security: what actually protects your data

Authentication: OAuth 2.1, or a bearer token

Remote MCP servers authenticate in one of two ways, and the difference matters for who is accountable for a call.

With OAuth, the client discovers the server's authorization metadata, registers itself, sends the user through a sign-in and consent screen, and receives a token bound to that user. With a bearer token, you generate a credential in the server's own interface and paste it into the client's connector settings. OAuth ties actions to a person; a shared bearer token ties them to whoever holds it.

• Authorization server metadata at a well-known endpoint, so clients can self-configure
• Protected resource metadata, so an unauthenticated request returns a pointer to the auth server rather than a bare 401
• PKCE, so an intercepted authorization code cannot be exchanged by anyone else
• Dynamic client registration, so a client can register without a human creating credentials by hand
• Short-lived authorization codes that can only be exchanged once

Zylx implements all five. Its MCP endpoint answers an unauthenticated request with a WWW-Authenticate header pointing at its protected-resource metadata, advertises the authorization-code grant with PKCE S256, and exposes registration and revocation endpoints. Both are publicly inspectable at zylx.studio/.well-known/oauth-authorization-server.

The consent step is a security control, not a formality

A subtle and serious failure mode in OAuth-secured MCP servers: if the authorization endpoint issues a code on a bare GET request from an already-signed-in user, a crafted link can cause a live authorization code to be delivered to an attacker-controlled redirect URI. The user never knowingly approved anything. The result is account takeover through a link.

The fix is to bind every issued code to an explicit, freshly authenticated approval — a signed, short-lived consent artefact that ties the exact grant parameters to the approving user, verified before a code is ever issued. If you are evaluating a server, ask whether authorization requires a real approval action, and whether authorization codes are single-use with an atomic exchange. Both are cheap to implement and expensive to omit.

Scopes: the difference between reading and doing

A token should not be a blanket key. The useful pattern is a capability scope that the server enforces at call time, so a read-only credential is refused when it attempts a write-class tool — and refused with a message naming the missing scope, rather than failing in a way that looks like a bug.

Equally important is what the default grant is. A server that quietly issues write capability on first connection has made a decision on your behalf. Write should require explicit request and explicit approval.

Zylx enforces scopes centrally in the tool-call path rather than inside individual tools, so a tool that skips the usual approval layer cannot become a scope-blind hole. OAuth connections are read-capable by default; write is granted only when a client explicitly requests it and the user approves it on the consent screen.

Tenant isolation has to fail closed

Where a server holds data for multiple workspaces, brands or clients, the highest-consequence failure is not a wrong answer — it is one tenant's data surfacing in another's session. This class of bug does not look like an error; it looks like a helpful response.

The rule worth insisting on: if a tool call names a workspace the credential is not authorized for, the call must be refused, not silently honoured or quietly redirected. Prompt-level instructions such as "only use Brand A data" are not an access control.

Ask for the tool-surface census

The single most revealing question you can ask a vendor is what proportion of their tools can change something. A server that cannot answer has not thought about it. Below is Zylx's own catalogue, classified by what each tool does to the workspace, as the server reported it on 9 August 2026.

The shape matters more than the totals: roughly three quarters of the surface cannot change anything, the next largest group only writes proposals, and the tools that touch live systems are gated twice — by scope, and by human approval.

Prompt injection is the risk the protocol cannot fix

When a tool returns content from an outside source — a support ticket, a product review, a web page, an email — that content can contain text aimed at the assistant rather than at you. A sufficiently persuasive instruction inside returned data can attempt to redirect what the assistant does next.

No authentication design prevents this, because the request is properly authorized; the problem is the content, not the caller. OpenAI has been explicit about the risk for connectors that can write, and Anthropic advises reviewing tool approvals rather than blanket-allowing them. The practical mitigation is architectural: keep consequential actions behind human approval so a successful injection produces a proposal somebody declines, not an executed change.

A 10-point checklist before you connect a server

• Does it support OAuth, or only a shared static token?
• Is authorization bound to an explicit approval, with single-use codes?
• What is the default scope on first connection — read, or write?
• Are scopes enforced centrally, or per tool?
• What proportion of tools can change something? Ask for the numbers.
• Do consequential actions require human approval, and can that be bypassed?
• Can the assistant approve its own proposals?
• Does a request naming another tenant get refused, or honoured?
• How do I revoke access, and does revocation take effect immediately?
• Do credentials expire on their own if I forget about them?

If a vendor cannot answer all ten in specifics, that is itself the finding. These questions are answerable in a paragraph by anyone who has built the thing properly.

Frequently asked questions