- One catalogue of approved MCP servers that clients discover automatically
- No shared or long-lived tokens: access goes through the identity provider with narrow scopes
- Every tool call attributable to a user, an agent and a server version
- A paved road that lets teams publish new internal servers without a security exception
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
An organisation had embraced AI assistants faster than it had governed them. Developers connected IDE assistants to MCP servers for the code host, the ticketing system and the data warehouse. Some servers were built internally in an afternoon; others were installed from public repositories. Many used personal access tokens with wide permissions, stored in local configuration files. Nobody could say which servers were in use, who had approved them, or what they had done.
Security's first instinct was to block MCP outright. Leadership's instinct was the opposite: agents were becoming central to engineering and operations, and a ban would simply push usage further out of sight.
What had to be true
- One place to find approved servers, discoverable by the clients people already use.
- No long-lived shared tokens. Access flows through the identity provider, per user, with the narrowest scopes that work.
- Every tool call is attributable to a person, an agent, a server and a version.
- Writes and destructive actions need explicit, visible consent.
- Publishing a new internal server is easy if it follows the standard; exceptions are rare and visible.
Architecture
The design followed the ecosystem's own shape: the official MCP Registry is intended as an upstream that organisations build private subregistries on, adding internal servers that should never appear publicly3. The approach is described in more depth in running an enterprise MCP registry.
The data flow, end to end
- DiscoverClient lists servers from the private registry, filtered by the user's groups
- AuthoriseUser signs in through the identity provider; token issued for that server only
- ConnectClient reaches the server through the gateway, which checks token audience and policy
- Call a toolRead tools run directly; write tools trigger a consent prompt
- Act downstreamServer uses its own credentials or a token exchange, never the client's token
- RecordCall, result status and versions logged and traced
Step five matters most. The MCP security guidance names token passthrough, where a server forwards a token it received from the client to a downstream API, as an anti-pattern that breaks OAuth security boundaries, and the authorisation specification forbids it12. Every server on the platform validates that tokens were issued for it, and calls downstream systems with its own, separately scoped credentials.
The hard part: scopes people would actually accept
The technical controls were well understood. The difficult part was scope design. The MCP guidance warns that over-broad scopes granted up front expand the blast radius of a stolen token, make revocation disruptive and create consent dialogs that users abandon; it recommends a progressive, least-privilege model starting with a minimal read-only set1. In practice that meant:
- A small, named set of scopes per server, starting with read-only discovery.
- Write and admin scopes requested only when a user first invokes a tool that needs them.
- Central control through the identity provider using the authorisation extensions, so administrators can grant and revoke access in one place4.
- Metrics on which scopes are requested and used, so creep is visible.
Least privilege only works if the least-privilege path is also the least-friction path. Otherwise people find a personal token and work around it.
How it ran
- Registry and gateway
- Server template and CI checks
- Usage and audit reporting
- Review criteria
- Scope and policy design
- Approve and pin versions
- Build from the template
- Declare scopes and data class
- Own and patch their server
- Find servers in use
- Classify by data and risk
- Agree review criteria
- Private registry
- Gateway and SSO
- Server template
- Top servers first
- Retire personal tokens
- Point clients at registry
- Block unregistered sources
- Usage-based pruning
- Regular re-review
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Private registry mirroring the public one | Allow-list in a wiki | Clients can discover from it, and versions can be pinned |
| Gateway in front of remote servers | Each server enforces policy alone | One place for authentication, policy, rate limits and audit |
| Servers use their own downstream credentials | Pass client tokens through | Token passthrough is forbidden and breaks audit and audience checks |
| Progressive scopes | Grant everything at first login | Smaller blast radius and consent people actually read |
| Enforce after migration | Block first, build later | Avoids pushing usage underground |
The prompt injection and excessive agency risks in the OWASP Top 10 for LLM applications shaped the server template, with tool descriptions treated as untrusted and write tools gated by consent5. The detailed controls are in securing MCP servers, prompt injection defence for agents and MCP extensions strategy.
What I'd do again, and differently
Again: start with an inventory and make the approved path faster than the unapproved one before enforcing anything. Differently: publish the server template and its CI checks in the first phase. Teams wanted to build compliant servers early, and every week without a template produced another one-off that later needed migrating.
If agents are spreading faster than your controls, my AI architecture work describes how I approach agent platforms, or analyse your challenge and bring the result to a call.
- 1Security best practicesModel Context Protocol documentation
- 2Authorization: security considerationsModel Context Protocol specification
- 3The MCP RegistryModel Context Protocol documentation
- 4Authorization extensions overviewModel Context Protocol documentation
- 5OWASP Top 10 for LLM ApplicationsOWASP GenAI Security Project