DEV Community: AgentAvow

AgentGraph is now AgentAvow

AgentAvow — Fri, 07 Aug 2026 23:51:35 +0000

Quick note: we've renamed AgentGraph to AgentAvow (agentavow.com). Same team, same product, sharper focus: signed, verifiable safety grades for the tools your AI agents connect to (MCP servers, packages, skills). Paste a URL, get a letter grade backed by a scan across 12 safety categories, plus a signed attestation anyone can recompute offline.

The public verification is unchanged: the attestation format, the CTEF namespace, and the JWKS are all the same, so your existing badges and receipts keep working, and agentgraph.co redirects to agentavow.com.

Check a tool: https://agentavow.com/check

How We Built Verifiable Agent Identity with DIDs — and Why the Moltbook Breach Should Scare You

AgentAvow — Thu, 06 Aug 2026 01:11:16 +0000

TL;DR: AI agent platforms without identity verification are a security disaster waiting to happen — and the Moltbook breach proved it. AgentGraph uses W3C Decentralized Identifiers (DIDs) to give every agent a cryptographic identity that's auditable, on-chain, and not owned by any single platform. Here's how we built it and what we got wrong along the way.

The Moltbook breach hit 35,000 emails and 1.5 million API tokens. 770,000 agents, zero identity verification. Meta acquired the platform, the breach happened, and suddenly every developer who had integrated Moltbook agents into their pipelines had to assume those agents were compromised. No audit trail. No way to know which agents had been tampered with. No cryptographic proof of anything.

That's the actual problem we're solving at AgentGraph.

OpenClaw has 512 CVEs and 12% of their skills marketplace has been flagged as malware. These aren't edge cases — they're what happens when you build agent infrastructure without identity as a first-class concern.

Why Agent Identity Is Different From User Identity

OAuth solves identity for humans. JWT handles session auth. X.509 certificates work for servers. None of these map cleanly to agents.

An agent isn't a user. It acts autonomously, often across multiple sessions, sometimes spawning sub-agents, sometimes being cloned or forked by other operators. The identity model needs to handle:

Persistence across sessions — the agent's identity shouldn't be tied to a single API session or runtime
Delegation — agent A can authorize agent B to act on its behalf, and that delegation needs to be verifiable
Evolution — an agent that gets new capabilities, a new model, or a new system prompt is still "the same agent" in some meaningful sense, but that change should be auditable
Portability — identity shouldn't be locked to one platform

W3C DIDs solve most of this. A DID is a globally unique identifier that resolves to a DID document containing public keys, service endpoints, and verification methods. The identifier itself is controlled by whoever holds the private key — not by a registry, not by a platform.

did:agentgraph:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

That's what an agent identity looks like on AgentGraph. The did:agentgraph method stores the DID document on-chain, which means resolution doesn't go through our servers. If we disappear tomorrow, your agent's identity still resolves.

The Architecture

Here's the high-level flow:

Agent Operator
     │
     ▼
AgentGraph SDK
     │
     ├── Generates keypair (Ed25519)
     ├── Creates DID document
     ├── Anchors to chain
     └── Returns DID + verification material

     │
     ▼
DID Document (on-chain)
{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:agentgraph:z6Mkha...",
  "verificationMethod": [{
    "id": "did:agentgraph:z6Mkha...#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:agentgraph:z6Mkha...",
    "publicKeyMultibase": "z6Mkha..."
  }],
  "service": [{
    "id": "did:agentgraph:z6Mkha...#agentgraph",
    "type": "AgentGraphProfile",
    "serviceEndpoint": "https://agentgraph.co/agents/z6Mkha..."
  }]
}

When agent A wants to verify it's talking to agent B, it resolves B's DID, gets the public key from the DID document, and checks that B's messages are signed with the corresponding private key. No central authority involved. No "trust us, we verified them."

Registering an Agent: The SDK Flow

Here's what registration looks like using the AgentGraph SDK:

from agentgraph import AgentGraph, AgentConfig

# Initialize the client
ag = AgentGraph(api_key="your-api-key")

# Register a new agent with a verifiable identity
agent = ag.agents.register(
    AgentConfig(
        name="data-pipeline-agent-v2",
        description="Processes and validates financial data streams",
        capabilities=["data-processing", "validation", "reporting"],
        operator_did="did:agentgraph:z6MkOperator...",  # your DID as operator
        model="gpt-4o",
        version="2.1.0"
    )
)

print(agent.did)
# did:agentgraph:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

print(agent.trust_score)
# 72  (starts lower, increases with verified activity)

# Sign a message as this agent
signed_message = agent.sign({
    "action": "process_batch",
    "batch_id": "batch-20260318-001",
    "timestamp": "2026-03-18T09:00:00Z"
})

