# The MCP Server Approval Standard: Connect, Remediate, or Reject

*You can grade any MCP server against a documented pass or fail bar and reach the same connect, remediate, or reject verdict another reviewer would.*

- Canonical URL: https://www.refolk.ai/guides/mcp-server-approval-standard
- Pillar: Engineering and open source
- Format: Standard
- Published: 2026-08-24
- Last reviewed: 2026-08-24
- Reading time: 16 min

You need to decide whether a third-party or community Model Context Protocol (MCP) server is safe to connect to a production AI agent that already holds real credentials. MCP is the protocol that lets an agent invoke external tools, and those tools can read secrets, write files, and hit external networks under a live credential. This guide is the definition of done for that decision: a gradeable pass or fail bar, aimed at the platform engineer who has to sign off before a server touches production, that yields the same connect, remediate, or reject verdict no matter who runs it.

Published guides already cover vetting an open-weights model and grading a library you import. Neither addresses the MCP server case, where the thing you approve does not just sit in your dependency tree - it acts, on your behalf, with your access. That is the gap this standard fills.

## Why an MCP server needs its own approval bar

An MCP server is not a passive dependency. It is an active tool provider that an agent invokes at runtime, and the agent runs those invocations under whatever credential you gave it. That collapses the usual distance between "code I trust" and "actions taken in production."

Three facts from the research make the case that model-level and library-level habits do not transfer. First, the attack surface lives in the server, not the model. In the MCPTox benchmark - built on 45 live MCP servers, 353 authentic tools, and 1,348 malicious test cases - the average tool-poisoning attack success rate across 20 agents was 36.5%, and the highest refusal rate observed was under 3%. Existing safety alignment does not save you. Second, more capable models are more vulnerable, not less, because tool poisoning exploits superior instruction-following. Third, the MCP specification itself states that security cannot be enforced at the protocol level. A spec-compliant server can still be unsafe. "Compliant" is not "approved."

**36.5% - Average tool-poisoning attack success rate across 20 agents (MCPTox)**

The highest refusal rate any tested model reached was under 3%, so the model will not catch a malicious server for you.

The practical consequence: the only reliable control is a server-side gate you own, applied before connection. Upgrading the agent's model does not shrink the attack surface. Trusting the vendor's compliance claim does not either.

> **Rule:** The gate is server-side and pre-connection
>
> Because tool poisoning survives model alignment and the protocol cannot enforce security, every MCP server must pass a documented review before it is connected to any agent holding a real credential. No exceptions for "official-looking" servers.

## The four threat classes a pass/fail check must cover

Every MCP approval bar has to cover four named threat classes, because they are distinct vectors that a single control rarely stops together. If your checklist misses one, a server can pass and still compromise production.

- **Tool poisoning.** Malicious instructions embedded within tool metadata and descriptions - hidden directives that appear benign to a human but execute when the agent reads the metadata, persisting across sessions.
- **Confused deputy.** The server executes actions with its own, often broad, privileges rather than the requesting user's permissions. The spec addresses this by requiring that proxy servers implement per-client consent, but the protocol cannot force it.
- **Rug pull auto-update.** A clean tool you approved last week silently updates with malicious behaviour this week, with no re-approval and no alert. Day 1 benign, day 7 malicious.
- **Prompt injection through tool results.** Related to tool poisoning but distinct: the malicious content arrives in the data a tool returns, not in its description.

The reason all four matter at once: they fail your review in different places. Tool poisoning hides in metadata your scanner reads. Confused deputy hides in how the server exchanges tokens. Rug pull hides in time. Prompt injection hides in runtime data. A single control - "we ran a scanner" or "it uses OAuth" - covers at most one.

#### Where each threat class hides in an MCP server

1. **Tool metadata and descriptions** - Tool poisoning - hidden directives the agent reads and executes
2. **Auth and token flow** - Confused deputy - server acts with its own broad privileges or passes your token through
3. **Update and release pipeline** - Rug pull - approved code silently changes to a malicious payload
4. **Runtime tool results** - Prompt injection - malicious content arrives in returned data

*Four distinct layers, each requiring its own check; passing one does not clear the others.*

## What the public scan data tells you about the baseline

The population of MCP servers you might connect is measurably risky, so the default assumption should be "unsafe until graded," not the reverse. Large public scans converge on that conclusion from different angles.

The single most actionable finding is about credential scope. An audit of more than 5,200 servers found that 88% require credentials, 53% rely on static API keys or personal access tokens, only 8.5% use OAuth, and 79% pass keys via environment variables. Because the credential's scope determines whether the worst case is "read one file" or "exfiltrate the production database," per-tool scoping is the highest-leverage single check you can apply.

Here is the comparable scan evidence from the research, so you can see the baseline is not one outlier study:

