Buyer Guide · June 2026
MCP server security for non-technical buyers: a 10-minute field guide
Your developers want to install community MCP servers. Your security team wants you to have a policy. You are somewhere in between — you understand the business risk, you don't want to block productivity, and you don't have time to review source code. This guide explains what a SkillAudit report tells you, what each grade means in plain language, and how to turn that report into a decision you can defend.
First: what is an MCP server, and why does it need a security review?
A Model Context Protocol (MCP) server is a small software plugin that gives an AI assistant — Claude, Cursor, or similar — the ability to take actions in your environment. An MCP server for GitHub lets the AI read and write code repositories. One for Slack lets the AI send messages. One for your database lets the AI run queries.
The security concern is straightforward: when you install an MCP server, you are giving it the same access credentials your developers have. If that server has a vulnerability, an attacker who knows about it can use your developer's AI session to extract those credentials, read your private repositories, or exfiltrate data. The server runs on your developer's machine, with your developer's permissions, using your developer's API keys.
This is why the Anthropic Skills Directory now requires a security review before listing. It's why 36.7% of community MCP servers in our public corpus have Server-Side Request Forgery vulnerabilities — a finding class that, when combined with broad API scopes, can result in full account compromise. And it's why a team policy that gates MCP server installation on a minimum security grade is not bureaucracy — it's the same risk management you'd apply to any third-party software touching your production credentials.
What SkillAudit measures: the six axes explained without jargon
Every SkillAudit report grades an MCP server across six dimensions. Here is what each one means in terms a non-technical buyer can act on.
Can an attacker abuse this server to reach systems it's not supposed to reach?
The Security axis looks for the two most dangerous patterns in MCP servers: SSRF (Server-Side Request Forgery) and command injection.
SSRF means the server will fetch any URL you give it — including internal network addresses like http://169.254.169.254 (AWS metadata endpoint that vends temporary credentials) or http://internal-db.company.com. A malicious website or a compromised prompt could instruct the AI to fetch one of those URLs using your developer's session, leaking credentials or internal data. Command injection means the server executes shell commands built from AI-supplied input — an attacker who can influence the AI's output can run arbitrary commands on the host machine.
Business translation: A Security HIGH finding means the server could be weaponized to reach internal systems or execute code on a developer's machine. This is the finding class with the largest blast radius — it's not a "maybe someday" risk, it's a live exploitation path.
Does this server handle API keys, tokens, and passwords safely?
The Credentials axis looks for three patterns: hardcoded secrets in source code, API keys logged or echoed to stdout, and .env files committed to the repository. Any of these means the credentials flow outside the systems they're supposed to stay in.
In our corpus of 101 servers, 38 had Credential findings. The most alarming: 64 hardcoded secrets across 18 repositories, including OpenAI and Anthropic API keys, GitHub Personal Access Tokens, Stripe keys, and AWS access keys. These are not hypothetical risks — if a developer installs a server that has a hardcoded Stripe test key in its source, and that server is exploited, the attacker has a starting point for further credential escalation.
Business translation: A Credentials HIGH finding means secrets are mishandled in a way that makes them accessible outside the intended trust boundary. Given that MCP servers run with your developer's API keys, a Credentials finding can multiply the impact of any other vulnerability.
Does this server ask for more access than it actually needs?
The Permissions axis checks whether a server requests broad API scopes when narrower ones would work. It also looks for permanent credentials where short-lived ones would be safer, and credentials passed in URLs (which appear in logs) rather than headers.
68% of corpus MCP servers request org-wide API scopes when only repository-level access is needed. This matters because Permissions findings multiply the impact of Security findings. An SSRF vulnerability on a server with read-only, single-repo access is bad. The same SSRF on a server with admin:org scope — which grants write access to every repository in your GitHub organization, the ability to add members, and access to organization secrets — is an organizational incident.
Business translation: A Permissions HIGH finding means the server is asking for more power than it needs, increasing the blast radius of any security problem. This is especially important when evaluating servers that touch your GitHub organization, cloud providers, or internal databases.
Is anyone keeping this server up to date?
The Maintenance axis looks at commit history, open security issues, dependency advisory feeds, and whether the server has a published security disclosure policy. Maintenance is the only axis that gets worse over time without anyone touching the server — a well-maintained server today can earn a Maintenance FAIL in six months simply by being abandoned.
Nine of the 101 most-installed MCP servers in our corpus are archived — including servers from Azure, Gmail, and two of Anthropic's own scaffolders. Eight of those nine are vendor-official releases. A server with no commit in 365 days is not being maintained; the dependencies it installed at release will accumulate CVEs, and no one is publishing patches.
Business translation: A Maintenance HIGH means the server is effectively dead. Installing it is not just a today risk — it's a risk that grows every day as new CVEs are published against its unpinned dependencies. Many teams have a policy against installing npm packages with no maintainer activity in 12 months; the same logic applies here.
Has this server been tested against the AI clients your developers use?
The Compatibility axis checks whether the server has been verified to work correctly on Claude Code, Cursor, Windsurf, and other major AI clients. A server that has only been tested with one client can behave differently — sometimes unsafely — in another context due to differences in how clients handle tool invocations, session state, and permission scoping.
Compatibility findings are typically lower severity than Security or Credentials findings, but they matter for operational reasons: a server that fails on your developer's chosen client is worse than no server at all, and one that behaves unexpectedly across clients can produce inconsistent security properties that are hard to audit.
Business translation: A Compatibility finding is primarily a reliability concern, but at the HIGH level it can indicate security-relevant behavioral differences across clients. Treat it as a flag to test the server explicitly against your environment before approving adoption.
Can your security team understand what this server does and how it does it?
The Documentation axis checks for a runnable example that demonstrates the server's normal operation, a versioning scheme, and a published security disclosure policy (SECURITY.md). A server without any of these is harder to audit, harder to onboard, and harder to maintain.
Documentation findings are the lowest-severity axis in isolation. However, a server with no documentation and no security disclosure file is sending a signal about its overall maturity and the maintainer's security culture. Every A-grade server in our corpus has at least a working example; 17 of 19 lack only a SECURITY.md to be perfect scores.
Business translation: A Documentation WARN is not a blocker on its own. Paired with Security or Credentials findings, it's further evidence of a server that wasn't built with production teams in mind. For a server you're considering for wide internal deployment, you want the documentation axis to be clean.
Reading the grade: what A through F actually means
Every SkillAudit report produces an overall letter grade based on a weighted score across the six axes. Here's what each grade means in terms of adoption decision.
The three-outcome decision framework
When your team proposes installing an MCP server, the audit report drives one of three outcomes. Use this framework to document your decision.
Install: grade A or B with no unacknowledged HIGH findings
Approve for standard adoption. Set a re-scan cadence — we recommend monthly for servers in active use. Add the server to your approved-list with the audit date and grade. If the grade drops on re-scan, trigger a review before the next update pull.
Review first: grade C, or B with a Permissions HIGH
Do not approve immediately. Assign a technical reviewer to read the specific HIGH and WARN findings, assess whether compensating controls are practical (scope restriction, sandboxing, credential isolation), and make a written recommendation. The decision log should include: which findings were reviewed, which compensating controls were applied, who signed off, and the re-evaluation date. Alternatively, file an issue with the server author citing the specific SkillAudit findings — many A-grade servers started as C-grades before the maintainer addressed the specific issues.
Block: grade D or F, or any Security or Credentials HIGH
Do not install in any environment where production or org-level credentials are active. If the server provides unique functionality with no alternative, escalate to your CISO for explicit sign-off on a time-limited exception. The exception should be scoped to a sandboxed environment with restricted credentials, not general developer use. Re-evaluate when the author publishes a patch addressing the specific findings.
The audit report is not a one-time check
One of the most important things the 30-day re-scan data tells us is that a server's grade at the time of installation is not permanent. A server that earned an A in April can earn a C in June if a new feature is added carelessly — and it can earn an F in September if it stops being maintained and its dependencies accumulate CVEs.
The practical answer is a continuous re-scan rather than a point-in-time check. The GitHub Action CI gate adds a SkillAudit re-scan to your CI pipeline — it runs on every commit to any repository that includes MCP server dependencies, fails the build if a new HIGH finding appears, and sends a Slack alert if the overall grade regresses. Your team approved the server when it was an A; the CI gate tells you the day it becomes a B or C.
For teams that are not yet running the CI gate, a monthly manual re-audit of all approved MCP servers is a reasonable interim control. SkillAudit's free tier allows you to re-run an audit on any public repository at any time — the report shows the diff from the previous run, so you can see exactly what changed between audit cycles.
What to do when the answer is "block but we need it"
The most common objection to a minimum-grade policy is: "Yes, but we need this specific server and there's no alternative." This is a real constraint, not an excuse. Here is how to handle it without abandoning your policy.
Step 1: File a specific issue with the author. Don't just block the server — cite the exact finding. An issue that says "your server has an SSRF vulnerability" is less actionable than one that says "your fetchUrl tool has no hostname allowlist — here is the specific finding from the SkillAudit report and a suggested fix." Authors of actively maintained servers respond to specific, actionable disclosures faster than general security warnings. In our 30-day re-scan data, 7 of the 67 F-graded servers improved within 30 days — all because of targeted disclosure with specific findings.
Step 2: Apply a scoped exception. Allow the server in a sandboxed environment with the minimum credentials needed for the specific use case. If the server needs GitHub read access for a specific repository, provision a scoped token for that repository only — not the developer's personal PAT with org-wide scope. Document the scope restriction and the expected date of the server's security remediation.
Step 3: Set an expiry on the exception. Exceptions without expiry dates become permanent. Set a re-evaluation date — 30 or 60 days — and cancel the exception if the author has not addressed the findings by that date. Most active maintainers will patch within 30 days of a specific, actionable disclosure.
Frequently asked questions from team leads
Our vendor says they have their own internal security review. Can we skip the SkillAudit check?
Vendor-official MCP servers earn the lowest grades in our corpus. 79% of vendor-official servers earned an F — versus 26% of community-maintained servers. "Vendor has a security team" and "vendor's MCP server passed a security review" are not the same statement. Run the audit regardless of who published the server.
The server has 10,000 GitHub stars. Doesn't that indicate it's safe?
Star count is a proxy for popularity, not security. The most popular MCP servers in our corpus earned the worst grades — popularity drives adoption, and adoption happens before security review. SkillAudit was designed specifically for this situation: when GitHub stars and brand recognition are the only available signal, you have no security signal.
We're blocking a D-grade server. The developer says the specific vulnerability only matters if an attacker can influence the AI's output. Is that a realistic attack?
Yes. Prompt injection — an attacker embedding instructions in content that the AI processes — is a live attack class. An attacker who controls a GitHub issue, a web page the AI fetches, or a Slack message the AI reads can instruct the AI to invoke a vulnerable tool with a crafted argument. The threat model for MCP servers is not just "can an outside attacker call the tool directly" — it's "can an outside attacker influence the AI agent's tool invocations," which is a much broader attack surface.
How do I explain a minimum-grade policy to developers who want to install servers quickly?
Frame it as the same control you'd apply to any third-party software installation. You wouldn't let a developer install a browser extension with a known credential-stealing vulnerability on a machine with production access. An MCP server that earns an F has a credential-stealing vulnerability. The policy is: run the audit, share the result, install the A and B servers, and file issues on the others. Developers who build MCP servers will fix their F grades when their users tell them specifically what to fix.
We don't have anyone technical enough to evaluate a C-grade server's specific findings. What do we do?
Run the free SkillAudit audit and share the report link with the author. The report includes specific findings with severity levels and suggested remediation. You don't need to evaluate the code — forward the report to the person who wrote the code. If the author addresses the HIGH findings and re-runs to a B or A, approve it. If the author doesn't respond, treat it as an unmaintained server and block it.
Run a free audit on any MCP server before your next team installation.
Run a free audit → Download team policy template →Related reading
- How to read a SkillAudit report — understanding every section in detail
- Block 52 of 101 community MCP servers with one CI gate — the 2026 team policy template
- GitHub Action gate: enforcing MCP security grades in CI/CD
- Vendor-official vs community MCP server grade breakdown
- 30-day re-scan delta: how quickly the MCP ecosystem responds to disclosure
- MCP server permissions checklist: 5 questions before you approve org scope