# Another agent verifying that signature
verification_result = ag.verify(
    did="did:agentgraph:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
    message=signed_message.message,
    signature=signed_message.signature
)

print(verification_result.valid)  # True
print(verification_result.trust_score)  # 72
print(verification_result.audit_trail_url)  # Link to on-chain history

The operator_did field is where the human accountability chain starts. Every agent is registered by an operator, and that operator has their own DID. If an agent goes rogue, you can trace back to the operator who deployed it.

The Trust Score: What It Actually Measures

Trust scores are the part we've thought hardest about and gotten wrong in interesting ways.

The score (0-100) is a composite of:

Identity verification depth — just a DID, or DID + operator verification + source repo?
Behavioral consistency — does the agent do what its DID document claims it does?
Audit trail length — how much verifiable history exists?
Operator reputation — what's the trust score of the humans/orgs behind this agent?
Capability attestations — third-party verification of claimed capabilities

What we got wrong in v1: we weighted "age" too heavily. An agent that had been around for six months got a big trust boost just from longevity. That's wrong. A malicious agent that's been operating quietly for six months is more dangerous, not more trustworthy. We now weight behavioral consistency against claimed capabilities much more heavily.

The other thing we got wrong: we tried to make the score opaque, like a credit score. Developers hated it. Now every component is visible in the API response:

{
  "did": "did:agentgraph:z6Mkha...",
  "trust_score": 72,
  "components": {
    "identity_depth": 85,
    "behavioral_consistency": 78,
    "audit_trail": 65,
    "operator_reputation": 70,
    "capability_attestations": 60
  },
  "last_updated": "2026-03-18T08:45:00Z",
  "audit_trail_entries": 147
}

The Audit Trail Problem

Every change to an agent's capabilities, model, or system prompt gets recorded as an on-chain event. This is the "evolution trail" — the idea that you can see exactly how an agent has changed over time.

This matters because the Moltbook-style attack vector isn't just "steal credentials." It's "quietly modify an agent's behavior and wait." If you can't see that an agent's system prompt changed three weeks ago, you can't detect that attack.

The trade-off here is cost. On-chain writes aren't free. We batch non-critical updates and only write immediately for security-relevant changes (new keys, capability additions, operator changes). Minor version bumps get batched into daily writes. It's a compromise — a sophisticated attacker could theoretically modify an agent and wait for the batch window. We're honest about that.

The alternative was keeping the audit trail off-chain in our database. Faster, cheaper, but then you're trusting us. For a trust infrastructure platform, that's a bad look.

MCP Bridge and Tool Discovery

Agents don't just have identities — they use tools. The Model Context Protocol is becoming the standard way agents discover and call tools, and we've built a bridge that integrates DID-based identity into that flow.

When an agent discovers a tool through AgentGraph's MCP bridge, it gets the tool's DID, trust score, and audit trail alongside the normal MCP response. Before calling an untrusted tool, the agent can check:

Is this tool's DID document valid and resolvable?
What's the trust score?
Has this tool's behavior changed recently in unexpected ways?

We also open-sourced mcp-security-scan — a CLI and GitHub Action that scans MCP servers for credential theft vectors, data exfiltration patterns, unsafe execution, filesystem access, and code obfuscation. It outputs a trust score that integrates directly with AgentGraph trust badges.

# Scan an MCP server before integrating it
npx mcp-security-scan scan --server https://mcp.example.com/tools

# Output:
# Trust Score: 67/100
# ⚠️  Filesystem access detected (read: /tmp, write: none)
# ✅  No credential theft patterns found
# ✅  No data exfiltration vectors detected
# ⚠️  One obfuscated code block in tool handler
# 
# Full report: https://agentgraph.co/scan/abc123

The GitHub Action version runs in CI so you catch problems before deployment. It's MIT licensed because the goal is for this to become standard practice, not to lock anyone in.

Why On-Chain and Not Just a Database?

This is the question we get most often.

The honest answer: on-chain is slower, more expensive, and more complex to operate. We chose it anyway because the alternative — a database we control — creates a single point of failure and a single point of trust. If our database gets breached (see: Moltbook), all the identity records are compromised. If we get acquired and the acquirer has different incentives, the identity records can be modified.

On-chain means the DID documents are verifiable without going through our infrastructure. An agent can resolve another agent's DID using any DID resolver that supports the did:agentgraph method. We're not in the critical path for verification.

The cost is real though. We absorb chain write costs for registered agents and pass them through at scale. It adds latency to registration (seconds, not milliseconds). For high-frequency updates, it's genuinely limiting.

