Early AccessEvery agent is free to connect — no card, no checkout.

Skip to content
FindAgent
Sign in
01Research · as of October 2026

The State of MCP Security

Anyone can publish an MCP server, and most public directories list thousands of them with no human ever looking. FindAgent takes the opposite approach: every agent passes an automated security scan and a human review before it can go live. This report is an honest look at what that review catches — the exact checks, and anonymized, aggregate results from our own pipeline. Every number is computed from our real review data or it isn’t shown; nothing here is estimated or inflated.

02What our review found

Across 21 agents FindAgent scanned and reviewed (external, unreviewed directory listings excluded), 21 passed the automated scan clean and 0 were flagged with a high or critical finding for a person to review. A clean scan is necessary but not sufficient — a person makes the final publish call either way.

21Agents reviewed
21Passed the scan clean
0Flagged by the scan
Embedded credentialAn API key, token, or private key pasted directly into a manifest instead of a bound credential slot.
0
Prompt-injection / exfiltration textInstruction-shaped text that tries to override a model or exfiltrate a conversation or credentials.
0
Unbound or unsafe tool targetA tool action that would send a credential to a host it is not bound to, or targets a private / internal / cleartext endpoint.
0
Obfuscated / encoded payloadLarge base64 / hex / unicode-escape blobs or decode primitives used to hide content.
0
Hidden-Unicode smugglingInvisible tag, bidirectional, zero-width, or control characters that can hide instructions from a human reviewer.
0

A cell reading <10 means the real count fell below our anonymity floor and was suppressed — never rounded or guessed. A count is shown only when it is zero or at least 10 agents.

03What every agent is checked for

Before an agent can publish, an automated scan runs over its entire definition. Every check below is real and runs on our servers — a high or critical finding fails the scan and holds the agent back for a human look.

Embedded credentials

Scans every text field for a leaked API key, token, or private key (AWS, GitHub, OpenAI, Anthropic, Stripe, Google, Slack, JWTs, PEM keys). A real embedded secret fails the scan — credentials belong in a bound slot, never inline.

Credential-to-host binding

Every tool action is checked against the credential it uses: the key may only be sent to the exact hosts that credential declares. A target the key can’t reach, a private / internal / loopback address, or a cleartext (non-HTTPS) endpoint is flagged.

Prompt-injection & exfiltration text

Flags instruction-shaped text that tries to override a model or exfiltrate a conversation, credentials, or tokens. For instructions that run verbatim in your own model, an exfiltration pattern fails the scan.

Obfuscation & hidden Unicode

Catches large base64 / hex-escape blobs and decode primitives, plus invisible tag, bidirectional, zero-width, and control characters that can smuggle hidden instructions past a human reviewer.

Manifest shape & duplicates

Validates the manifest schema, size, and slug, and rejects a duplicate of an existing agent. Malformed or oversized manifests are held for a human look rather than waved through.

Methodology

How the cohort is defined, how the numbers are produced, and how we keep them anonymous.

  • The cohort is the agents FindAgent SERVES and scans. Two other things are deliberately kept out of it. External directory listings we index from a public MCP registry are auto-ingested, unvetted and labeled "not reviewed by FindAgent" — counting them would overstate what we checked. And published MCP-server listings are pointers to servers their providers run: your client connects directly, we never execute them, and there is no code on our side to scan, so they carry no scan verdict and are counted separately above rather than folded in.
  • The scan runs on our servers over the full manifest and fails closed: any high or critical finding holds the agent back. A clean scan is necessary but not sufficient — a person still reviews every agent before it can publish. There is no auto-approval path for a non-admin submission.
  • Beyond the scan, the runtime applies a security floor a creator cannot turn off: a tool marked "read-only" whose action actually writes or deletes is corrected to write/destructive, so a mislabeled tool can never auto-run without your confirmation.
  • Every figure below is computed at page load from that real scan output, behind a k-anonymity floor: a number is shown only when its group is either zero or at least 10 agents. A group smaller than that is suppressed so no single agent or creator can be identified — we would rather show fewer numbers than a number that fingers one listing.
  • Because the figures are recomputed live rather than frozen, an observer who compares snapshots taken at different times could in principle infer how a count changed between visits; the k-anonymity floor still governs every published number, so any inference stays at the group level and never resolves to a single agent.

What we do not claim

Honest boundaries build more trust than a bigger-looking number.

  • These are counts of what our review caught, not proof any published agent is flawless. The review is about safety boundaries, not correctness or quality — read reviews and try an agent before relying on it.
  • We don’t publish per-agent findings, and we never will. Only anonymized, aggregate counts appear here, and any group too small to be anonymous is suppressed entirely.
  • FindAgent is young and in early access. The cohort is deliberately small, so the honest story here is mostly about method — what we check and how — with whatever aggregate numbers are large enough to publish safely. We do not inflate the sample or invent a figure to look bigger.
  • For an agent listed only as a pointer to an external server, or agent code you download and run yourself, FindAgent doesn’t run or inspect that code — so it isn’t part of this review data.
Read the security modelBrowse agents

Comparing marketplaces? See FindAgent vs other MCP marketplaces

Frequently asked questions

What does FindAgent’s MCP security review actually check?

Before an agent can publish, an automated scan runs over its whole manifest: it looks for embedded credentials (leaked API keys, tokens, private keys), checks that every tool action can only send a credential to the hosts it declares, flags prompt-injection and exfiltration text, catches obfuscated or hidden-Unicode payloads, and validates the manifest shape. Any high or critical finding fails the scan and holds the agent back, and a person reviews every agent before it can go live.

Are these MCP security numbers real, or estimated?

They are real. Every figure is computed at page load from FindAgent’s actual review output — the stored scan results for agents we reviewed — behind a k-anonymity floor. A number is shown only when its group is zero or at least 10 agents; smaller groups are suppressed so no single agent or creator can be identified. Nothing is hardcoded, estimated, or inflated, and external directory listings we index but never reviewed are excluded.

Does FindAgent count the thousands of MCP servers in public directories?

No. FindAgent indexes some listings from a public MCP registry, but those are auto-ingested, unvetted, and labeled "not reviewed by FindAgent." They are excluded from every figure here. The scan figures cover only the agents FindAgent serves and scanned. Published MCP-server listings — pointers to servers their providers run — are reported as their own number, because they pass a human review and no scan: there is no FindAgent-side code in them to scan. One figure for both would claim the scan for rows it never touched.