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 in this report. The cohort is only agents FindAgent actually scanned and human-reviewed, so the numbers reflect our own pipeline, not someone else’s directory.

Research · as of August 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.

What our review found

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

112

Agents reviewed

112

Passed the scan clean

Flagged by the scan

Anonymized count of reviewed agents in which each class of security finding appeared. Groups too small to be anonymous are suppressed.
What the scan caught	Agents
Embedded credential An API key, token, or private key pasted directly into a manifest instead of a bound credential slot.	0
Prompt-injection / exfiltration text Instruction-shaped text that tries to override a model or exfiltrate a conversation or credentials.	0
Unbound or unsafe tool target A tool action that would send a credential to a host it is not bound to, or targets a private / internal / cleartext endpoint.	22
Obfuscated / encoded payload Large base64 / hex / unicode-escape blobs or decode primitives used to hide content.	0
Hidden-Unicode smuggling Invisible 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.

What 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 a recipe whose prompt runs 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 agents FindAgent actually reviewed — never the external directory listings we index from a public MCP registry. Those are auto-ingested, unvetted, and clearly labeled "not reviewed by FindAgent"; counting them would overstate what we checked, so they are excluded from every number here.
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.

See it on each agent

Every agent’s page shows plain-language security facts drawn from its own definition — whether it ships code, the exact hosts your keys can reach, and which tools can change or delete data. The security model spells out each rule and what it does not cover.

Read the security model Browse agents

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 a young, free public beta. 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 a local code agent you download and run yourself, FindAgent doesn’t run or inspect that code — so it isn’t part of this review data.

Comparing marketplaces? See FindAgent vs other MCP marketplaces