Guide

Secure MCP: building AI apps on tooling you can trust

The security of an AI app is rarely about the model. It is about what the toolsyou wire in can do on a user’s behalf — and whose permissions they carry. Get that wrong and a helpful assistant becomes an over-privileged one. Here is what to demand from secure MCP tooling, and how to verify it before you connect.

The real security question

MCP is the shared tool-calling standard across Claude, ChatGPT/OpenAI and the rest, so the risk surface is the same everywhere: a tool call runs with someone’s rights. The only questions that matter are whose and how much. A secure setup answers both precisely: this action runs as this user, with exactly the access that user already has, and nothing more. An insecure one answers vaguely — a shared key, a service account, “the app can do everything, we trust the agent.”

What to demand from secure AI-app tooling

Six properties, each of which you can check rather than take on faith:

1. OAuth 2.1, not a shared API key

Per-user tokens, least-privilege scopes, standard revocation, and an audit trail that names the real person. A shared API key is long-lived, coarse, and a broad blast radius when it leaks. See how MCP’s OAuth discovery works in practice.

2. No permission flattening

The single most common serious regression: tools behind one over-privileged service account, so every user’s agent inherits admin access to everything. Secure tooling propagates the real user’s identityso each app’s own permission model applies — the agent gets exactly the user’s rights, no more.

3. Verify before you trust

A sensitive tool should force an OAuth challenge, not trust the network. The whole chain is walkable without a token, so you can confirm a server’s posture before connecting. Don’t take a claim on faith — probe it.

4. Least-privilege, scope-filtered tools

The agent should only see and be able to call the tools its token scopes allow. A catalog that exposes every tool to every caller is both a security and a context problem.

5. Audit and central revocation

One line per call recording who did what, and a single revocation that cuts access everywhere at once. If you cannot answer “what did this agent do, and how do I stop it,” the tooling is not secure enough for real users.

6. Encrypted storage for linked third-party tokens

When a tool holds credentials to another service on a user’s behalf, those live encrypted and per-user — so the downstream provider sees the user’s own account, seat and limits, not a shared bot.

Do

  • +Front your tools with an OAuth 2.1 perimeter and propagate the real user identity.
  • +Scope the tool catalog to the token; expose only what the user may call.
  • +Log one audit line per call and wire central revocation.
  • +Verify a server’s OAuth and discovery chain before connecting.

Don’t

  • −Wire tools behind one broad service account ("permission flattening").
  • −Hand agents a long-lived shared API key for multi-user access.
  • −Trust a server because it says it is secure — probe it instead.
  • −Store third-party credentials in plaintext or share them across users.

Why MCP + a gateway is the secure pattern

Put the six properties together and you get a specific architecture: an OAuth-protected MCP layer in front of your apps that propagates identity to each one, filters tools by scope, and keeps the audit and revocation central. Because the layer enforces nothing itself — each app keeps its own permission model — there is nothing new to trust. That is exactly what Cortex Gatewayimplements: a self-hosted, open-source MCP gateway where the agent’s access equals the user’s, by construction. For the trust dimension specifically, see our earlier note on building AI apps on verifiable trust.

Verify it

Security you cannot check is a slogan. Run any domain through the agent-readiness checker: it walks the MCP OAuth challenge, the discovery chain and the crawler posture, and shows the curl behind every verdict — so you can confirm a tool is what it claims before you wire it into an AI app.

FAQ

What makes an MCP server or tool secure?

Three things you can verify: it authenticates the real user with OAuth 2.1 (not a shared API key), it never grants the agent more than that user already has (no permission flattening), and its whole trust chain is inspectable before you connect — a 401 OAuth challenge, protected-resource metadata, a real authorization server. If a tool asks for a broad API key and hands every agent the same access, that is the insecure pattern, whatever else it claims.

How do I build a secure ChatGPT or Claude AI app?

MCP is the shared tool-calling standard across Claude, ChatGPT/OpenAI and others, so the security question is the same for all of them: how does your app expose tools, and with whose permissions? Put an OAuth 2.1 perimeter in front of your tools, propagate the real user’s identity to each backend so its own permission model applies, scope the tool catalog to what the token allows, and log one audit line per call with central revocation. That is a secure AI-app baseline regardless of which assistant connects.

Are MCP servers safe to connect to?

A well-built one is: it should force an OAuth flow for anything sensitive rather than trust the network, and you should be able to walk its discovery chain token-less to confirm it. An open MCP server that exposes write tools with no authentication, or one that stores a shared credential granting broad access, is not safe. Verify before you connect — you can probe any domain’s MCP and OAuth posture without an account.

What is the biggest security mistake in AI-app tooling?

Permission flattening: wiring tools behind a single over-privileged service account, so every user’s agent inherits admin-level access to everything. It is convenient and it is the most common serious regression. The fix is identity propagation — the agent acts with the real user’s own rights, enforced by the app that owns the data, so there is nothing new to trust.

Should AI tools use OAuth or API keys?

OAuth 2.1 for anything multi-user or sensitive. API keys are long-lived, coarse, hard to attribute to a person, and painful to revoke; a leaked key is broad and durable access. OAuth gives per-user tokens, least-privilege scopes, standard revocation, and an audit trail that names the actual user. For a single-user local tool a key can be fine; for anything an assistant uses on behalf of many people, it is the wrong primitive.
Verify any of this on a real domain with the agent-readiness checker— every result line ships the curl that reproduces it. See the pattern shipped end-to-end in cortex-gateway.