Implementation Kit
MCP Server Inventory Template and Security Review Checklist
Which MCP servers agents may connect to, what each exposes, and what contains a compromised one. An inventory and allowlist, an intake review template, a credential scoping standard, and a re-review trigger log.
Who this is for: The platform or security owner governing agent tool connections.
1. MCP server inventory and allowlist register
SpreadsheetEvery MCP server any agent can reach, with what it exposes and its risk tier.
Template
| Server | Publisher | Exposed tools | Data scope (read / write / external) | Ingests untrusted content? | Risk tier | Allowlisted? | Review date |
|---|---|---|---|---|---|---|---|
| <server> | Y / N (web, tickets, issues) | Low / Medium / High | Y / N | YYYY-MM-DD |
Worked example
| Server | Publisher | Exposed tools | Data scope | Ingests untrusted content? | Risk tier | Allowlisted? | Review date |
|---|---|---|---|---|---|---|---|
| internal-docs-mcp | Platform team | search_docs, get_doc | internal read | N | Low | Y | 2026-08-15 |
| ticketing-mcp | Platform team | list_tickets, comment | internal read + write | Y (ticket bodies) | High | Y (write requires confirm) | 2026-09-01 |
| github-issues-mcp | third party (pinned v1.2) | list_issues, create_issue | external repo read + write | Y (issue text) | High | Y (read only) | 2026-09-01 |
| random-web-fetch-mcp | unknown | fetch_url | external | Y | High | N | blocked 2026-08-20 |
Acceptance criteria
- ✓Every reachable MCP server is listed, including ones developers added themselves.
- ✓Each server records whether it ingests untrusted external content, since that sets the risk tier.
- ✓Only allowlisted servers are reachable from agent runtimes; the rest are network-blocked.
2. MCP server intake review template
SpreadsheetThe documented review a new server needs before any agent connects.
Template
| Question | Finding |
|---|---|
| Publisher identity verified? How? | |
| Full list of tools exposed, and what each can do | |
| Data the server can read | |
| Data or actions the server can write or trigger externally | |
| Does it ingest untrusted content (web pages, tickets, issues, PRs)? | |
| How is untrusted-content ingestion separated from tool-execution authority? | |
| Authentication model; can we scope a dedicated least-privilege credential? | |
| Version pinning and update mechanism | |
| Decision: allow / allow with constraints / deny |
Worked example
| Question | Finding |
|---|---|
| Publisher verified | third-party; verified via signed release + org on the registry |
| Tools exposed | list_issues (read), create_issue (write), add_comment (write) |
| Can read | issues, comments, labels in allowlisted repos |
| Can write / trigger | creates issues and comments in allowlisted repos |
| Ingests untrusted content | yes: issue and comment bodies from external contributors |
| Separation of untrusted content from authority | agent runs issue text through a constrained "summarize only" step; tool calls require an explicit plan the orchestrator validates |
| Credential scoping | dedicated fine-grained token, 3 repos, issues-only |
| Version | pinned v1.2; updates via PR with review |
| Decision | Allow, read-only for v1; create_issue behind human confirmation |
Acceptance criteria
- ✓The review lists every tool the server exposes, not a summary.
- ✓It documents how untrusted-content ingestion is separated from tool-execution authority in the architecture, not just the prompt.
- ✓A signed-off decision exists before any agent connects.
3. Agent-to-MCP credential scoping standard
DocumentThe rule for how agent-to-server connections authenticate.
Template
One page. Applies to every agent-to-MCP-server connection.
- Every connection uses a dedicated, non-human identity. Never a shared credential, never a standing personal token.
- The identity is scoped to the minimum: specific tools, specific data scopes, specific targets (repos, projects, tables).
- Credentials are short-lived where the protocol allows, and rotated on a schedule otherwise.
- Write and external-action scopes are granted only where the intake review approved them, and gated per the autonomy boundary.
- Every credential has an owner, an expiry, and a line in the identity register.
- Revocation is tested: killing the identity stops the agent's access within a defined time.
Worked example
github-issues-mcp connection for the triage agent:
- Identity: svc-triage-gh (fine-grained GitHub App installation token).
- Scope: issues read/write on 3 repos; no code, no actions, no admin.
- Lifetime: 1-hour installation tokens minted per run.
- Write: create_issue and add_comment allowed; both behind orchestrator confirmation.
- Register line: owner Platform, expiry 2027-03, last review 2026-09-01.
- Revocation drill: uninstalling the app cut access in under 1 minute (tested 2026-09-03).
Acceptance criteria
- ✓No agent-to-server connection uses a shared or standing personal credential.
- ✓Each credential is scoped to specific tools, data, and targets.
- ✓Revocation has been tested and stops access within a stated time.
4. Re-review trigger log
SpreadsheetMaterial changes to a server force a fresh intake review.
Template
| Date | Server | Change (capability / maintainer / publisher / version) | Re-review outcome | Effective date |
|---|---|---|---|---|
| YYYY-MM-DD | <server> | <what changed> | re-approved / constrained / removed | YYYY-MM-DD |
Worked example
| Date | Server | Change | Re-review outcome | Effective date |
|---|---|---|---|---|
| 2026-09-12 | github-issues-mcp | v1.3 adds a run_workflow tool | Constrained: run_workflow denied at the allowlist; stayed on v1.2 | 2026-09-12 |
| 2026-09-20 | internal-docs-mcp | maintainer team merged into Platform | Re-approved, no change | 2026-09-20 |
Acceptance criteria
- ✓Capability, maintainer, publisher, and version changes each trigger a re-review.
- ✓A new tool on an existing server is denied by default until reviewed.
- ✓The log records the outcome and when it took effect.
Governance controls this kit produces evidence for
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The inventory and intake review are the AI tool and plugin supply-chain risk assessment for MCP servers.
The credential scoping standard and re-review log address agent OAuth scope drift.
Separating untrusted-content ingestion from tool authority is the agent prompt-injection defense.
MCP tool-call logging feeds the agent action audit trail.
Allowlisting and network-blocking non-approved servers is part of agent environment isolation.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →