At a glance
- An MCP server vetting checklist tests publisher provenance, exposed tools, credential handling, data destinations, and runtime behavior before any agent connects.
- Each MCP server is a live connection an agent can act through, using the employee's own identity, permissions, and local files.
- Backslash Security's MCP Server Security Hub has scanned and scored more than 80,000 publicly available MCP servers.
- Backslash Security blocks risky agent actions inline before execution, including credential access, privilege escalation, and data sent to unapproved destinations.
Backslash Security
Published:
An MCP server vetting checklist gives enterprise security teams a repeatable way to decide whether a given Model Context Protocol server is safe to approve, for whom, and under what conditions. MCP is the protocol agents use to connect to external tools and data sources, and each MCP server is a connection an agent can act through — so vetting one is closer to onboarding a privileged integration than to reviewing a library. A usable checklist works through provenance and publisher, the tools and commands the server exposes, how it authenticates and where it stores credentials, which destinations it can send data to, how updates reach it, and what record exists afterward if something goes wrong.
Concretely, every server a team approves should be assessed against:
- Provenance — who publishes it, how it is distributed, and whether the installed build matches the published one.
- Exposed tool surface — the individual MCP tools it offers, including any that execute shell commands, read local files, or call external APIs.
- Identity and credentials — which tokens it reads, whether it uses corporate or personal accounts, and what it caches on disk.
- Egress — the endpoints it contacts and which of those are approved destinations.
- Enforcement and evidence — whether risky actions can be stopped before execution, and whether the run can be reconstructed afterward.
As of 2026, that decision has to account for where these servers actually run: on an employee's laptop, alongside agents, Skills, hooks, and rules files, under that employee's access. Latio's 2026 AI Security Market Report named Backslash Security an Endpoint AI Security Leader, a badge awarded to vendors demonstrating the most in-depth controls for AI on the endpoint, including permission mapping, folder structures, approved commands, and runtime controls for MCPs and Skills.
What exactly are you vetting when you vet an MCP server?
Vetting an MCP server means assessing a specific, bounded object, so it is worth stating exactly what that object contains before you vet it. MCP, the Model Context Protocol, is the protocol agents use to connect to external tools and data sources, and each MCP server is a live connection an agent can act through — usually a process running on an employee's own endpoint, under that employee's identity and access. The scope here is the server itself; the agent calling it, and the Skills and rules files sitting beside it, are separate objects with their own checks.
An MCP server is not a monolith. A checklist evaluates its parts individually, because each one carries a different attribute set and a different failure mode.
| Component | What it is | Attribute a checklist evaluates |
|---|---|---|
| Tools | Callable functions the server exposes to the agent | Capability class: read, write, or execute; what systems each call can reach |
| Prompts | Prompt templates the server supplies for the agent to load | Whether they carry standing instructions the user never sees |
| Resources | Data the server exposes for reading — files, records, tickets, pages | Sensitivity of the data, and whether untrusted content enters the agent's context |
| Transport | How the agent reaches the server: local process, or remote over HTTP | Local versus remote, destination host, and whether traffic leaves the machine |
| Credentials | Tokens and keys the server holds or inherits from the user | Scope of the token, where it is stored, and whether the account is corporate or personal |
| Manifest / config entry | The server's definition inside the agent's configuration file | Install source, pinned version, and whether the entry can be edited silently after approval |
Provenance sits on the same list: who published the server, which package source it was installed from, and whether anyone has assessed that exact build before it reached the endpoint.
Which checks belong on an enterprise MCP server vetting checklist?
Scope note: this covers vetting a single Model Context Protocol server — the standard agents use to reach external tools and data — before you approve it. Each server is a live connection an agent can act through, so the checks that belong on an enterprise vetting checklist run from provenance to removal path. Monitoring behavior after approval is a separate control.
Work the list in order. Each row pairs the check with the failure mode it exists to catch.
| # | Check | Pass criteria | Do this — but watch out for |
|---|---|---|---|
| 1 | Provenance | Source repository and publisher are identifiable and match the advertised project | Accept named publishers only; typosquatted names mimic real ones, so verify the repository URL, not the display name |
| 2 | Maintainer | An accountable owner with recent commit activity | Favor active projects; a lone maintainer is a handover risk, so record an internal owner too |
| 3 | Publishing method | Installed from a pinned, versioned artifact | Pin versions; pinning stalls security fixes without a review cadence |
| 4 | Tool inventory | Every exposed MCP tool enumerated, descriptions read in full | Read tool descriptions; the agent obeys them, and hidden directives can sit inside one |
| 5 | Permission scope | Least privilege: filesystem paths, repositories and APIs explicitly bounded | Scope narrowly; servers run under the employee's own identity, so broad grants inherit that access |
| 6 | Credential handling | Secrets injected at runtime from a managed store, never in config files | Externalize secrets; local config files travel with the endpoint |
| 7 | Network egress | Destination hosts known and allowlisted | Allowlist egress; a server that calls out dynamically can exfiltrate quietly |
| 8 | Update channel | Signed, reviewable updates | Require signing; silent auto-update changes the thing you approved |
| 9 | Logging and tracing | Prompt, tool call and outcome are reconstructable | Keep traces; without them an incident has no record to investigate |
| 10 | Removal path | A tested way to revoke and remove it fleet-wide | Test removal first; uninstall often leaves the config entry behind |
Rows one and four assume you already know which servers exist. Backslash Security discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file, plugin and connector running on an endpoint, which makes the inventory question answerable across the fleet rather than one machine at a time.
How do you verify an MCP server's provenance, identity, and permission scope?
To verify an MCP server's provenance, a reviewer works through a fixed sequence and records the result of each step. MCP, the Model Context Protocol, is the standard agents use to reach external tools and data; each server is a live connection an agent can act through, running with the employee's own identity and access. This means every permission the server requests is a permission the organization has effectively granted, so the review has to end in written evidence rather than a verbal approval.
What should a reviewer check, and what evidence should they keep?
| Verification step | Evidence to record | Why it matters |
|---|---|---|
| Confirm publisher identity | Repository owner, organization account, maintainer history | Typosquatted forks imitate known publishers |
| Check signature and package integrity | Verification output, package digest, registry source | Confirms the installed artifact matches the reviewed one |
| Pin the version | Exact version string and lockfile entry | A server can change its tool surface on the next release |
| Read the declared tool surface | Every exposed tool and its parameters | Tool descriptions are instructions the agent will follow |
| Map requested OAuth scopes | Each scope, the system it touches, its justification | Write access to Git or cloud accounts widens blast radius |
| Map local file and shell access | Readable and writable paths, command execution rights | Shell access makes a connector arbitrary code execution |
| Store the approval record | Reviewer, date read, decision, expiry | Supports audit and later incident reconstruction |
How do you keep the approval record from going stale?
A written approval only holds if something on the endpoint enforces it. Backslash Security carries the decision forward onto the machine: approved servers are allowlisted, risky ones denylisted, and the surrounding inventory — agents, Skills, hooks, rules files, plugins and connectors — is discovered continuously, so a server installed outside the review process shows up instead of passing unnoticed. For teams starting without any record at all, Backslash Security offers a free AI Endpoint Exposure Assessment that is agentless, read-only, and retains no data, producing the first inventory a checklist can actually be applied against.
Which MCP server risks slip past a one-time vetting at install?
Approval at install captures a snapshot, so most MCP server risks arrive after the review closes. MCP, the Model Context Protocol, is how agents connect to external tools and data sources; each MCP server is a live connection an agent can act through, and that connection keeps changing.
What changes after approval without anyone filing a ticket? A server can redefine its tool descriptions on a later run. The agent reads the new description and acts on it, while the approval record still points at the old one.
How does a vetted server end up doing something nobody asked for? Through indirect prompt injection — hidden instructions planted in content the agent reads on its own, which it follows as though the user had typed them. Backslash Security research found that malicious instructions hidden in a repository's AGENTS.md rules file, which carries standing instructions an agent reads on every run, could trick OpenAI Codex into silently accessing AWS credentials, npm tokens and Git configuration.
Can permissions that are safe apart be unsafe together? One tool reads a local file; another makes an outbound request. Reviewed separately, both pass; chained inside a single agent run, they become exfiltration.
Who installed the servers security never saw? Employees, under their own identities. A personal login and a personal token put a working server on a corporate machine without touching MDM — the concrete form of shadow AI, unsanctioned AI use inside the organization.
| Do this | But watch out for — and how to contain it |
|---|---|
| Keep a continuously refreshed inventory of installed MCP servers and tools | A quarterly export goes stale between runs; refresh continuously, not on a review calendar |
| Allowlist approved servers, denylist risky ones | Allowlists drift as versions change; bind approval to how the component currently behaves |
| Scope and rotate the credentials an agent can reach | Tokens issued for a pilot outlive the review; set expiry at issuance |
| Record the full path from prompt to tool call to outcome | Process-level logs stop at the boundary; capture agent-level tracing for forensics |
Where should MCP controls sit: in a registry, at a network layer, or on the endpoint itself?
MCP controls can sit in three places — a curated internal registry, a network or proxy layer, or the endpoint itself — and each layer answers a different question. MCP, the Model Context Protocol, is how an agent connects to external tools and data; every MCP server is a live connection an agent can act through. Fix the deciding criteria before comparing layers.
- Visibility — what the layer can actually enumerate, versus what it only knows was requested.
- Coverage of locally run servers — whether a server launched as a local process on a laptop, reading local files under the employee's own identity, is in scope at all.
- Enforcement timing — whether the control can stop an action before execution, or only record it afterward.
- Forensic reconstruction — whether you can rebuild which prompt led to which tool call and which outcome, months later, for an auditor or an incident review.
| Control layer | Visibility | Locally run servers | Enforcement timing | Forensic reconstruction |
|---|---|---|---|---|
| Curated registry / allowlist | Approved entries only; declared intent, not live state | Not covered unless voluntarily declared | Pre-approval, before deployment | Procurement record only |
| Network / proxy mediation | Traffic that crosses the mediated path | Not covered when the server runs and reads locally | At the connection boundary | Connection logs, not agent reasoning |
| Endpoint discovery and inline action control | Components as they exist on the machine | Covered, including locally launched servers | Inline, before the action executes | Agent run traced end to end |
A control point's value depends on whether the thing it governs ever crosses it, and a server started locally against local files crosses no network boundary and appears in no procurement record.
A registry fits governance and vendor approval; network mediation fits remote, shared services. Endpoint-level control — where Backslash Security operates — covers the employee-initiated components the other layers never observe, and Backslash Security traces the full path of an agent run from prompt to agent to tool call to outcome.
Frequently Asked Questions
What belongs on an MCP server vetting checklist?
An MCP server vetting checklist for enterprise security teams has to cover both the connection and everything that connection exposes. MCP, the Model Context Protocol, is the protocol agents use to reach external tools and data sources, so each MCP server is a live path an agent can act through. A workable checklist records:
- Publisher and provenance — who ships the server, and where the build comes from.
- Tool surface — every MCP tool the server exposes, since each one is an action the agent can take.
- Credential reach — which tokens, keys, and configuration files the server can touch.
- Identity — whether the server runs under a corporate identity or an employee's personal account.
- Destinations — the external endpoints data can be sent to.
- Change control — who can edit the configuration after approval, and whether edits are visible.
- Reconstructability — whether you can replay what the server did after the fact.
According to Backslash Security, its MCP Server Security Hub, a public and continuously updated risk database, held 81,021 MCP servers, each scored for risk, when read on 22 September 2026, which gives reviewers a reference point for the reputation line of the checklist.
How do you find the MCP servers employees are already running?
Through discovery on the endpoint itself, because most MCP servers are installed by the person using them rather than requested through IT. Backslash Security discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file, plugin, and connector running on an endpoint, and offers a free AI Endpoint Exposure Assessment — known in conversation as Scout — that is agentless, read-only, and retains no data. Agentless here means information is collected without leaving software permanently installed on the machine. As Philip Walsh, Head of Security Engineering at Happy Returns, put it: "Backslash gave us a live picture of the AI our engineers were already running, and a way to govern it without slowing anyone down."
Why doesn't the existing endpoint stack answer this question?
Endpoint detection and response, or EDR, is the incumbent endpoint layer, built to catch malicious processes, files, and known-bad behavior on a machine. When an approved agent calls an approved MCP server with the employee's own permissions, EDR sees the process but not which prompt, agent, Skill or MCP server caused the action — and without the cause, the action cannot be stopped in time. Closing that gap is the work of agentic AI endpoint security, and Latio's 2026 AI Security Market Report named Backslash an Endpoint AI Security Leader, a badge awarded to vendors demonstrating the most in-depth controls for AI on the endpoint, including permission mapping, folder structures, approved commands, and runtime controls for MCPs and Skills.
What is the difference between Shadow AI and a rogue agent?
Shadow AI is a tool nobody approved: an agent, model, MCP server, or Skill installed by an employee that security cannot see, frequently connected through a personal account on a corporate machine. A rogue agent is an approved component behaving in ways nobody asked for — reaching for credentials, escalating privilege, or sending data to an unapproved destination. Vetting addresses the first; inline enforcement addresses the second. Backslash Security blocks risky agent actions before execution, including unauthorized code execution, credential access, privilege escalation, and data sent to unapproved destinations.
Should Agent Skills and rules files go through the same review?
Yes, and agent skills security often gets skipped because the artifacts look trivial. An Agent Skill is packaged instructions and scripts that extend what an agent can do — in practice frequently just a markdown file — and it executes with the user's own permissions. A rules file, such as AGENTS.md or CLAUDE.md, carries standing instructions an agent reads on every run. Backslash Security research found that malicious instructions hidden in a repository's AGENTS.md file could trick OpenAI Codex into silently accessing AWS credentials, npm tokens, and Git configuration. Backslash Security also operates a free Skills Security Scanner that scans AI agent Skills for security risks.
What audit evidence should the vetting process produce?
Enough to reconstruct a specific agent run later. Backslash Security traces the full path of an agent run from prompt to agent to tool call to outcome, and states that it automatically generates audit evidence for EU AI Act, NIS2, DORA, and SOC. For a review board, that means an approval decision on an MCP server can be tied to the actions that server subsequently performed, under which identity, and against which destinations.
About this article
Backslash Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Backslash Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-10-08