Some things we keep off-chain: the social graph visualization, detailed behavioral logs, the marketplace listings. Those live in a database. The cryptographic roots — keys, capability hashes, operator relationships — go on-chain.

What the Healthcare and Finance Verticals Are Teaching Us

A few teams building AI agents for healthcare have started using AgentGraph, and they've pushed us hard on one thing we hadn't fully thought through: agent delegation chains.

A healthcare agent might be: deployed by a hospital (operator), configured by a department (sub-operator), and used by a specific doctor (end user). The liability chain matters. When the agent makes a recommendation, who is cryptographically accountable?

We're building delegation proofs into the DID document structure — verifiable credentials that capture the full chain from operator to end user. It's not shipped yet. But the requirement is real and the W3C Verifiable Credentials spec gives us the building blocks.

The finance teams have a different problem: they need to prove to auditors that the agent that ran a transaction in January is the same agent (or provably different) from the one running transactions now. The audit trail solves this, but only if the auditors can read it. We're working on a human-readable audit report export that doesn't require understanding DIDs.

Getting Started

If you're building agents and you're not thinking about identity yet, the Moltbook breach is the argument. 1.5 million API tokens exposed because there was no cryptographic link between agents and their operators.

AgentGraph is live and free to register. You get a DID for your agent, a trust score, and access to the API and marketplace. The SDK supports Python and TypeScript, with more coming.

The mcp-security-scan tool is a good starting point even if you're not ready to commit to the full platform — run it against any MCP servers you're integrating and see what comes back.

Full docs, API reference, and early access registration are at agentgraph.co.

Disclosure: This post was generated with AI assistance and reviewed by the AgentGraph team. We think transparency about that is table stakes for a company whose whole thing is trust.

How to Audit Your MCP Servers for Security Risks

AgentAvow — Thu, 30 Jul 2026 00:15:25 +0000

TL;DR: MCP servers run with significant privileges inside AI agent pipelines, and most teams ship them without any security review. mcp-security-scan is an open-source CLI and GitHub Action that checks for credential theft patterns, data exfiltration, unsafe execution, and code obfuscation — and outputs a 0-100 trust score that integrates with AgentGraph's identity layer.

The Moltbook breach last year is still the clearest example of what happens when you scale agent infrastructure without thinking about trust. 770,000 agents, zero identity verification, and when it went down it exposed 35,000 emails and 1.5 million API tokens. The tokens were the real problem — many of them were credentials passed through MCP servers that nobody had audited.

MCP (Model Context Protocol) servers are the connective tissue of modern agent systems. They sit between your LLM and the outside world, handling tool calls, filesystem access, API requests. That position gives them a lot of power. It also makes them an obvious target.

And yet most teams treat MCP servers like they treat npm packages circa 2015: install and trust.

What Actually Goes Wrong

Before getting into the scanner, it's worth being specific about the threat categories. There are four that show up most often in real codebases:

Credential theft — MCP servers that read environment variables indiscriminately, log request/response payloads, or forward tool call arguments to external endpoints. This one is subtle because the server might be doing legitimate work and exfiltrating credentials.

Data exfiltration — Outbound HTTP calls to domains that weren't declared in the server's manifest, or calls that happen inside tool handlers where the LLM can influence the destination URL. Prompt injection into tool parameters is the attack vector here.

Unsafe execution — eval(), exec(), subprocess calls, or dynamic require()/import() where the argument comes from tool call input. If an LLM can influence what gets executed, you have a problem.

Filesystem access — Path traversal risks, reading outside declared directories, writing to sensitive locations. Especially bad in servers that accept filename parameters from the model.

OpenClaw's skills marketplace has 512 CVEs at last count, and roughly 12% of skills contain what their own security team classifies as malware. That's a marketplace that grew fast and audited slowly.

Introducing `mcp-security-scan`

mcp-security-scan is a CLI tool and GitHub Action for scanning MCP server source code and runtime behavior. It's MIT licensed, lives at github.com/agentgraph-co/mcp-security-scan, and produces a structured JSON report plus a 0-100 trust score.

Install it:

npm install -g mcp-security-scan

Basic scan against a local server directory:

mcp-security-scan scan ./my-mcp-server

Output:

{
  "score": 74,
  "findings": [
    {
      "severity": "HIGH",
      "category": "credential_theft",
      "rule": "env-wildcard-read",
      "file": "src/tools/search.ts",
      "line": 43,
      "message": "process.env spread into tool response object",
      "snippet": "return { ...process.env, results }"
    },
    {
      "severity": "MEDIUM",
      "category": "unsafe_execution",
      "rule": "dynamic-require",
      "file": "src/index.ts",
      "line": 112,
      "message": "require() called with non-literal argument",
      "snippet": "const mod = require(toolName)"
    }
  ],
  "passed": 18,
  "failed": 2,
  "agentgraph_trust_badge": "https://agentgraph.co/badge/mcp/..."
}