| Study | Sample size | Headline finding |
|---|---|---|
| Astrix | 5,200+ | 53% use static API keys or PATs |
| Hasan et al. | 1,899 | 5.5% showed tool poisoning |
| AgentSeal | 1,808 | 66% had a security finding |
| Censys | 12,520 exposed | ~40% unauthenticated |
| VIPER-MCP | 39,884 repos | 106 zero-day vulnerabilities |

Read those as a floor, not a headline. Raw "X% vulnerable" figures vary by methodology, and one independent audit found a roughly 78% false-positive rate from YARA-based scanners. The point is directional: a meaningful fraction of servers fail on credentials, on tool poisoning, and on authentication, so a documented gate is warranted.

The vulnerability also scales with model capability, which is why the gate cannot be a temporary measure that a better model retires. The MCPTox results by model make this concrete:

| Model | Attack success rate |
|---|---|
| o1-mini | 72.8% |
| Phi-4 | 70.2% |
| GPT-4o-mini | 61.8% |
| Qwen3-32b (reasoning) | 58.5% |
| All-model average | 36.5% |

> **Note:** Two real CVEs set the ceiling on impact
>
> CVE-2025-6514 in mcp-remote (CVSS 9.6) allowed arbitrary OS command execution when connecting to an untrusted server, in a package downloaded more than 437,000 times, fixed in v0.1.16. CVE-2025-49596 (CVSS 9.4) let attackers run commands through unauthenticated MCP Inspector instances. These are the outcomes your gate exists to prevent.

## The grading procedure

Grade the server in eight ordered steps, recording PASS, FAIL, or N/A for each, then convert the record into a single connect, remediate, or reject verdict. The order below moves from cheap, decisive checks to expensive isolation testing, so you can reject early and stop.

#### Grade the server, then decide

1. **Inventory and threat-model the agent loop** - Map every tool call path and flag any tool that can read secrets, write files, or hit an external network. Shadow MCP is real, so account for auto-executing servers. Done: every tool listed with its blast radius.
2. **Verify source provenance** - Confirm the repo is the official upstream, not a typosquat or a fake "official" server with attractive naming. Verify canonical repo URL and maintainer, not the registry display name. Done: canonical entry and maintainer confirmed.
3. **Scan for hardcoded credentials** - Search for embedded static keys or PATs and confirm credentials are injected at runtime, scoped per tool. Done: no static secrets, injection is runtime and least-privilege.
4. **Run a tool-poisoning and description scan** - Run a description scanner and manually inspect any description, schema, or return value that could carry hidden instructions. Diff against the prior version. Done: no hidden or obfuscated directives.
5. **Review auth and scope** - Check per-client consent for proxies, audience validation, per-tool OAuth scopes, and confirm there is no token passthrough. Done: scopes least-privilege and identity bound per session via token exchange.
6. **Check update controls** - Confirm the version is pinned to the exact reviewed commit, auto-update is disabled, and releases are signed. Done: pin, disabled auto-update, and signed releases all in place.
7. **Isolate and test in staging** - Run the server sandboxed with a dummy credential and confirm human-in-the-loop for consequential actions. Done: expected behaviour under isolation, no privileged escape.
8. **Record the verdict** - Assign PASS, FAIL, or N/A per item, then connect, remediate, or reject. Archive the signed grading sheet against the exact commit. Done: verdict gates deployment and is stored.

The first five items are decisive. NimbleBrain names source verification, permission scope, clean stdout, error handling, and authentication security as the first five, and treats a server that fails any of them as a liability. If you have to triage, that is the priority order.

Some teams organise by domain rather than sequence. OWASP and FlowHunt group the same checks into five domains: strong identity and policy enforcement, strict isolation and lifecycle control, trusted and controlled tooling, schema-driven validation, and hardened deployment with continuous oversight. Knostic adds a formal submission by the requesting team before any technical review begins. Use whichever grouping your reviewers agree on, as long as every item ends with a recorded PASS, FAIL, or N/A.

## Turning the record into a connect, remediate, or reject verdict

The verdict is a function of two things: whether any first-five item failed, and whether the failures are fixable on your side. State the mapping so two reviewers grade the same case the same way.

- **Connect** when every item is PASS or a justified N/A. Nothing in the first five failed, credentials are per-tool scoped, and the version is pinned and signed.
- **Remediate** when failures exist but you can close them without the upstream: you can wrap the server in a scoped credential broker, pin an earlier clean commit, or add a gateway that enforces consent. Re-grade after the fix; the verdict is not "connect with caveats," it is "connect only once the remediation passes."
- **Reject** when a first-five item fails and you cannot fix it locally: no verifiable provenance, hardcoded secrets you cannot strip, token passthrough baked into the design, or an update pipeline you cannot pin.

#### The connect, remediate, or reject decision

