Agent & MCP supply-chain trust API

You approved an agent dependency you cannot vouch for

It reads a component's provenance, the permissions it requests and the instruction text inside it. You get back an allow, warn or deny verdict, stamped with the policy version and component digest that produced it.

Scan your agent stack View API docs

100 component scans/month free Paid from $99/month No card to run the scan here

Free component scan Ready

A component: what it claims, what it asks for, what it says.

Runs the same engine the paid endpoint uses. Nothing is stored and no key is needed.

Press “Scan component” to call the live API.

The problem

Every component in your agent stack is there because someone trusted it

Usually on a name, a version and a star count. Three things that decision did not have in front of it:

You cannot see what it can do

A manifest gives you a name and a version. It does not tell you the component can execute processes, reach the network and read credentials — the combination that turns a dependency into a foothold.

The postmark-mcp backdoor reached roughly 300 organisations before it was caught. September 2025.

You cannot tell where it came from

Unsigned artifacts, unverified publishers, no declared source repository. When nothing links the published build to source, 'we reviewed it' means you reviewed something you cannot now identify.

30+ CVEs were filed against MCP infrastructure in a single 60-day window. January–February 2026.

The dangerous part is prose, not code

Prompt-injection and exfiltration payloads sit in MCP tool descriptions and SKILL.md files — text that code scanners walk straight past, because it is not code.

Snyk examined 3,984 agent skills: 36% carried security flaws, 13.4% critical. OWASP published an Agentic Skills Top 10 in April 2026.

Those figures describe the ecosystem your agents install from. They are published findings about MCP and agent components generally — not results claimed for this service, which launched days ago.

The consequence

Months later, someone asks why you allowed it

An incident review, an auditor, or a customer's security questionnaire does not ask whether a component looks risky today. It asks what you decided, under which rule, against which exact build — and it usually asks after the engineer who approved it has moved on.

Re-running a scanner does not answer that question. Scanners change their rules, publishers republish under the same tag, and a fresh result is evidence about today, not about the decision you made last quarter. A screenshot of a dashboard is not a record either.

So the exposure is two-sided: the component you should not have trusted, and the fact that you cannot reconstruct why you did.

The solution

The scan is commoditized. The verdict is the product.

Scanning is largely free and getting freer — Snyk's agent-scan is Apache-2.0, Socket's free tier includes API access. Keep using them. What none of them hands you is a durable enforcement record, and that is the thing an audit actually asks for.

What a free scanner returns

A list of findings, produced by today's rules against whatever the registry serves today. Genuinely useful input. It is not a record of a decision, it names no policy, and it will not reproduce once the rules move.

What a verdict returns

decision, reasons[], policyVersion, componentDigest, riskScore. What your organisation allowed, under which policy, against which exact build. Replay the same policy against the same component in eleven months and you get the same answer.

Findings are the input. You can even bring your own. The verdict is what you keep.

Worked example

A component with flawless provenance, denied

Signed. Publisher verified. Source repository declared. It asks for exactly two permissions. This is the real response body from POST /v1/verdicts.

{
  "verdict": {
    "decision": "deny",
    "reasons": [
      "exec_with_network"
    ],
    "policyVersion": "default-v1",
    "componentDigest": "sha256:862aa28183e905d63f64ca29917779702726af9117960ce5a3537cf53dfb94ce",
    "riskScore": 40,
    "scannedAt": "2026-08-30T14:02:11.884Z"
  },
  "scan": {
    "component": {
      "kind": "mcp_server",
      "name": "acme-notify-mcp",
      "version": "2.4.1"
    },
    "riskScore": 40,
    "findings": [
      {
        "code": "exec_with_network",
        "severity": "critical",
        "facet": "permissions",
        "message": "Component can both execute processes and reach the network — sufficient to fetch and run arbitrary code.",
        "evidence": "permissions[]=\"process.exec\"+\"network.outbound\""
      }
    ],
    "severityCounts": {
      "critical": 1,
      "high": 0,
      "medium": 0,
      "low": 0
    },
    "scannedAt": "2026-08-30T14:02:11.884Z"
  },
  "requestId": "7f3c1a92-4e5b-4d18-9a06-2c8f1b7e0d33"
}

Why it denied at a risk score of 40

The deny threshold is 70. On score arithmetic alone this component installs with a note attached — and that is precisely the calibration error. Severity gates run before the score.

Warn — score arithmetic alone

40 clears the warn threshold of 35 but sits below the deny threshold of 70. One critical finding weighs 40. Arithmetic lets it through.