The score drops from 100 based on finding severity: HIGH findings cost 15 points each, MEDIUM costs 5, LOW costs 1. That's configurable via a .mcp-scan.json file if your threat model weights things differently.

Running It in CI

The GitHub Action is the more useful integration for teams that ship MCP servers regularly:

name: MCP Security Scan

on: [push, pull_request]

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

      - name: Scan MCP Server
        uses: agentgraph-co/mcp-security-scan@v1
        with:
          path: ./server
          fail-on-severity: HIGH
          min-score: 70
          agentgraph-api-key: ${{ secrets.AGENTGRAPH_API_KEY }}

The agentgraph-api-key is optional. Without it, you get the local scan results. With it, the score gets pushed to your agent's trust profile on AgentGraph, and your README badge updates automatically after each passing scan.

fail-on-severity: HIGH will exit with code 1 on any HIGH finding, blocking the PR merge. min-score: 70 does the same if the aggregate score drops below threshold. You can use one, both, or neither depending on how strict you want to be.

How the Scanner Works

The scan runs in two phases: static analysis and (optionally) dynamic analysis.

Static Analysis

Static analysis uses AST parsing via @typescript-eslint/parser for TypeScript/JavaScript servers and ast module for Python servers. The rules are pattern-based, not ML-based. That was a deliberate call.

ML-based detection would catch more subtle patterns, but it would also produce false positives that developers learn to ignore. A rule that says "flag process.env spread into any object that gets returned from a tool handler" is specific, auditable, and easy to suppress with a comment when you have a legitimate reason.

Every rule has a rule ID, a description, and a link to the rationale. If a finding doesn't make sense for your codebase, you suppress it explicitly:

// mcp-scan-disable-next-line env-wildcard-read
return { ...process.env, results }

That suppression gets logged in the report so reviewers can see what was intentionally skipped.

Current rule count: 34 rules across the four categories. The full list is in the repo's docs/rules.md.

Dynamic Analysis

Dynamic analysis is opt-in and requires Docker. It spins up the MCP server in a sandboxed container with network monitoring enabled, runs a set of synthetic tool calls, and records outbound connections.

mcp-security-scan scan ./my-mcp-server --dynamic

This catches things static analysis misses: obfuscated code that decodes at runtime, dependencies that phone home, servers that behave differently under specific input patterns.

The trade-off is obvious: it's slower (adds 30-90 seconds depending on server startup time), requires Docker, and can't catch everything — a server could behave differently with real LLM-generated inputs than with synthetic ones. But it catches the low-hanging fruit reliably.

The Trust Score

The 0-100 score is designed to integrate with AgentGraph's trust infrastructure. AgentGraph assigns W3C DIDs to AI agents and maintains auditable trust scores based on verifiable signals — scan results, deployment history, operator reputation. The scanner is one input into that system.

When you push scan results via the API key, they get recorded on-chain as part of the agent's evolution trail. That means you can show users of your MCP server a verifiable history of security scans, not just a static badge that could be faked.

This is the piece that distinguishes it from running ESLint with some custom rules. ESLint output lives in your CI logs. The trust score lives in a verifiable record that third parties can check before deciding whether to use your server.

Architecture Decisions and What We Got Wrong

A few honest notes on choices that didn't go perfectly:

The scoring formula is too simple. Flat point deductions per severity don't capture the difference between a HIGH finding in a core authentication handler versus a HIGH finding in a rarely-called utility function. We're working on a weighted scoring model that factors in code path reachability. The current version errs toward simplicity — a score you can explain beats a score that's accurate but opaque.

Python support is incomplete. The TypeScript/JavaScript rules are more mature. Python servers get about 60% of the rule coverage. If you're building Python MCP servers, the scanner will still catch the most common issues, but don't treat a passing score as a clean bill of health.

Dynamic analysis doesn't handle auth flows well. If your MCP server requires OAuth or API key setup before it will respond to tool calls, the dynamic scanner will time out waiting for initialization. There's a --dynamic-init-script flag that lets you provide a setup script, but it's clunky. This is on the roadmap.

The false positive rate on obfuscation detection is ~8%. Some legitimate minification patterns trigger the obfuscation rules. The fix is usually adding the file to .mcp-scan-ignore, but it's annoying when it hits a vendored dependency you can't control.

Integrating with AgentGraph Trust Badges

If you're publishing an MCP server publicly — on npm, GitHub, or through a marketplace — the trust badge is the user-facing output of all this.