Horizontal axis runs from You cannot fix it locally to You can fix it locally. Vertical axis runs from A first-five item failed to Only lower-priority items failed.

| Quadrant | What it means |
| --- | --- |
| Minor failure, upstream fix | Remediate: pin a clean commit or wrap it, then re-grade |
| Minor failure, you control it | Connect after applying the local mitigation and recording it |
| Critical failure, upstream only | Reject: no provenance, baked-in passthrough, or unpinnable updates |
| Critical failure, you control it | Remediate: broker the credential or gateway the consent, then re-grade |

*Plot the graded server by failure severity and whether you control the fix.*

> Compliant is not approved, and a scanner pass on stale code is worth nothing the day the tool updates.

MCP-specialist reviewers are scarce, which changes who can do this work. In Refolk's index of professional profiles, only 18 US profiles list Model Context Protocol as a skill under AI or platform engineer titles, and 17 of the 18 carry the title "AI Engineer." A broader keyword search returns 11 US profiles across employers including Zapier, PayPal, Workday, and Wipro. Outside the US the count is effectively zero.

| Market | MCP-skill profiles (eng titles) | MCP-keyword profiles |
|---|---|---|
| United States | 18 | 11 |
| Germany | 0 | 0 |
| United Kingdom | 0 (not queried by skill) | 0 |
| US share of the three | 100% (derived) | 100% (derived) |

Those are small absolute counts, which signal that MCP is a sparsely tagged, emerging skill rather than an absence of practitioners. The operational read: most teams cannot hire a dedicated MCP reviewer, so the grading bar has to be encoded as policy that any platform engineer can run, not held in one specialist's head.