Deny — severity gate applied first

process.exec plus network.outbound is enough to fetch and run arbitrary code. That is categorical, not a number to be offset by good provenance. Any single critical finding denies.

The thresholds still catch the opposite failure: an accumulation of medium and low findings that each look tolerable and together are not. And credentials.read or an exfiltration marker denies outright under denyOnCodes, however clean everything else looks.

How it works

Scan, decide, record

Describe the component
Kind, name, version, its provenance claims, the permissions it requests, and any instruction text — an MCP tool description, a SKILL.md. Analysis is static: nothing is installed and nothing is executed.
Get findings across three facets
Provenance, permissions, and the instruction surface where injection and exfiltration markers concentrate. Every finding quotes the exact matched text as evidence, never a paraphrase, so a reviewer can dismiss a false positive in one look.
Apply your policy and keep the record
Set your own thresholds and categorical deny codes. The verdict comes back with the policy version and a SHA-256 component digest, so it can be replayed and defended later.

CI and release gates

Fail a pipeline on a deny verdict. Batch-scan every dependency in a build with one call.

Agent platforms and MCP gateways

Decide at install time whether a server or skill is permitted, and keep the record of why.

Security review and procurement

Answer 'what did we approve, and when' with a reproducible artifact rather than a screenshot.

Developer integration

Small surface, versioned, OpenAPI-first

Authenticate with Authorization: Bearer <key>. Every error returns a stable code and a requestId you can quote.

POST/v1/verdictsThe billable artifact. Scan and apply a policy; returns an allow/warn/deny with a replayable digest.

POST/v1/scansScan one component. Returns findings and a risk score.

POST/v1/scans/batchScan up to 100 components in one call. Quota cost scales with the batch.

POST/v1/demo/scanPublic. Runs the real scanner and default policy. No key required — it powers the panel above.

curl -X POST https://agentsupplytrust-api.com/v1/verdicts \
  -H "Authorization: Bearer $SUPPLY_TRUST_KEY" \
  -H "content-type: application/json" \
  -d '{"component":{"kind":"mcp_server","name":"acme-notify-mcp","version":"2.4.1"}}'

Full reference in the API docs, machine-readable spec at /openapi.json. Start a free key with POST /v1/keys: it emails a one-time token, and POST /v1/keys/claim exchanges that token for the key.

Pricing

Priced per component scan, capped so a runaway job can’t surprise you

Start free with 100 component scans a month, no card. Every paid plan includes an allowance, then a per-unit overage that is hard-capped per billing period — so your worst-case bill is the base price plus the cap, never more.

Developer

$99 /month

2,000 component scans included
$0.05 per additional component scan
Overage capped at $200 per period
Full API access, Python and TypeScript SDKs

Start with this plan

Scan something you already depend on

Paste a real MCP server, package or skill into the panel above and read the verdict. 100 scans a month, free, no card.

Get Free API Key Scan your agent stack Read the API reference

One email address, no password, no card: the key is waiting on the other side.

FAQ

Questions

How is this different from free scanners?

It is not trying to beat them at scanning. Free tools give you findings; this returns a policy decision with a version and a digest, which is the artifact an audit or incident review needs. You can feed it findings from anywhere.

What is a component scan?

One component evaluated once. Batch calls cost one unit per component, so a 50-dependency pipeline run bills 50 — never one.

Can I set my own policy?

Yes. Send thresholds and categorical deny codes with the request. The verdict records which policy version produced it, so a decision made under an older policy stays explainable after you tighten it.

Do you execute the component?

No. Analysis is static: declared provenance, requested permissions and instruction text. Nothing is installed or run.

Why does a verdict deny below the deny threshold?

Severity gates before score. A single critical finding denies regardless of the number, because properties like 'can execute processes and reach the network' are categorical — no amount of good provenance offsets them. See the worked example above.

You approved an agent dependency you cannot vouch for

Every component in your agent stack is there because someone trusted it

You cannot see what it can do

You cannot tell where it came from

The dangerous part is prose, not code

Months later, someone asks why you allowed it

The scan is commoditized. The verdict is the product.

What a free scanner returns

What a verdict returns

A component with flawless provenance, denied

Why it denied at a risk score of 40

Scan, decide, record

Describe the component

Get findings across three facets

Apply your policy and keep the record

CI and release gates

Agent platforms and MCP gateways

Security review and procurement

Small surface, versioned, OpenAPI-first

Priced per component scan, capped so a runaway job can’t surprise you

Scan something you already depend on

Questions