After your first successful scan with an API key, you get a badge URL:

[![MCP Security Score](https://agentgraph.co/badge/mcp/your-server-id)](https://agentgraph.co/agent/your-server-id)

The badge shows the current score and links to the full scan history. It updates after each scan that pushes results to the API. If a scan fails or the score drops below 70, the badge goes red.

This is the same trust infrastructure that AgentGraph uses for AI agents more broadly — verifiable DIDs, on-chain audit trails, social graph trust scoring. The scanner is a way into that system for teams who build tooling rather than agents directly.

What It Doesn't Catch

Being clear about limitations:

Supply chain attacks in dependencies. The scanner checks your code, not your node_modules. Use something like socket.dev or npm audit alongside it for dependency scanning.
Logic-level vulnerabilities. If your server correctly implements a tool that does something dangerous by design, the scanner won't flag it. It checks implementation patterns, not intent.
Runtime prompt injection. The dynamic analysis catches some injection patterns, but a sophisticated attack that only triggers under specific LLM-generated inputs won't show up in synthetic testing.
Configuration security. How you deploy the server, what permissions it runs with, network policies — none of that is in scope.

Think of it as one layer in a defense-in-depth approach, not a complete security solution.

Getting Started

# Install
npm install -g mcp-security-scan

# Scan a local server
mcp-security-scan scan ./path/to/server

# Scan with dynamic analysis
mcp-security-scan scan ./path/to/server --dynamic

# Output JSON for CI integration
mcp-security-scan scan ./path/to/server --format json --output report.json

# Check a specific rule
mcp-security-scan rules list
mcp-security-scan rules explain env-wildcard-read

The full documentation is in the repo. Issues and PRs are open — the rule set in particular benefits from real-world examples of patterns people have seen in the wild.

Conclusion

MCP servers are infrastructure. They deserve the same security review you'd give any other piece of infrastructure that touches credentials and runs code on behalf of users. Most teams aren't doing that review today because there wasn't a fast, automated way to do it.

mcp-security-scan is the starting point. It won't catch everything, and the trust score is a signal, not a guarantee. But a score of 45 with three HIGH findings is a concrete thing you can act on before shipping.

The broader project — verifiable agent identity, auditable trust trails, a trust layer that scales across the agent ecosystem — is what AgentGraph is building. The scanner is how a lot of developers find their way into it.

Repo: github.com/agentgraph-co/mcp-security-scan

Disclosure: This post was generated with AI assistance as part of AgentGraph's content pipeline. The technical details reflect the actual tool's behavior.

How to Audit Your MCP Servers for Security Risks

AgentAvow — Thu, 16 Jul 2026 17:49:54 +0000

TL;DR: MCP servers run with surprising access to your filesystem, environment variables, and network — and most developers ship them without any security review. mcp-security-scan is an open-source CLI and GitHub Action that checks for credential theft, data exfiltration, and unsafe execution patterns, outputting a 0-100 trust score. It's free, MIT-licensed, and takes about 30 seconds to run.

If you've wired up an MCP server to Claude or another agent runtime, you've probably not thought too hard about what that server can actually do. That's normal. You were focused on getting the tool calls working.

But MCP servers run in a privileged position. They sit between your agent and the outside world, and they can read files, make network requests, spawn subprocesses, and access environment variables. The Model Context Protocol spec doesn't define a security model — it defines a communication protocol. What happens inside your server is entirely up to you.

That gap is where mcp-security-scan comes in.

What the scanner actually checks

The tool runs static analysis on your MCP server source code (TypeScript, Python, and JavaScript supported) and looks for six categories of risk:

Credential theft patterns — environment variable reads that touch anything matching *_KEY, *_SECRET, *_TOKEN, *_PASSWORD, or *_CREDENTIAL. Not all of these are bugs, but they should be visible. If your weather tool is reading STRIPE_SECRET_KEY, that's worth knowing.

Data exfiltration — outbound HTTP calls from inside tool handlers. Again, not inherently bad. But a tool that's supposed to format a string shouldn't be POSTing to an external endpoint.

Unsafe execution — exec(), eval(), subprocess.run(), child_process.spawn(), and similar. These are the ones that keep security people up at night. An MCP tool that eval's user-supplied input is a remote code execution waiting to happen.

Filesystem access — reads and writes outside the working directory. Particularly dangerous when the agent is passing file paths that come from user input.

Code obfuscation — high-entropy strings, base64-encoded payloads, minified code shipped without source maps. These aren't automatically malicious, but they're a signal.

Dependency confusion risks — package names that shadow popular packages, or dependencies pulled from unusual registries.

Running it

npx @agentgraph/mcp-security-scan ./my-mcp-server

Or install globally:

npm install -g @agentgraph/mcp-security-scan
mcp-security-scan ./my-mcp-server

Python projects work the same way — the scanner detects the runtime from package.json or pyproject.toml.

Output looks like this:

AgentGraph MCP Security Scanner v0.4.1
Scanning: ./my-mcp-server

[PASS] No credential theft patterns detected
[WARN] 3 outbound HTTP calls in tool handlers (lines 47, 112, 203)
[FAIL] eval() usage detected in tools/execute.ts (line 89)
[WARN] Filesystem read outside working directory (tools/reader.ts, line 34)
[PASS] No obfuscated code detected
[PASS] Dependencies look clean

Trust Score: 61/100

Issues requiring attention:
  HIGH   eval() in tool handler — potential RCE vector
  MEDIUM Filesystem traversal — validate paths before use
  LOW    Outbound HTTP in 3 handlers — document or restrict

Run with --json for machine-readable output
Run with --fix for suggested remediations

The trust score integrates directly with AgentGraph's trust badge system, so if you're publishing an MCP server for others to use, you can attach a verified score to your README.

The GitHub Action

Drop this in .github/workflows/security.yml:

name: MCP Security Scan

on:
  push:
    branches: [main]
  pull_request:

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

      - name: Run MCP Security Scan
        uses: agentgraph-co/mcp-security-scan@v1
        with:
          path: ./
          fail-below: 70
          output: sarif

      - name: Upload SARIF results
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: mcp-security-scan.sarif

The fail-below threshold is configurable. We default to 70 for most projects — below that, you have at least one HIGH or several MEDIUMs that haven't been addressed. The SARIF output means findings show up natively in GitHub's Security tab, which is useful if you're already using CodeQL or similar.

Architecture decisions (and what we got wrong)

Building a security scanner for something as loosely-defined as MCP servers involved some choices worth being upfront about.

Static analysis vs. dynamic analysis. We chose static. Dynamic analysis would catch more — you'd actually run the server and observe its behavior. But it's dramatically harder to do safely. Running arbitrary MCP server code in a sandbox to observe what it does is the kind of thing that requires real infrastructure. Static analysis misses obfuscated runtime behavior, but it's fast, safe, and works in CI without any special setup.

The trade-off: a sufficiently motivated bad actor can evade static analysis. If someone really wants to hide malicious behavior, they'll encode it in a way that pattern-matching won't catch. We know this. The scanner isn't a guarantee — it's a baseline that catches the obvious stuff and raises the cost of shipping something obviously dangerous.

Regex vs. AST parsing. For the first version, we used regex patterns for Python and a lightweight AST walk for TypeScript/JavaScript. Regex is fast and easy to maintain, but it produces false positives. A comment that says # don't use eval() will still trigger the eval check. We're migrating the Python analyzer to use ast module parsing in v0.5, which will cut false positives significantly.

This is the thing about security tooling: false positives erode trust in the tool itself. If developers learn to ignore the warnings, the scanner becomes noise. We'd rather have fewer, higher-confidence findings than comprehensive but noisy output.

Trust score math. The 0-100 score is a weighted sum. HIGH findings cost 25 points each (capped at 2), MEDIUM findings cost 10 points each (capped at 3), LOW findings cost 3 points each. Starting from 100, you can floor at 0 but not go negative. This is... fine. It's not a sophisticated risk model. But it produces numbers that feel intuitively right for the cases we tested, and it's transparent enough that developers can understand why their score is what it is.

We considered a more sophisticated model — CVSS-style scoring with exploitability and impact dimensions. We decided against it for v1 because the complexity wasn't justified by the signal quality of static analysis. When you're doing AST pattern matching, you don't actually know if that eval() call is reachable from a tool handler or buried in dead code. Pretending you have CVSS-level precision would be misleading.

Why MCP security is messier than it looks

The Moltbook breach earlier this year exposed 1.5 million API tokens. That incident wasn't an MCP-specific attack, but the attack surface is similar: a platform that aggregates agent tools and credentials, with insufficient verification of what those tools actually do.

OpenClaw's skills marketplace had 12% of submissions flagged for malware in their last public audit. That's not a rounding error. That's one in eight tools doing something it shouldn't.

The problem is that MCP servers are easy to write and increasingly easy to publish. The friction between "I built a thing" and "other people's agents are running my thing" is very low. That's good for the ecosystem's growth. It's bad for security.

The Traceforce launch on HN this week (company-wide security monitoring for AI apps) is hitting the same problem from the enterprise end. They're watching what AI apps do at runtime. We're catching issues before deployment. Both approaches are necessary — the question of "is this agent doing what it claims to do" doesn't have a single answer at a single layer.

Using the API for custom integrations

If you want to integrate the scanner into something beyond a standard CI pipeline, there's a REST API:

import { MCPSecurityScanner } from '@agentgraph/mcp-security-scan';

const scanner = new MCPSecurityScanner({
  apiKey: process.env.AGENTGRAPH_API_KEY, // optional — enables trust badge publishing
  config: {
    failBelow: 70,
    checks: ['credentials', 'exfiltration', 'execution', 'filesystem'],
    exclude: ['node_modules', '**/*.test.ts']
  }
});

const result = await scanner.scan('./my-mcp-server');

console.log(`Trust Score: ${result.trustScore}`);
console.log(`Findings: ${result.findings.length}`);

for (const finding of result.findings) {
  console.log(`[${finding.severity}] ${finding.message} (${finding.file}:${finding.line})`);
}

// Publish to AgentGraph trust registry (requires API key)
if (result.trustScore >= 70) {
  const badge = await scanner.publishTrustBadge(result);
  console.log(`Badge URL: ${badge.url}`);
  console.log(`Embed in README: ${badge.markdown}`);
}

The API key is only needed if you want to publish results to the AgentGraph trust registry and get a verified badge for your README. Scanning itself is entirely local — nothing leaves your machine without the API key configured.

What the scanner won't catch

Being honest about limitations:

Runtime behavior. If your server loads a malicious plugin at runtime from a URL that isn't in the source code, static analysis won't see it. This is a known gap.

Logic bugs. The scanner doesn't understand what your tool is supposed to do. If your tool is supposed to read files and it reads files, that's a WARN, not a FAIL — even if the specific files it reads are sensitive. You need a human to evaluate whether the behavior is appropriate.

Supply chain attacks in dependencies. We check package names for obvious confusion attacks, but we don't run a full audit of your dependency tree. Use npm audit or pip-audit for that — they're better tools for that specific job.

Obfuscated malice. A determined attacker who encodes their payload in a way that looks like a base64 config string will probably get through. We flag high-entropy strings, but the false positive rate on that check is high enough that many projects will tune it down.

The scanner is a floor, not a ceiling. It catches the stuff that shouldn't be there at all — the eval() calls, the credential reads in tools that don't need credentials, the outbound HTTP calls that weren't in the README.

Getting a trust badge for your MCP server

If you're publishing an MCP server — on npm, PyPI, or anywhere else — running the scanner and publishing your score takes about two minutes:

mcp-security-scan . --publish --api-key $AGENTGRAPH_API_KEY

You get a badge like this in your README:

[![AgentGraph Trust Score](https://agentgraph.co/badge/your-server-id.svg)](https://agentgraph.co/server/your-server-id)

The badge links to a public audit page showing what was scanned, what version, and what the findings were. It updates automatically when you push new code through the GitHub Action.

This is the piece that connects to the broader AgentGraph project. The scanner is useful standalone. But the trust badge is what makes the score meaningful to someone who's deciding whether to run your MCP server against their data.

The repo is at github.com/agentgraph-co/mcp-security-scan — MIT licensed, PRs open. We're particularly interested in contributions around the Python AST analyzer and additional check categories.

For the broader trust infrastructure context — DIDs, trust scoring, agent identity — that's at agentgraph.co. The scanner is one piece of it. The goal is a world where you can look at any agent or MCP server and have a real answer to "should I trust this thing."

Right now, the answer to that question is usually "I don't know, the README looked fine." That's not good enough.

This post was generated with AI assistance and reviewed by the AgentGraph team. We're committed to being transparent about that.

AgentGraph Update

AgentAvow — Thu, 09 Jul 2026 17:36:51 +0000

🤖 Auto-generated technical article by AgentGraph's content bot (disclosure at top). Long-form (~1500 words). Break down the 5 vectors mcp-security-scan checks: credential theft patterns, data exfil signatures, unsafe exec (shell/eval), filesystem scope, code obfuscation. For each: what we look for, a real-ish code example of a red flag, weight in the score. Close with GitHub Action YAML snippet + how the score maps to an AgentGraph badge. SEO target: 'MCP server security', 'trust score MCP'.

AgentGraph Update

AgentAvow — Thu, 02 Jul 2026 04:23:57 +0000

Bot-disclosed banner. Long-form (1500-2000 words) walking through 5 concrete attack patterns in MCP servers — credential harvesting via env vars, prompt-injected tool descriptions, silent filesystem traversal, obfuscated payloads in package post-install, exfil via DNS. For each: code sample, why static scanners miss it, how mcp-security-scan flags it. Include CLI examples and GitHub Action snippet. Close with AgentGraph trust badge.

AgentGraph Update

AgentAvow — Thu, 25 Jun 2026 00:36:38 +0000

Long-form technical post (1500-2000 words). Walk through methodology of mcp-security-scan, share aggregate findings (X% had hardcoded creds, Y% had unsafe shell exec, Z% obfuscated code), provide a checklist devs can run themselves. Include code snippets, the CLI install command, GitHub Action YAML. End with note that trust scores integrate with AgentGraph badges. Disclose at top: 'Written and published by the AgentGraph bot account — methodology and data are real.'

AgentGraph Update

AgentAvow — Thu, 18 Jun 2026 00:45:29 +0000

Long-form (~1500 words). Structure: (1) Why 'it sounds right' isn't trust. (2) The four primitives of agent trust: verifiable identity (W3C DIDs), tamper-evident evolution history, third-party security attestation (mcp-security-scan as example), social/transitive trust scoring. (3) Worked example: an MCP server author goes from anonymous repo to badge-bearing verified agent in 5 minutes. (4) Open standards we build on (DSNP, AIP, DID-core). Disclose bot authorship in TL;DR. Heavy on code samples and diagrams.

AgentGraph Update

AgentAvow — Thu, 11 Jun 2026 01:01:28 +0000

Long-form (1500+ words) technical guide: the 5 attack classes mcp-security-scan checks for (credential theft, data exfil, unsafe exec, filesystem access, code obfuscation), with concrete code examples of vulnerable vs safe patterns. Show how to add the GitHub Action in 3 lines of YAML. Final section: how the trust score connects to AgentGraph badges (soft mention). Header disclosure: 'This post was drafted by AgentGraph's content bot and reviewed by our team.'

You can't tell if an MCP server is safe before you install it. So I built a scanner you don't have to trust.

AgentAvow — Sat, 06 Jun 2026 17:24:30 +0000

Most MCP servers and agent tools execute code, hold API keys, or run with broad permissions. There's no easy way to check if one is safe before you wire it into your stack — you're basically running curl | bash and hoping.

So we built a free scanner. Paste any GitHub repo at agentgraph.co/check/{owner}/{repo} (no login) and you get a grade plus the actual findings: hardcoded secrets, unsafe exec, missing auth, dependency risks, OWASP-style flags.

We've scanned ~950 agent/MCP repos so far. The honest headline: most use unsafe code-execution patterns, and high-severity findings show up even in popular, well-maintained projects.

The part I actually care about: you don't have to trust our verdict. Every scan emits an Ed25519-signed "trust envelope" you can verify yourself against our published JWKS — the score, the per-source methodology, all of it. Two SDKs do the verification client-side:

pip install agentgraph-sdk      # Python
npm i agentgraph-trust          # JS/TS

from agentgraph_sdk import AgentGraphClient
async with AgentGraphClient("https://agentgraph.co") as c:
    result = await c.verify("did:web:...")   # checks the signature + freshness locally
    print(result.valid, result.kid)

And there's a GitHub Action so a scan runs in CI and drops the grade as a PR comment:

- uses: agentgraph-co/trust-scan-action@v1

It's free, no signup, no secret. Try it on something you actually use — curious what people find.

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

AgentAvow — 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

AgentAvow — 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.

DEV Community: AgentAvow

AgentGraph is now AgentAvow

How We Built Verifiable Agent Identity with DIDs — and Why the Moltbook Breach Should Scare You

Why Agent Identity Is Different From User Identity

The Architecture

Registering an Agent: The SDK Flow

The Trust Score: What It Actually Measures

The Audit Trail Problem

MCP Bridge and Tool Discovery

Why On-Chain and Not Just a Database?

What the Healthcare and Finance Verticals Are Teaching Us

Getting Started

How to Audit Your MCP Servers for Security Risks

What Actually Goes Wrong

Introducing mcp-security-scan

Running It in CI

How the Scanner Works

Static Analysis

Dynamic Analysis

The Trust Score

Architecture Decisions and What We Got Wrong

Integrating with AgentGraph Trust Badges

What It Doesn't Catch

Getting Started

Conclusion

How to Audit Your MCP Servers for Security Risks

What the scanner actually checks

Running it

The GitHub Action

Architecture decisions (and what we got wrong)

Why MCP security is messier than it looks

Using the API for custom integrations

What the scanner won't catch

Getting a trust badge for your MCP server

AgentGraph Update

AgentGraph Update

AgentGraph Update

AgentGraph Update

AgentGraph Update

You can't tell if an MCP server is safe before you install it. So I built a scanner you don't have to trust.

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

What's in v0.3.2

The substrate-evidence density

What this unlocks

What's next

Read the spec

AgentGraph Update

Introducing `mcp-security-scan`