Org policy: govern tools the way you govern dependencies
Lesson 5 of 5 in Supply Chain and MCP Security: Code You Run, Content You Trust.
A per-engineer review does not scale, and it does not have to. You already solved this problem once: your organisation has an opinion about which third-party libraries may enter the build, who approves exceptions, and what happens when a CVE lands. A tool allowlist is that process, applied to servers instead of packages — and the reason it needs to be a process rather than a wiki page is that the artefacts here change their own behaviour after approval.
Three design choices decide whether the policy survives. It has three outcomes, not two — approve, sandbox-first, reject — because a binary gate turns every uncertain case into either a rubber stamp or a blocker, and blockers produce shadow installs. It maintains a catalogue, so the second team to want Jira access inherits the first team’s review rather than repeating it. And it owns the whole lifecycle, because the risky moment is version 1.0.16, not day one.
Tool intake, end to end
- Engineer requests a server or tool
A short form: which system, which capability, which agents, read or write. Cheap to file, or people route around it.
- Already in the catalogue?
The catalogue is the point. Most requests after the first quarter should end here.
- Mount the approved entry, inherit its scoping
Same pinned artefact, same credential pattern, same monitoring. No new review.
- First-party, or a publisher you can verify?
Verified namespace, real repository history, name checked against the official one for impersonation.
- Reject — with a written reason and an alternative
A rejection that names the next-best path (build a thin server, call the API directly) prevents the shadow install.
- Pin the exact version or digest; record the artefact
The approval attaches to this artefact. Anything else is a new decision.
- Read tools/list; hash descriptions; count write tools
Reviewer output is a saved artefact: the tool list, the hashes, and the list of tools you are deliberately disabling.
- Can the credential be scoped down and, if remote, audience-bound?
Read-only, project-scoped, dedicated identity. Remote servers: RFC 8707 resource indicators.
- Would mounting it create the trifecta in one session?
Untrusted content plus private data plus an outbound channel. If yes, the fix is topology, not paperwork.
- Approve only with session or agent separation
Reader and writer in different contexts, or the workflow split across two agents with different mounts.
- Sandbox-first: contained pilot, gated writes, re-review dated
Contained process, egress allowlist, approvals on writes, one team, a review date in the calendar.
- Approve, add to catalogue, monitor for drift
Catalogue entry, owner, credential pattern, tool-list hashes, and the alert that fires when they change.
Interactive sorting exercise: Ten real-shaped install requests land in your queue this month. Sort each into approve, sandbox-first, or reject. The test is always the same two questions: if this code is hostile, what can it reach — and if this text is hostile, what can it talk the agent into?
Finally, measure the programme, or it will decay into a form nobody reads. Four numbers are enough: catalogue coverage (what fraction of servers actually running are approved entries), time to detect drift (how long between a tool description changing and an owner knowing), credential scope (how many approved entries still hold org-wide tokens), and shadow installs found — which should be non-zero, because zero means you are not looking.
The mapping to dependency governance is close enough to reuse the machinery, and worth writing down for whoever owns your software supply chain today.
| Dependency control you already have | The tool-supply-chain equivalent | What differs |
|---|---|---|
Lockfile / pinned versions | Pinned server versions or image digests in host config, reviewed like a lockfile diff | Host config is often per-developer and untracked — getting it into version control is half the work |
SCA scanning and a CVE feed | The same scanners on server packages, plus watching MCP tooling CVEs (client shims and test tools are in scope too) | Scanners cannot see the content surface at all — no scanner flags a hostile tool description |
SBOM / inventory | A tool inventory: which servers, which hosts, which tools enabled, which identity, which egress allowlist | Must be enumerated per host, and changes at runtime when a server updates its own tool list |
License and dependency review | Data-flow review: what this tool reads, what it can write, whether it composes into the trifecta | The new question. A library’s data flow is visible in your code; a server’s is a policy decision about the agent’s session |
Deprecation and removal process | Documented removal from every host, credential revocation, and a rehearsed kill switch | Removing a package from a registry does not un-install it from the machines that already have it |
Interactive flashcard deck.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.