Running MCP across a team without making a mess
One engineer with five servers is fine. Twenty engineers with their own five each is an audit finding waiting to happen — and it arrives on the day somebody leaves.
The first five installs are somebody’s afternoon. The problem arrives quietly, months later, and always in the same form: an engineer leaves, and nobody can say which servers held credentials on their machine, what those credentials reached, or whether the CI job still authenticating as them is theirs.
Everything below is what prevents that conversation. None of it is exotic, and all of it has to be decided before it matters — because afterwards the answer is an inventory nobody trusts.
An install belongs to an account, not a laptop
This is the single design decision that makes the rest possible. If the install is owned by the account, a key is a device rather than an identity: removing a machine removes its key and leaves the install, the subscription and the log intact. If the install is owned by whoever ran the command, everything they did leaves with them.
A key per machine, not per person
The instinct is one key per engineer. The version that survives contact with reality is one key per machine — laptop, CI runner, staging box — because those are the things that get lost, rotated and decommissioned independently of each other.
A shared CI key across a fleet of workers produces the strangest tickets: the workers share one install and therefore one allowance, and they starve each other in whatever order they happen to arrive, which is not an order anybody chose. If your CI is a fleet, give the fleet its own install rather than its own excuse.
Two ceilings, and they do different jobs
The allowance stops a loop. The account ceiling stops accumulation — which is the thing that actually happens to teams. It is rarely one runaway job. It is eleven subscriptions nobody remembers approving, each of them individually reasonable.
The audit trail is the point, not the paperwork
Who installed it, who approved the capability a release added, who revoked the key, and when. It belongs to the organisation rather than to the person — a member should not be able to delete the record of their own approval, which is the entire reason for keeping one.
The test of whether yours is real: pick a server nobody has mentioned in a month and answer "who added this, when, and what did it do last week" without asking anybody. More than two minutes means the trail is decorative.
The two mistakes
- Letting everyone install anything, then trying to inventory it later. The inventory is never accurate and the conversation is always adversarial. A short allowed list plus a genuinely fast path to add to it beats a policy nobody reads — and the speed of the second half is what makes the first half survive.
- Approving a publisher rather than a release. "We trust this company" quietly means "and everything they ship from now on". Approve the capability surface; re-approve when it changes. Smaller decision each time, much smaller blast radius.
The question a team has to be able to answer is not "what do we have installed". It is "what can it reach, and who said yes".
A short rollout that works
The last box is the one people skip and the one that pays. Reading the call log once a month is twenty minutes, and it is how a team finds the server nobody calls, the key that should have gone with a laptop, and the agent quietly making four hundred calls a day at three in the morning.