Landon Nesbitt

I find supply-chain and agent-security weaknesses that current tooling misses — then build read-only detectors and reproducible research to prove them.

Two representative pieces of work are below: a scanner for MCP registry supply-chain attacks with a bounded, re-runnable snapshot, and a hands-on penetration test of a vulnerable LLM agent.

Featured research

The MCP supply chain's real blind spot isn't malware — it's the credentials you hand to closed gateways

A read-only scan of 29,606 MCP servers across four registries, and what it did and didn't find.

The Model Context Protocol now has a supply chain: public registries listing thousands of servers an AI agent can install and grant access to. That makes it a target for the same attacks that hit npm and PyPI — and the official registry, by its own documentation, does not screen server code. I built mcp-registry-audit, a read-only scanner for the two attack shapes specific to how MCP works, and ran it against a single bounded snapshot.

The scan found no source-readable malicious server. The more useful result is what it surfaced on the way: a large, growing class of hosted aggregator gateways that route your real API keys through closed servers. Their public connector code is clean pass-through; their credential handling is, by construction, invisible to static analysis. That gap — not malware in published code — is the part of the MCP supply chain that current scanning cannot see.

The core finding

Closed credential gateways

The strongest brand-named candidates in the scan kept resolving to the same architecture. They weren't standalone packages you install and run — they were thin front-ends for hosted gateways: you hand the gateway your real API key (your Stripe secret, your GitHub token), and the actual server logic runs on the provider's closed infrastructure.

Here is the asymmetry, and it is the actual finding: the public connector code reads clean — and that tells you nothing about what the closed gateway does with your key. Static analysis, the entire basis of supply-chain scanning, can confirm the published code passes your token straight through with no logging and no second destination. It cannot see what the gateway does after it receives that token. "Clean by static analysis" is not "clean" — it is "not statically falsifiable," and for a credential-proxying gateway those are very different statements.

This isn't an accusation against any one provider — several are plainly legitimate. It's a structural point: the ecosystem is normalizing a model where you grant production credentials to closed third-party servers that can't be verified by the tools we use to verify everything else — and almost no one is naming it as the distinct trust problem it is. A related pattern worth watching: OpenAPI-to-MCP generators let a single org mass-produce, on the order of a thousand, near-identical templated connector wrappers, inflating registry counts and pre-staging brand-adjacent namespaces at scale.

The tool

What the scanner detects

Two pipelines over a shared, cached, read-only fetch core. It only reads public metadata — it never installs, executes, imports, or contacts anything it analyzes; every URL or sink found in a package is treated as an inert string to be scored, never reached. Every candidate score traces to a named signal with its evidence, so a human confirms or dismisses each by reading the source.

Snapshot results

A bounded, re-runnable census

Scope, stated plainly. This snapshot covers four registries; mcp.so was not included in this run. Coverage is also uneven by design — the official and Glama registries expose repos and packages, so detectors ran at full strength there, while community registries exposed only names and publishers. Treat this as a prevalence upper-bound at a moment in time, not a clean bill of health: a rug-pull appears after approval, so one snapshot structurally can't catch future drift. The scanner scales to more registries and more servers with a longer run — this is a bounded first census, published with its date and per-registry coverage so anyone can re-run it.

Across this snapshot, neither detector fired on any server whose source was readable. That is an absence-of-evidence result, not proof the ecosystem is safe — but it did establish that the most-vetted majority of the population contained no readable malicious lookalike or rug-pull at snapshot time, and it pointed straight at the closed-gateway problem that can't be dismissed by scanning at all.

Selected work

Tooling & assessments

Services

Two ways to get your agent assessed

External and artifact-based — I work from public data and what you share (your server list, your config). No access to your systems, codebase, or credentials required. Fixed scope, fixed price, fixed deliverable.

Methodology. Findings are scored with CVSS v3.1 and mapped to the OWASP Agentic AI Threats & Mitigations taxonomy (T1–T15) — the agent-specific framework, distinct from the general OWASP LLM Top 10. Every finding traces to specific evidence and a named threat class. Not included (so scope stays clear): full application penetration testing, whole-codebase source audit, anything requiring authorized access to your systems, and ongoing monitoring — those are separate engagements.