I ran this search: `Engineers who have published or committed to open-source MCP servers on GitHub and also list OAuth or application security experience` - [see the full result list](https://www.refolk.ai/s/d5hvqqvxpf).

*Returns candidates who can both read MCP tool code and reason about credential scope, the two skills this review demands.*

If you do need to bring reviewer capacity in, [Refolk](/) turns that plain-English description into a shortlist across the public GitHub graph and public profiles, which is faster than filtering a keyword search by hand when the qualified pool is this thin.

## How this goes wrong: failure modes and false positives

Most bad MCP approvals are not missed checks; they are checks that returned the wrong answer. These are the specific ways a review produces a false PASS, and the local test that catches each one. This is the load-bearing part of the standard.

**1. Scanner false positives.** A raw "vulnerable" flag may be noise; one audit found a roughly 78% false-positive rate from YARA-based scanners. If you fail a server on an unreviewed flag, you reject safe tools and teach the team to ignore the gate. Check: manually review each flagged detection before recording a FAIL.

**2. Passing on a clean version, then rug-pulled.** A server can be graded PASS and silently change, because a server that can update its tool definitions can update its injection payload. The false positive is a green audit on stale code. Check: pin the exact reviewed commit and re-grade on every version bump.

**3. Advisory-not-blocking gates.** Security scanning treated as advisory rather than a blocking gate lets known-fail servers ship anyway. The verdict annotates the deployment instead of stopping it. Check: the verdict must gate deployment; a FAIL blocks connection until remediated.

**4. Token passthrough masquerading as scoped auth.** If the server forwards the user's token to the downstream API, it collapses two trust boundaries into one - the confused deputy vulnerability. The false positive is ticking "OAuth present." Check: confirm a token exchange to a downstream-scoped credential, not passthrough.

**5. Implicit tool poisoning surviving review.** Payloads survive casual review because they are not overtly malicious in isolation. A keyword scan will miss them. Check: diff descriptions against the prior version and scan for hidden or Unicode content, not just keyword matches.

**6. "Official-looking" typosquat.** Malicious servers are distributed with attractive naming and professional presentation, so a developer installs a seemingly legitimate tool with hidden exfiltration. The false positive is trusting a polished registry listing. Check: verify the canonical repo URL and maintainer identity, not the display name.

**7. Auto-execute IDEs bypass the gate entirely.** Leading IDEs including Cursor, Claude Code, Gemini CLI, GitHub Copilot, and Amazon Q auto-execute project-defined MCP servers with developer-level OS privileges and no process isolation. Your gate is irrelevant if a server never passes through it. Check: enforce approval at the gateway and run continuous discovery for shadow servers.

> **Watch out:** Green audit, changed payload
>
> The most common way this standard fails in practice is grading a commit that is not the one running in production. Record the verdict against a specific pinned commit hash. If the running version does not match the graded hash, the server is unapproved, full stop.

## Initial approval versus re-approval on upgrade

Initial approval grades the whole server; re-approval grades the delta and gets the same scrutiny. Never auto-update a server in production.

On every upgrade, before you accept it: check whether the new version introduces additional tools, requests broader OAuth scopes, or expands existing capabilities. Review every new tool and permission exactly as you did at first install. If you cannot explain why a new permission is necessary, do not grant it. Then pin the exact version, review release notes, test in staging, and keep a rollback path.

**MCP server grading sheet**

```
Server: __________   Repo (canonical URL): __________
Reviewed commit hash: __________   Grader: __________   Date: __________

1  Tool inventory + blast radius mapped ............ [ PASS / FAIL / N/A ]  evidence:
2  Source provenance / maintainer verified ......... [ PASS / FAIL / N/A ]  evidence:
3  No hardcoded secrets; runtime injection ......... [ PASS / FAIL / N/A ]  evidence:
4  Tool-poisoning + description scan clean ......... [ PASS / FAIL / N/A ]  evidence:
5  Per-tool scopes; no token passthrough ........... [ PASS / FAIL / N/A ]  evidence:
6  Version pinned, auto-update off, signed ......... [ PASS / FAIL / N/A ]  evidence:
7  Sandboxed staging test + human-in-the-loop ...... [ PASS / FAIL / N/A ]  evidence:

First-five failure? ___   Fixable locally? ___
VERDICT: [ CONNECT / REMEDIATE / REJECT ]   Remediation owner + re-grade date: __________
```

*One row per check. Record PASS, FAIL, or N/A with evidence. Store against the exact commit hash and the grader's name.*

## What to verify before you sign off

Run this final check before recording any CONNECT verdict. It is the minimum bar; anything unchecked is an open FAIL.

#### Sign-off checklist

- [ ] Every tool the server exposes is listed with its blast radius (secrets, files, network).
- [ ] The canonical repo and maintainer are confirmed, not a typosquat or display name.
- [ ] No static keys or PATs are embedded; credentials are injected at runtime and scoped per tool.
- [ ] Tool descriptions, schemas, and return values are scanned and manually diffed against the prior version.
- [ ] Auth uses a token exchange to a downstream-scoped credential, not passthrough of the user's token.
- [ ] The exact reviewed commit is pinned, auto-update is disabled, and releases are signed.
- [ ] The server was tested sandboxed with a dummy credential, with human-in-the-loop for consequential actions.
- [ ] The verdict is recorded against the pinned commit hash and gates deployment rather than annotating it.
- [ ] A re-grade is scheduled to fire on the next version bump.

## Keeping the standard current

The MCP threat landscape moves faster than any fixed number in this guide, so treat the scan statistics as a snapshot and re-check the mechanism, not the figure. The first malicious MCP package hit public registries in September 2025; new CVEs and new scanner benchmarks land continuously. Re-run your description scanner and re-read the OWASP MCP Security Cheat Sheet on a schedule, and subscribe to advisories for any server you have approved so a rug pull triggers a re-grade rather than a breach.

Two things will not change and should anchor your policy. Model alignment will keep failing against tool poisoning, so the server-side gate stays load-bearing. And the protocol will keep offloading security to the implementer, so "compliant" will never mean "approved." Encode the grading sheet as team policy, require the pinned-commit verdict before connection, and re-grade on every upgrade. That is the part of this standard that does not expire.

## Frequently asked questions

### Is a spec-compliant MCP server safe to connect?

No. The MCP specification states security cannot be enforced at the protocol level, so a fully spec-compliant server can still be unsafe. Compliance means the server speaks the protocol correctly, not that it is trustworthy. Every load-bearing check, from credential scoping to update control, is an implementation decision someone on your side has to own and verify before you connect.

### How do I check an MCP server for tool poisoning?

Run the server through a description scanner, then manually inspect every tool description, input schema, and return value for hidden instructions, including Unicode-obfuscated content. Diff the descriptions against the prior version rather than relying on keyword matches, because implicit payloads survive casual review by not looking overtly malicious in isolation. Treat any changed description on an update as a fresh review.

### Can I trust my agent's model to refuse a malicious MCP tool?

No. In the MCPTox benchmark the average tool-poisoning attack success rate across 20 agents was 36.5%, and the highest refusal rate was under 3%. More capable models were more vulnerable, not less, because the attack exploits superior instruction-following. Approval must assume the model will comply, which is why review has to happen before connection at the server-side gate.

### How is approving an MCP server different from re-approving an upgrade?

Initial approval grades the whole server against the full bar. Re-approval focuses on the delta: check whether the new version introduces additional tools, requests broader OAuth scopes, or expands existing capabilities, and review every new tool and permission with the same scrutiny you applied at install. If you cannot explain why a new permission is necessary, do not grant it. Pin exact versions and re-grade on every bump.

### What single check reduces the most risk?

Per-tool credential scoping. The credential's scope determines whether the worst case is reading one file or exfiltrating the production database. With 53% of audited servers using static keys and 79% passing keys via environment variables, confirming least-privilege, per-tool scopes with token exchange rather than passthrough is the highest-leverage control you can apply.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/mcp-server-approval-standard*