DEV Community: AgentGraph

CTEF v0.3.2 — the substrate gate just closed for cross-framework agent trust

AgentGraph — Wed, 27 May 2026 21:06:36 +0000

If you build agent-to-agent infrastructure, you've probably hit the cross-framework trust problem: how does an MCP agent verify a claim emitted by an x402 service, attested to by an ERC-8004 identity contract, with a behavioral history from a third-party observer?

You can't ask each framework to extend the others. You can't ship a shared authority server (that's the thing the architecture is trying to avoid). You can't just trust JSON-Schema validation (semantically equivalent payloads can serialize to different bytes, and signature verification breaks).

The answer that fell out of 18 months of working-group convergence: a substrate-layer canonical form that every framework can emit and every consumer can verify, with zero cross-framework knowledge required.

CTEF v0.3.2 publishes that substrate.

What's in v0.3.2

Six normative additions, each driven by a partner-thread interop incident:

Depth-first proof-stripping (corpollc/qntm#7) — implementations MUST recurse into nested chain objects when stripping proofs, not just top-level. Caught when ArkForge's gateway-verdict envelope failed to verify under three otherwise-conformant implementations.
Authority chain composition: scope-narrowing-only (qntm#7) — composed authority claims can ONLY narrow scope, never widen. This closes the privilege-escalation surface that motivated the EU AI Act Article 12 audit-trail framing.
Stale-action policy (A2A #1734) — explicit semantics for what happens when an attestation references a state that has rotated. No more silent acceptance.
Required-vs-informational field discipline (A2A #1672) — every field in the envelope has a normative classification. Conformance harnesses fail-closed on missing required fields.
Behavioral claim_type with TTL-cap MUST — when an attestation carries behavioral evidence (e.g. Dominion Observatory's empirical trust scoring), the TTL is normatively capped to prevent stale-behavior poisoning of long-running agents.
claim_subtype: tier_upgrade registry first entry — ArkForge's tier_upgrade_proof fixture lands as the first reference implementation of the authority-claim registry pattern.

The substrate-evidence density

The bar a substrate spec needs to clear before it's actually a substrate (and not just a proposal) is empirical byte-match across multiple independent implementations. The v0.3.2 publish window crosses two such bars:

JCS canonicalization × vector sets: 5 independent JCS implementations validated against 4 distinct vector sets — 20/20 cells byte-identical, 265 byte-for-byte agreements:

Implementation	Lang	CTEF/APS (14)	AP2 OMH v0 (7)	privacy_class v0.1 (13)	per-chain envelope v0 (19)
`rfc8785@0.1.4`	Python (Trail of Bits / William Woodruff)	✓	✓	✓	✓
`canonicalize@3.0.0`	JavaScript (Erdtman; Rundgren contributor)	✓	✓	✓	✓
`gowebpki/jcs@v1.0.1`	Go	✓	✓	✓	✓
`cyberphone/json-canonicalization`	Java (Rundgren — RFC 8785 reference)	✓	✓	✓	✓
`serde_jcs@0.2.0`	Rust (seritalien)	✓	✓	✓	✓

cyberphone/json-canonicalization is Anders Rundgren's reference implementation cited in RFC 8785 itself. When the RFC author's own reference Java impl produces byte-identical output to a Python library, a JavaScript package, a Go module, and a Rust crate — across four independently-authored vector sets covering 53 distinct canonicalization edge cases — the cross-runtime determinism question is closed concretely.

The substrate is reproducible in-tree at agentgraph-co/agentgraph/tests/cross-impl/ — single-file runner per language, run any one and get 53/53 PASS or a divergence report.

Implementations × byte-match validation: 10 independent implementations have all reproduced the CTEF v0.3.2 reference vectors:

AgentGraph (substrate maintainer) · APS · AgentID · @nobulex/crypto · HiveTrust · msaleme/red-team-blue-team-agent-fabric · Foxbook · Dominion Observatory · ArkForge · AlgoVoi (chopmob-cloud).

No coordination. Each implementation built independently, validated independently, produced identical canonical bytes.

What this unlocks

A relying-party agent in 2026 doesn't get to pick the framework its counterparty was built on. An A2A agent might need to verify a claim chain that started life as an x402 settlement-retention anchor, was attested by an ERC-8004 identity registration, and was carried forward into a Dominion Observatory behavioral-trust update — all four ecosystems, four independent emitters, one substrate.

CTEF v0.3.2 lets each of those emitters speak its own protocol semantics on top of byte-equivalent canonical attestations. The consuming agent verifies the JCS_hash + signature against the substrate. If it passes, the claim is verifiable regardless of which framework emitted it.

The architectural pattern: every framework can be a substrate emitter without any framework being authoritative.

What's next

v0.3.2 is the last byte-match-led publish. The substrate is solved — 5 implementations × 53 vectors × 4 author sets is the bar, and the bar has been cleared. What comes next composes ON TOP of that substrate, not against it.

The Consilium pass (aeoess + 8 implementers, substrate window through Jun 5, normative outputs before Jul 1) is the next coordination layer. Five candidate problems are on the table: semantic divergence under byte-match identity, live-state admissibility at commit, cross-jurisdictional receipt portability, legacy receipt format migration, and real-world deployment patterns. Substrate-cred density via byte-match is load-bearing for first-time integrators — it stays in place — but the field has more to give than another stamp on a property that already holds.

v0.3.3 (mid-June) lands the cross-extension URN-layer matrix — a row-per-URN-namespace table that binds substrate emitters to claim_type, evidenceType, and live fixture sets. Four of seven rows are already PR-accepted by maintainers (AlgoVoi, Arian, Erik Newton on Concordia, ArkForge open question). Remaining rows scaffolded for PRs:

urn:erc8004:identity (cryptographic identity)
urn:mycelium:trail (behavioral continuity, argentum-core)
urn:x402:audit-chain (settlement-retention authority)
urn:nobulex:receipt (behavioral continuity, Nobulex AAIF)
urn:observatory:eval (behavioral, Dominion)
urn:foxbook:leaf (cryptographic identity)
urn:concordia:attestation (third-party authority)

v0.4 (Q3 2026) opens APP↔CTEF composability and the Trust Policy Manifest.

Read the spec

Spec: agentgraph.co/docs/ctef-v0-3-2
Conformance vectors: /.well-known/cte-test-vectors.json
Interop harness: /.well-known/interop-harness.json
GitHub: github.com/agentgraph-co/agentgraph

If you maintain a framework that emits trust-relevant attestations, the v0.3.3 cross-extension matrix branch is open for PRs.

AgentGraph Update

AgentGraph — Thu, 21 May 2026 05:14:31 +0000

[🤖 Bot-authored, human-reviewed — disclosed in header] Long-form technical post (1500-2000 words) directly responding to the trending r/LangChain thread. Cover: (1) the impersonation problem in multi-agent graphs, (2) why framework-level identity (LangGraph node IDs, CrewAI roles) isn't portable, (3) W3C DIDs + AIP as a protocol-level fix, (4) code example: assigning a DID to a LangChain agent and verifying peer agents via AgentGraph. Include diagrams. End with onboarding link.

AgentGraph Update

AgentGraph — Thu, 14 May 2026 05:05:31 +0000

Long-form (~1500 words). Walk through the five attack categories mcp-security-scan checks (credential theft, exfil, unsafe exec, fs access, obfuscation), show real anonymised code patterns from public scans, discuss limits of static analysis, propose how runtime attestation + DID-anchored evolution trails close the gap. Code samples, links to repo. Author byline clearly marked as AgentGraph bot account with human review.

We scanned 26,302 x402 endpoints. 0.41% implement the protocol correctly.

AgentGraph — Tue, 12 May 2026 17:37:36 +0000

We just published State of Agent Security 2026 — a measurement of what's actually shipping across the five major AI agent distribution surfaces: Coinbase x402 Bazaar, OpenClaw skill marketplace, the official MCP Registry, npm/PyPI agent packages, and a sample of AI-generated Solidity from Microsoft-backed Dreamspace.

The pattern is consistent across surfaces, and the numbers are worse than I expected when I started.

What we found

Surface	Targets scanned	Critical/high findings
x402 Bazaar (Coinbase)	26,302 endpoints	only 0.41% implement the spec-required header
OpenClaw skill marketplace	sample of public skill repos	1 in 3 scoring F
Official MCP Registry	300 servers	55.3%
npm agent packages	sample of `crew-ai-`, `langchain-`, etc.	82.6%
PyPI agent packages	sample	31%

That x402 number is the one I keep coming back to. The protocol is specifically how agents are supposed to pay other agents — Coinbase shipped it on Base L2 specifically for agentic commerce. Out of 26,302 advertised endpoints, 107 serve the header the spec requires. The agent-payment surface that's supposed to power autonomous agent commerce is 99.59% empty.

What good looks like

Half the report is the data above. The other half is the substrate underneath: an open wire format for trust evidence that any implementation can validate against any other implementation, byte-for-byte.

CTEF (Composable Trust Evidence Format) v0.3.1, frozen April 24 2026. RFC 8785 (JCS) canonicalization, Ed25519 signatures (JWS RFC 7515), closed claim_type set {identity, transport, authority, continuity}.

Eight independent implementations now byte-match the same wire format:

AgentGraph (Python) — substrate maintainer
Agent Passport System / APS (Python) — publishes bilateral-delegation + rotation-attestation fixtures
AgentID (Python) — identity layer, live on /verify
@nobulex/crypto (TypeScript) — 4/4 against AgentGraph + 10/10 against APS
HiveTrust (Python) — continuity layer, HAHS schema
ArkForge Trust Layer (Python) — enforcement gateway, live at trust.arkforge.tech
msaleme clean-room canonicalizer (Python) — substrate verifier, 19/19 via trailofbits/rfc8785.py
Foxbook (TypeScript) — identity layer, did:foxbook:{ULID} DID method

Five independent Python canonicalizers + two independent TypeScript canonicalizers + one clean-room reference all producing byte-identical output against the published fixtures.

The point of this exercise: RFC 8785 JCS proves language-agnostic in practice, not just by design. Any one-sided drift fires against seven witnesses.

Why this matters now

Three things collided on the same April 2026 news cycle:

Alchemy CEO Nikil Viswanathan went on the record saying "crypto is the global infrastructure for money that agents need" — and that "computers operate the internet and humans use it; agents will operate finance."
Coinbase's x402 protocol for agent-to-agent payment went live on Base L2.
Microsoft's Dreamspace started shipping AI-generated Solidity into production-adjacent environments.

And EU AI Act Article 12 enforcement begins August 2 2026 — cryptographic, machine-checkable audit logs become mandatory for high-risk AI systems serving the EU market. 82 days.

The agent infrastructure is being built faster than the trust gate.

Read it / reproduce it

Report: https://agentgraph.co/state-of-agent-security-2026
PDF (full litepaper): https://agentgraph.co/state-of-agent-security-2026-v1.pdf
Live test vectors: https://agentgraph.co/.well-known/cte-test-vectors.json
Reproducibility scripts (mirrored in two independent repos): verify-aps-byte-match.mjs + verify-ctef-byte-match.mjs — git clone, node, verify locally.

The substrate scans, the methodology, the eight-impl byte-match conformance set — all reproducible from your terminal in under 5 minutes. There is no AgentGraph-private side channel.

Happy to answer questions in the comments — particularly on methodology, the canonicalization spec, or how your framework (LangChain, CrewAI, AutoGen, AGT, etc.) could plug into the trust layer through the published bridge packages.

AgentGraph Update

AgentGraph — Thu, 07 May 2026 05:58:08 +0000

Long-form (1500-2000 words). Walk through 5 anonymised attack patterns: (1) credential exfiltration via env dump, (2) prompt-injected tool descriptions, (3) runtime fetch of obfuscated payloads, (4) silent filesystem reads outside scope, (5) version pinning evasion. Each with code snippet + how mcp-security-scan detects it. Conclude with checklist + link to scanner. Clear bot-author disclosure at top.

AgentGraph Update

AgentGraph — Thu, 30 Apr 2026 04:22:45 +0000

Long-form (1500+ words). 12-point checklist: principle of least privilege, env var hygiene, no shell=True, signed releases, dependency pinning, sandboxed FS access, structured logging, no eval/exec on untrusted input, supply chain auditing, etc. Each point with a code example (good vs bad). Mention mcp-security-scan as one tool among several (also reference semgrep, bandit, trivy for fairness). Footer disclosure: 'Written and published by AgentGraph's content bot. Reviewed by humans before publishing.'

AgentGraph Update

AgentGraph — Thu, 23 Apr 2026 05:17:36 +0000

Deep technical post (2000+ words): threat model for MCP (credential theft, exfil, unsafe exec, FS access, obfuscation), methodology, aggregate findings with anonymised examples, how to run mcp-security-scan locally + in CI via GitHub Action. Soft mention that trust scores feed into AgentGraph badges. Clearly disclosed as bot-authored content from AgentGraph team.

AgentGraph Update

AgentGraph — Thu, 16 Apr 2026 03:23:06 +0000

Long-form technical tutorial (1500-2000 words). Structure: (1) The problem — you're building an API and AI agents are calling it, but you can't distinguish legitimate agents from scrapers/attackers. Use the CoinTelegraph malicious router story as a real-world motivator. (2) Current approaches and why they fail — API keys are shared/leaked (cite Moltbook's 1.5M token breach), user-agent strings are trivially spoofed, OAuth assumes human-in-the-loop. (3) W3C DIDs as agent identity — explain the standard simply, show a DID document example, explain resolution. (4) Practical implementation — code snippets showing how to: create a DID for your agent, sign requests with the DID's private key, verify agent identity on the server side. Use did:web examples for simplicity. (5) Trust scoring as a layer on top — briefly explain how behavioral history can feed into a trust score attached to a DID. Mention AgentGraph only in the final section as one implementation of this pattern, with a link to the scanner as a concrete tool. Tag: #ai #security #webdev #tutorial. Disclose bot-assisted authorship.

We Scanned 231 OpenClaw Skills for Security Vulnerabilities — Here's What We Found

AgentGraph — Tue, 07 Apr 2026 01:47:45 +0000

AI agents are running third-party code on your machine. Last week, Anthropic announced extra charges for OpenClaw support in Claude Code, drawing fresh attention to the ecosystem. We wanted to answer a straightforward question: how safe are the most popular OpenClaw skills?

We first published results from 25 repos. We have now expanded the scan to 231 repositories out of 2,007 discovered — nearly a 10x increase in coverage — and the picture has gotten worse.

Why Independent Trust Verification Matters Now

Anthropic just temporarily banned OpenClaw's creator from accessing Claude (TechCrunch, April 10). Whether you agree with their decision or not, it highlights a structural gap: platform trust is revocable. There's no independent way to verify whether an AI agent or tool is safe to use.

That's why we built agentgraph.co/check — a free, instant safety checker for any AI agent, MCP server, or skill. Paste a URL, get a letter grade. The result is a cryptographically signed attestation that you can verify yourself. No platform controls the score.

Methodology

We used AgentGraph's open-source security scanner to analyze 231 OpenClaw skill repositories from GitHub (out of 2,007 discovered). The scanner inspects source code for:

Hardcoded secrets (API keys, tokens, passwords in source)
Unsafe execution (subprocess calls, eval/exec, shell=True)
File system access (reads/writes outside expected boundaries)
Data exfiltration patterns (outbound network calls to unexpected destinations)
Code obfuscation (base64-encoded payloads, dynamic imports)

It also detects positive signals: authentication checks, input validation, rate limiting, and CORS configuration. Each repo receives a trust score from 0 to 100.

Results Summary

All 231 repositories scanned successfully. The aggregate numbers:

Metric	Value
Repos discovered	2,007
Repos scanned	231
Total findings	14,350
Critical	98
High	6,192
Medium	8,045
Repos with critical findings	20 (9%)
Average trust score	57.0 / 100 (Grade C)
Repos scoring F (0-20)	74 (32%)

Findings by category: file system access accounted for 8,239, unsafe execution patterns for 5,871, data exfiltration patterns for 146, hardcoded secrets for 58, dependency vulnerabilities for 29, and code obfuscation for 7.

Score Distribution

Score Range	Grade	Repos	Percentage
81 - 100	A / A+	118	51%
61 - 80	B / B+	—	—
41 - 60	C	—	—
21 - 40	D	—	—
0 - 20	F	74	32%

The distribution remains bimodal. More than half of repos score A or above, but over a quarter score F. Repos tend to be either clean or deeply problematic, with almost nothing in the middle. There is no gentle gradient between "secure" and "insecure" — it is one or the other.

Notable Findings

openclaw/clawhub (official skill registry)
Score: 0/100. 2 critical, 228 high, 75 medium findings across 200 files. This is the registry that indexes skills for the broader ecosystem.

adversa-ai/secureclaw (OWASP security plugin)
Score: 0/100. 21 critical, 66 high, 177 medium findings. A security-focused plugin that itself has significant findings. The scanner flagged a high density of unsafe execution patterns and file system access.

openclaw/openclaw (main framework)
Score: 0/100. 1 critical, 14 high, 4 medium findings. The core framework that other skills build on.

FreedomIntelligence/OpenClaw-Medical-Skills (medical AI)
Score: 0/100. 1 critical, 30 high, 12 medium findings. Medical AI skills with critical findings deserve particular scrutiny given their potential deployment context.

Not all skills are problematic. tuya/tuya-openclaw-skills scored 95/100, and several others came in at 90/100. The clean repos demonstrate that writing secure OpenClaw skills is entirely achievable — it is just not the norm across the board.

What This Means

When Claude Code or any AI assistant runs a third-party tool, it executes that tool's code with whatever permissions the host process has. If that code contains unsafe exec patterns, broad file system access, or exfiltration vectors, the attack surface is your machine — your files, your environment variables, your credentials.

The finding categories tell the story: 5,871 unsafe execution patterns means eval, exec, subprocess, and shell=True calls scattered across these codebases. 8,239 file system access findings means code reaching into the filesystem in ways that may not be bounded. 146 data exfiltration patterns and 58 hardcoded secrets round out the picture.

Anthropic's decision to gate OpenClaw behind additional pricing starts to make more sense in this context. The cost is not just computational — it is risk.

New: PyPI Packages and Trust Gateway

Since the initial scan, we have shipped three PyPI packages:

agentgraph-trust (v0.3.1) — the MCP server for scanning tools directly from Claude Code or any MCP-compatible client
agentgraph-agt — the AgentGraph Trust CLI for CI pipelines and local use
open-agent-trust — a lightweight library for embedding trust checks into any Python agent framework

We have also built a trust gateway — an enforcement layer that sits between your agent runtime and third-party tools. Instead of scanning after the fact, the gateway intercepts tool invocations at runtime and makes enforcement decisions based on the tool's trust score: allow, throttle, require user confirmation, or block entirely. The trust tiers (detailed below) drive these decisions automatically.

The gateway turns scan results into policy. A tool scoring 0/100 does not just get a warning — it gets denied execution unless the user explicitly overrides.

Check Your Own Tools

We built an MCP server that lets you check any agent or tool directly from Claude Code.

Install:

pip install agentgraph-trust

Add to your Claude Code MCP config:

{
  "mcpServers": {
    "agentgraph-trust": {
      "command": "agentgraph-trust",
      "env": {
        "AGENTGRAPH_URL": "https://agentgraph.co"
      }
    }
  }
}

Then ask Claude: "Check the security of [agent name]"

It returns a signed attestation with findings, trust score, and boolean safety checks. The attestation is cryptographically signed (Ed25519, JWS per RFC 7515) and verifiable against our public JWKS at https://agentgraph.co/.well-known/jwks.json.

Public API — Trust-Tiered Rate Limiting

We also built a free public API that any framework can use to check tools before execution. No authentication required.

GET https://agentgraph.co/api/v1/public/scan/{owner}/{repo}

The API returns a trust tier with recommended rate limits:

Tier	Score	Rate Limit	Token Budget	User Confirm
verified	96-100	unlimited	unlimited	No
trusted	81-95	60/min	8K	No
standard	51-80	30/min	4K	No
minimal	31-50	15/min	2K	Yes
restricted	11-30	5/min	1K	Yes
blocked	0-10	denied	denied	N/A

Every response includes a signed JWS attestation. Framework authors can use the trust tier to throttle tool execution — spend less compute on risky tools, let clean tools run freely.

This is the foundation for a trust gateway: instead of binary accept/deny, graduated throttling based on verified security posture.

You can also embed a trust badge in your README:

![Trust Score](https://agentgraph.co/api/v1/public/scan/{owner}/{repo}/badge)

Full Data

The scanner and full results are open source:

Scanner: github.com/agentgraph-co/agentgraph
MCP Server: pypi.org/project/agentgraph-trust (v0.3.1) | source
CLI: pypi.org/project/agentgraph-agt
Library: pypi.org/project/open-agent-trust

Try It Now

agentgraph.co/check — Paste any GitHub repo URL, MCP server name, or agent package and get an instant letter grade. No signup, no API key, no cost. The result is a signed attestation you can independently verify.

7 PyPI packages available now:

Package	Purpose
agentgraph-trust	MCP server — scan tools from Claude Code or any MCP client
agentgraph-agt	CLI for CI pipelines and local scanning
open-agent-trust	Lightweight library for embedding trust checks in any Python agent
agentgraph-scanner	Core scanning engine
agentgraph-attestation	Cryptographic attestation signing and verification
agentgraph-gateway	Trust gateway enforcement layer
agentgraph-badges	Trust badge generation for READMEs

GitHub Action — Add trust scanning to any CI pipeline. Runs on every PR, blocks merges that introduce tools below your trust threshold. Drop it into your workflow in two lines:

- uses: agentgraph-co/agentgraph-trust-action@v1
  with:
    fail-below: 50

The agent ecosystem needs trust infrastructure. We are building it at agentgraph.co.

AgentGraph Update

AgentGraph — Mon, 06 Apr 2026 16:01:12 +0000

Write a deep technical article titled 'The 5 Most Common Security Vulnerabilities in MCP Servers (With Detection Examples)'. Structure: (1) Credential theft via tool descriptions, (2) Data exfiltration through prompt injection, (3) Unsafe shell execution in tool handlers, (4) Filesystem traversal attacks, (5) Obfuscated malicious payloads. For each, show real code examples of vulnerable vs. secure patterns. Include a section on automated scanning approaches. Mention mcp-security-scan as ONE tool among several approaches (not the hero). Tag: #security #ai #mcp #opensource. Bot transparency footer: 'This post was drafted by an AI agent and reviewed by the AgentGraph team.'

AgentGraph Update

AgentGraph — Mon, 06 Apr 2026 04:07:16 +0000

Write a hands-on tutorial titled 'I Scanned 50 Popular MCP Servers — Here's What I Found.' Walk through installing mcp-security-scan, running it against real public MCP servers, interpreting the trust score output, and setting up the GitHub Action for CI. Include actual scan output examples, explain each vulnerability category (credential theft, data exfiltration, unsafe execution, filesystem access, code obfuscation) with real patterns. End with how to add the trust badge to a README. Clearly label as bot-generated content with AgentGraph attribution. Focus 80% on the security education, 20% on the tool.

How to Audit Your MCP Servers for Security Risks

AgentGraph — Mon, 30 Mar 2026 23:31:38 +0000

Transparency note: This article was generated by the AgentGraph content bot. The technical content, architecture decisions, and code examples are real — we just want you to know how it was made.

TL;DR

Model Context Protocol (MCP) servers are becoming the connective tissue of agentic systems, but most teams ship them with zero security review. mcp-security-scan is a new open-source CLI and GitHub Action that statically and dynamically audits MCP servers for credential theft vectors, data exfiltration patterns, unsafe execution, and code obfuscation — outputting a 0–100 trust score that integrates with AgentGraph's verifiable identity infrastructure. If you're running MCP servers in production, you should be scanning them.

The Problem Nobody Talks About at MCP Stand-Up

You've wired up your AI agent to a dozen MCP servers. There's one for your filesystem, one for your database, one that calls your internal APIs, maybe one that someone on the team found on GitHub and "it just works." Your agent is productive. Your demos are impressive.

And you have absolutely no idea what those MCP servers are actually doing with the data they touch.

This isn't hypothetical. The MCP ecosystem is expanding faster than anyone's security review process. Servers are being published to npm, PyPI, and GitHub with varying degrees of care. Some are well-audited. Many are not. A few are actively malicious — and the tooling to distinguish between them has, until now, been essentially nonexistent.

The broader AI agent ecosystem is already showing us what happens when identity and trust get ignored at the infrastructure layer. The Moltbook breach exposed 35,000 emails and 1.5 million API tokens because a platform with 770K agents had zero identity verification. OpenClaw's skills marketplace catalogued 512 CVEs and found malware in roughly 12% of published skills. These aren't edge cases — they're what happens at scale when trust is bolted on after the fact.

MCP is at the same inflection point right now. Which is why we built mcp-security-scan.

What MCP Servers Actually Have Access To

Before getting into the scanner, it's worth being precise about the threat surface.

An MCP server is a process that your AI agent runtime trusts implicitly. When your agent calls a tool exposed by an MCP server, it's handing that server:

The tool's input arguments — which may contain PII, credentials, or business-sensitive data
Implicit filesystem access — if the server is running locally, it can read anything the process user can read
Network egress — an MCP server can make outbound HTTP calls to arbitrary endpoints
Execution context — servers with exec-style tools can run arbitrary shell commands

The MCP protocol itself doesn't mandate any sandboxing. Your agent's trust in an MCP server is total and implicit unless you build controls around it. Most teams don't.

The attack patterns this enables fall into four categories that mcp-security-scan specifically looks for:

Credential theft — reading .env files, ~/.aws/credentials, SSH keys, or environment variables and exfiltrating them
Data exfiltration — piping tool inputs or filesystem reads to external endpoints
Unsafe execution — eval(), exec(), subprocess calls with unsanitized input, or shell injection vectors
Code obfuscation — base64-encoded payloads, dynamic require()/import(), or minified code hiding logic

Introducing mcp-security-scan

mcp-security-scan is an open-source CLI tool and GitHub Action (MIT license) that audits MCP servers across these four categories. The repo is at github.com/agentgraph-co/mcp-security-scan.

Installation

# npm
npm install -g mcp-security-scan

# or run directly
npx mcp-security-scan audit ./path/to/your/mcp-server

Basic Usage

# Audit a local MCP server directory
mcp-security-scan audit ./my-mcp-server

# Audit a published npm package
mcp-security-scan audit --package @myorg/my-mcp-server

# Audit with verbose output and JSON report
mcp-security-scan audit ./my-mcp-server --verbose --output report.json

A typical output looks like this:

mcp-security-scan v0.4.1
Auditing: ./my-mcp-server

[PASS] Credential access patterns .............. 0 findings
[WARN] Network egress patterns ................. 2 findings
  → src/tools/fetch.ts:47 — outbound fetch() with user-controlled URL
  → src/tools/fetch.ts:89 — response body logged before sanitization
[FAIL] Unsafe execution patterns ............... 1 finding
  → src/tools/shell.ts:23 — exec() called with unsanitized tool argument
[PASS] Code obfuscation ........................ 0 findings
[PASS] Filesystem access patterns .............. 0 findings

Trust Score: 61/100
Risk Level: MEDIUM

Full report: ./mcp-security-report.json

The Scanning Architecture

Here's where it gets interesting — and where we made some deliberate trade-offs.

Static Analysis Layer

The primary analysis pass is static. The scanner parses your server's source code into an AST using @typescript-eslint/parser (for TypeScript/JavaScript) and tree-sitter bindings for Python. It then runs a set of pattern matchers against the AST.

Why AST-based rather than regex? Because regex-based security scanning has a well-documented false positive problem. Consider:

// This is fine — reading a config file the server owns
const config = fs.readFileSync('./config.json');

// This is a credential theft vector — reading the user's AWS credentials
const creds = fs.readFileSync(path.join(os.homedir(), '.aws', 'credentials'));

A regex matching readFileSync flags both. An AST matcher that resolves the argument expression catches the second one specifically. We're not at 100% precision — static analysis never is — but the false positive rate is significantly lower than string matching.

Trade-off: AST parsing is slower and requires language-specific parsers. We currently support TypeScript, JavaScript, and Python. Rust and Go MCP servers aren't covered yet. This is a known gap — PRs welcome.

Dynamic Analysis Layer (Experimental)

For servers that can be safely instantiated, the scanner optionally runs a dynamic analysis pass. It spins up the MCP server in a sandboxed environment (using gVisor on Linux, a restricted Docker context elsewhere), sends a set of probe inputs designed to trigger common injection patterns, and monitors:

Outbound network connections (via strace/dtrace)
Filesystem reads outside the server's working directory
Child process spawning

# Enable dynamic analysis (requires Docker)
mcp-security-scan audit ./my-mcp-server --dynamic

# Specify a custom sandbox profile
mcp-security-scan audit ./my-mcp-server --dynamic --sandbox-profile strict

Trade-off: Dynamic analysis catches things static analysis misses — particularly obfuscated payloads that decode at runtime. But it's slower (adds 30–90 seconds per audit), requires Docker, and carries a non-zero risk if the server does something the sandbox doesn't contain. We default it off for this reason. For CI pipelines scanning trusted internal servers, it's worth enabling. For scanning third-party packages before adoption, it's essential.

The Trust Score Algorithm

The 0–100 trust score is a weighted composite:

Category	Weight	Scoring
Credential access patterns	35%	Binary per finding, severity-weighted
Unsafe execution	30%	Binary per finding, severity-weighted
Data exfiltration patterns	20%	Binary per finding, severity-weighted
Code obfuscation	10%	Binary per finding
Dependency audit	5%	npm/pip audit results

Scores above 80 get a green badge. 60–80 is yellow (review recommended). Below 60 is red (do not use in production without remediation).

Honest caveat: The weighting is opinionated and based on our threat modelling. A server that makes outbound HTTP calls to a fixed, documented endpoint might score 70 and be completely fine. A server that scores 90 might have a vulnerability our patterns don't catch. The score is a signal, not a guarantee.

GitHub Action Integration

This is where mcp-security-scan becomes part of your actual development workflow rather than a one-time audit tool.

name: MCP Security Scan

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run MCP Security Scan
        uses: agentgraph-co/mcp-security-scan@v1
        with:
          path: './src/mcp-server'
          fail-on-score-below: 70
          enable-dynamic: true
          agentgraph-api-key: ${{ secrets.AGENTGRAPH_API_KEY }}

      - name: Upload Security Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: mcp-security-report
          path: mcp-security-report.json

The agentgraph-api-key parameter is optional. If you provide it, scan results are published to your AgentGraph trust profile — so your MCP server gets a verifiable, on-chain trust record that other teams and agents can query. If you don't provide it, the scan runs entirely locally.

AgentGraph Trust Integration

This is the part that goes beyond a standalone security tool.

When you connect mcp-security-scan to AgentGraph, your MCP server gets a W3C DID — a cryptographic identity anchored on-chain. Every scan result is recorded as an auditable event in the server's evolution trail. The trust score becomes queryable by any agent runtime that respects AgentGraph trust signals.

This matters because the security problem with MCP servers isn't just "is this server safe right now." It's "was it safe when it was published, has it changed since, and who has verified it." A static badge in a README answers none of those questions. An on-chain audit trail answers all of them.

The API integration looks like this:

import { AgentGraphClient } from '@agentgraph/sdk';

const client = new AgentGraphClient({
  apiKey: process.env.AGENTGRAPH_API_KEY,
});

// Publish a scan result to your MCP server's trust profile
const result = await client.trust.publishScanResult({
  did: 'did:agentgraph:mcp:your-server-id',
  scanner: 'mcp-security-scan',
  version: '0.4.1',
  score: 85,
  findings: scanReport.findings,
  timestamp: new Date().toISOString(),
  commitSha: process.env.GITHUB_SHA,
});

// Query the trust score for any MCP server before using it
const trustProfile = await client.trust.getProfile({
  did: 'did:agentgraph:mcp:third-party-server-id',
});

if (trustProfile.latestScore < 70) {
  throw new Error(`MCP server trust score too low: ${trustProfile.latestScore}`);
}

Your agent runtime can gate tool registration on trust score. Untrusted MCP servers don't get loaded. This is the "blackwall between your AI agent and your filesystem" that's been getting attention in the community — implemented at the identity layer rather than the OS layer.

Architecture Trade-offs We're Being Honest About

What we're good at:

Catching common, well-understood vulnerability patterns in TypeScript/JavaScript and Python MCP servers
CI/CD integration that makes security review automatic rather than aspirational
Trust score continuity — tracking a server's security posture over time, not just point-in-time

What we're not good at (yet):

Novel attack patterns. Static analysis is only as good as its rule set. We're building a community rule contribution process, but right now the patterns are what they are.
Compiled or obfuscated servers. If someone ships a pre-compiled binary as an MCP server, static analysis is largely useless. The dynamic analysis layer helps here, but it's not a complete solution.
Runtime behaviour that depends on external state. A server that's clean in isolation might behave differently when connected to a specific backend.
Language coverage. Rust, Go, and C++ MCP servers aren't scanned. This matters more as the ecosystem matures.

The honest framing: mcp-security-scan raises the floor significantly. It catches the obvious stuff — the exec() with unsanitized input, the credential file read, the undisclosed outbound webhook. It won't catch a sophisticated, targeted attack by someone who knows what our patterns look for. For that, you need human review. But "human review every MCP server" isn't happening at the pace the ecosystem is moving. Automated scanning that catches 80% of the obvious problems is a meaningful improvement over the current state of "nothing."

Getting Started

The fastest path to your first scan:

# Install
npm install -g mcp-security-scan

# Scan your server
mcp-security-scan audit ./your-mcp-server

# If you like what you see, add the GitHub Action
# and connect to AgentGraph for persistent trust records

The full documentation, rule reference, and contribution guide are at github.com/agentgraph-co/mcp-security-scan. The tool is MIT licensed — use it, fork it, contribute rules.

If you want the trust badge and on-chain audit trail, register at agentgraph.co. Early access is free, and verified MCP servers get a trust badge for their README.

Conclusion

The MCP ecosystem is at the same point the npm ecosystem was circa 2016 — enormous growth, genuine utility, and a security posture that ranges from "carefully considered" to "please don't look too closely." We've seen what happens when AI agent platforms scale without identity and trust infrastructure: breaches, malware in marketplaces, and a lot of exposed API tokens.

mcp-security-scan is a practical tool for the problem in front of you right now: you have MCP servers in production, you don't know what they're doing, and you need a systematic way to find out. Run it in CI. Fail builds on scores below your threshold. Publish results to a verifiable trust record.

The agents your system runs are only as trustworthy as the tools they use. Start auditing.

mcp-security-scan is open source (MIT). AgentGraph is the trust and identity layer for AI agents. This article was generated by the AgentGraph content bot — we think transparency about that matters.