The question that decides your MCP architecture
Before tools, before transport, before hosting, answer one question: when a customer's AI calls your API, who is the caller? If the answer is "our service account", you've built a demo. If the answer is "that customer", you've built a product.
The shared-key demo, and why it can't grow up
- No attribution. Every log line says the same principal; support and debugging go blind.
- No blast-radius control. One leaked key = every customer's data.
- No selective revocation. Cutting off one abuser cuts off everyone.
- No fair limits. One heavy customer starves the rest.
- Silent authz bypass. Your API's permission model assumes per-user calls; a shared key routes around it.
The gateway pattern
Per-customer identity means a credential store and an auth flow in front of your MCP:
- Connect once. The customer proves who they are — pasting the API key they already have with you (validated live against your API), or signing in via your OAuth server.
- Store safely. Their credential is encrypted at rest; the AI client only ever holds a short-lived gateway token (stored as a hash, refresh-rotated, reuse-detected).
- Forward per call. Every tool call carries their credential upstream — your API's existing authorization applies unchanged.
What that buys you, visibly:
| Customer | Calls | Failures | Top tool | Last activity |
|---|---|---|---|---|
| ada@loopwork.io | 613 | 17 | post | 8:57 PM |
| felix@brightpath.app | 409 | 11 | me | 8:33 PM |
| admin@commandplusk.com | 23 | 6 | post | 4:51 PM |
And the customer experience is better, not worse
Counter-intuitively, per-customer identity is also the smoother onboarding: with OAuth discovery and dynamic client registration, the customer pastes one URL into Claude and the connect screen opens automatically. No config files, no tokens in chat messages.
This is the moat, not the tools
Anyone can generate tools from your spec — including your competitors. Per-customer identity, enforcement and attribution is the part that makes an MCP safe to sell. It's the entire reason Command+K's gateway exists.
FAQ
- What is per-customer identity for an MCP server?
- Each customer connects to your MCP with their own credential — the API key or OAuth account they already have with your product — instead of everyone sharing one key. Every tool call is then authenticated, attributed to that customer, individually rate-limitable, and revocable without affecting anyone else.
- What goes wrong with a shared API key on an MCP server?
- Your API can't tell customers apart: no per-customer limits, no attribution in logs, no way to cut off one abuser without breaking everyone, and a single leak exposes every account. It also silently bypasses the authorization logic your API already has, because every call arrives as the same principal.
- How does the customer's key stay safe?
- In the gateway pattern: the key is validated against your API once at connect time, encrypted at rest (AES-GCM), decrypted only inside the gateway when a call runs, and never exposed to the AI client — the client holds a short-lived gateway token whose hash is all the database stores.