Securing a company MCP server comes down to three questions, answered in order. Who can connect at all? That's OAuth. What can a connected client ever reach? That's workspace isolation. And of what's reachable, who sees which part? That's scoping — private versus public, and seats. Get all three right and "we exposed our company knowledge to AI clients" stops being a scary sentence. Miss one, and the other two don't save you.

Here is what each layer means in practice, and what to check on any platform that hosts an MCP server for you.

Layer 1: OAuth 2.1, to the current spec

MCP settled on OAuth 2.1 for authorization, and the word current is doing real work in that sentence. The spec has moved, and recent revisions closed real gaps. Two items are worth knowing by name even if you never implement them yourself.

Issuer validation (iss) means the client verifies that an authorization response actually came from the authorization server it started with. Without it, a malicious server can play man-in-the-middle games — so-called mix-up attacks — and walk away with a code meant for someone else. Boring, essential, and easy to skip if you hand-roll.

Client ID Metadata Documents (CIMD) are how clients identify themselves to your server. Instead of every MCP client pre-registering with every MCP server — which does not scale past a demo — the client presents a URL describing itself, and the server fetches and verifies that metadata. It's the piece that lets your server work with Claude and with MCP clients you haven't heard of yet, without an open-registration free-for-all.

SuperCognit implements both, per the current spec, on every published server. If you're evaluating any hosted MCP product, ask about these two specifically. "We support OAuth" is a 2023 answer to a 2026 question.

Layer 2: workspace isolation

Authorization decides who gets in the door. Isolation decides what's behind the door. Every SuperCognit MCP server is scoped to its workspace: its knowledge bases, its tools, its subscribers. A token for one workspace's server is worth nothing at another's, and there is no query, however creative, that retrieves a neighbour's documents — the boundary is structural, not a filter applied at answer time.

This matters more than it sounds. Retrieval systems answer from whatever corpus they can search. If the corpus boundary is soft — a tenant ID in a query filter, say — then the security of every answer rests on nobody ever writing one bad query. A hard per-workspace boundary means the interesting failure isn't possible, rather than merely unlikely.

Layer 3: who sees what

With the perimeter and the walls in place, the remaining decisions are yours — and they are policy, not engineering:

  • Private — the server is an internal company brain: SOPs, policies, product facts, reachable only by your own team. The right default for anything you wouldn't put on your website.
  • Public — anyone can connect. Right for documentation, product facts, and anything you actively want AI clients answering correctly on your behalf.
  • Paid — public, but behind a per-seat subscription. Stripe subscriptions, invoices and payouts are built in, with SuperCognit as merchant of record. A seat is an access-control primitive with a price on it: revoke the seat and the access goes with it.

The useful discipline is deciding the tier first and the content second. A server that mixes public product facts with internal escalation contacts in one knowledge base has already made its worst mistake, whatever its OAuth looks like.

What this buys you day to day

An employee connects the company server in Claude, authorizes once, and asks how the refund exception process works. A customer on the public server asks what each plan includes — and can't reach the SOPs, because the SOPs live in a different server in a different scope, not behind a prompt that says please don't mention them. Access control by architecture beats access control by instruction. Models follow instructions well, but "well" is not a security boundary.

None of this required your team to run an authorization server, rotate keys, or read the spec's changelog. That's the honest pitch: the security layers of a company MCP are exactly the part you want boring, standard, and someone else's full-time job.