MCP Exposure Assessment
Northwind Engineering (sample)
Prepared 12 August 2026 · 12 developer machines · Claude Code and Cursor
Executive summary
We inventoried every Model Context Protocol server configured across 12 developer machines and 2 AI clients. We found 7 distinct servers in 33 configured instances. 3 are high-risk and 4 appear in no governed catalog, meaning nobody has reviewed what they can do. 9 of 12 machines carry at least one high-risk server today.
12
machines in scope
7
distinct servers
3
high-risk
4
unreviewed
Prioritized remediation
Ordered by blast radius, then by how many machines are affected. P1 items involve credential reach or unreviewed execution — start there.
- P1postgres-prodon 5 machines
Rotate the credential, then remove or review the server's source before re-approving.
Holds a long-lived credential in its environment and has not been reviewed by anyone. Treat the credential as already exposed.
- P1aws-toolkiton 3 machines
Remove, or restrict to a scoped credential and re-review.
Can read credentials from the system keychain. An unreviewed server with keychain access can reach every secret on the machine, not just the one it needs.
- P2filesystemon 5 machines
Confirm which root path it is scoped to, and narrow it if that path is the home directory.
Has filesystem access. A reviewed server is still only as constrained as the directory it is given.
- P2puppeteeron 3 machines
Review the source, then allowlist a pinned version or remove.
Not present in any governed catalog — nobody has checked what it does.
- P2scratch-runneron 2 machines
Remove, or pin to a reviewed version with a restricted root path.
Unreviewed code with filesystem access. Scope is whatever the AI client asks it to read or write.
- P3githubon 12 machines
Keep. Pin the version so it can't change under you.
Reviewed and known-good. Version pinning stops a future release silently changing behaviour.
- P3slackon 3 machines
Keep. Pin the version so it can't change under you.
Reviewed and known-good. Version pinning stops a future release silently changing behaviour.
Full inventory
Every distinct MCP server found, with the risk flags that applied and how widely it is deployed across the fleet.
| Server | Risk | Machines | Flags |
|---|---|---|---|
| postgres-prodClaude Code, Cursor | HIGH | 5 | Credential in environment · Network egress · Not in any governed catalog |
| aws-toolkitClaude Code | HIGH | 3 | Keychain access · Network egress · Not in any governed catalog |
| scratch-runnerCursor, Claude Code | HIGH | 2 | Filesystem access · Not in any governed catalog |
| filesystemCursor, Claude Code | MEDIUM | 5 | Filesystem access |
| puppeteerCursor, Claude Code | MEDIUM | 3 | Network egress · Not in any governed catalog |
| githubClaude Code, Cursor | VERIFIED | 12 | Network egress |
| slackCursor, Claude Code | VERIFIED | 3 | Network egress |
Starter allowlist
The reviewed servers we recommend keeping. Adopting this as your allowlist means anything not on it stops being installable without a decision.
{
"allowed": [
"github",
"slack"
]
}Methodology & data handling
- Each machine ran the open-source CuratedMCP auditor once. It reads the MCP configuration of every installed AI client and classifies each server against a risk-classified catalog of reviewed servers.
- What left the machine: server names and risk flags only. Never commands, arguments, environment variable values, or file paths.
- Risk levels reflect declared capability, not observed behaviour — a server flagged for filesystem access can read files, which is not the same as proof that it did.
- Findings are a point-in-time snapshot. A developer can add a new server in seconds, so treat this as a baseline rather than a permanent state.