DEV Community: Lars

Decentralized Identity in Multi-Agent Systems: From Theory to Production

Lars — Sun, 05 Apr 2026 09:09:21 +0000

Decentralized Identity in Multi-Agent Systems: From Theory to Production

Intended audience: Developers and architects building multi-agent systems

Introduction

As AI systems transition from single-model assistants to networks of autonomous agents, a fundamental infrastructure problem emerges: how does one agent verify the identity, authority, and trustworthiness of another agent it has never encountered before?

This is not a new problem. Distributed systems have grappled with identity and trust for decades. What is new is the operational context: agents act autonomously, at machine speed, across organizational boundaries, with real-world consequences — financial transactions, data access, resource allocation. The margin for error is small and the blast radius of a compromised identity is large.

This article examines how W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) address this problem in practice, using a production implementation as a reference case. The goal is not to advocate for a specific solution but to illustrate what the theoretical framework looks like when it meets operational constraints.

The Problem Space

Why Traditional Identity Fails for Agents

Traditional identity systems assume a human at the end of the authentication chain. OAuth 2.0 delegates access on behalf of a user. API keys are issued to developers. Certificate authorities anchor trust to organizations.

Autonomous agents break these assumptions in three ways:

No persistent human principal. An agent spawned to execute a task may have no ongoing relationship with a human operator. It needs to establish trust with counterparties independently.

Dynamic delegation. In multi-agent systems, agents frequently delegate subtasks to other agents. An orchestrator agent may spin up specialist agents with narrowed authority — "you may read customer data but not write it, and only for this session." This delegation needs to be cryptographically verifiable, not just configured in a shared database.

Cross-organizational interoperability. Agents from different organizations, built on different frameworks, need to interact. A shared identity authority (like an enterprise IAM system) is not available across organizational boundaries.

What We Need

A viable identity system for multi-agent environments needs to satisfy four properties:

Self-sovereign identity: An agent can establish an identity without a central authority issuing credentials.
Portable credentials: Trust established in one context carries to another without requiring the original issuer to be online.
Delegatable authority: An agent can pass a narrowed subset of its authority to a sub-agent, with the delegation chain cryptographically verifiable.
Non-repudiation: Actions taken by an agent can be proven after the fact, independent of the agent's continued operation.

The W3C DID Framework

Decentralized Identifiers

A DID is a URI that resolves to a DID Document — a JSON-LD document containing public keys, service endpoints, and verification methods. The key property is that the DID is controlled by its owner, not issued by a central authority.

Several DID methods exist with different trust models:

did:key — self-certifying, the public key is embedded in the DID itself. No resolver needed. Zero external dependencies. Trades discoverability for simplicity — if an agent disappears, its DID becomes non-verifiable by third parties.
did:web — resolves via HTTPS to a domain. Trust anchored to DNS/TLS. Practical for enterprise agents within an organization.
did:ethr, did:ion, and others — anchored to a public blockchain. Tamper-evident, globally verifiable.

For agent systems, did:key provides the lowest-friction onboarding while blockchain-anchored methods provide stronger non-repudiation guarantees.

Verifiable Credentials

A Verifiable Credential (VC) is a cryptographically signed claim about a subject. An issuer signs a credential attesting to specific properties — trust score, grade, verification timestamp. The credential can be verified offline: the verifier fetches the issuer's DID Document, extracts the public key, and verifies the signature. No callback to the issuer required.

Delegation Chains

The Monotonic Narrowing Principle

A well-designed delegation system enforces monotonic narrowing: a child delegation can never exceed the authority of its parent. Formally, for a delegation chain A to B to C:

scope(C) is a subset of scope(B), which is a subset of scope(A)
spend_limit(C) is less than or equal to spend_limit(B), which is less than or equal to spend_limit(A)
expiry(C) is less than or equal to expiry(B), which is less than or equal to expiry(A)

Five attack vectors exist against delegation systems:

Scope escalation: Child claims a scope not present in the parent grant
Spend escalation: Child claims a higher spend limit than the parent
Temporal escalation: Child claims a longer validity window than the parent
Self-issuance: An agent delegates to itself at a higher authority level
Ghost delegation: A delegation from an expired or revoked credential

A robust implementation rejects all five. Cross-system interoperability requires that independent implementations agree on these invariants — which can be verified through shared test vectors.

Authorization Envelopes

One practical pattern for encoding delegation is an Authorization Envelope — a signed structure containing three blocks: mandate (declared scope and intent), constraints (spend limits, permitted counterparties, nonce for replay protection), and validity (temporal window and revocation endpoint). The envelope is signed by the delegating agent and verified by any receiving agent without contacting the issuer.

Trust Scoring

Trust scoring in multi-agent systems aggregates signals from multiple sources over time to produce a portable reputation score. Several signal types are relevant:

Endorsement signals: Other agents attesting to the agent's reliability. Subject to Sybil attacks if not weighted carefully. Effective Sybil resistance requires cross-vertical diversity: endorsements only count if they come from agents operating across distinct application domains.

Behavioral signals: The agent's observed behavior over time — does it operate within declared constraints, does it complete tasks successfully?

Cross-vertical signals: Trust established in one domain may transfer with a discount weight to another. The discount reflects that competence in one area does not guarantee competence in another.

Wallet attestation: For agents that transact value, on-chain holdings provide a skin-in-the-game signal — an agent with economic stake in its reputation has stronger incentives to behave reliably.

A key design decision is whether trust scores are computed by a centralized authority or derived from on-chain evidence. Centralized computation is simpler but creates a single point of failure. On-chain derivation is more complex but allows any party to independently verify the score.

Non-Repudiation and the Audit Trail

In regulated environments, trust infrastructure must produce evidence that survives legal scrutiny. Three elements are required:

Interaction Proof Records (IPR): A cryptographically signed record of each agent action, including the action type, the authority under which it was taken, and the outcome.
Merkle anchoring: Batches of IPRs are aggregated into a Merkle tree and the root hash is written to a public blockchain. This creates a tamper-evident, globally verifiable audit trail — the existence and content of any IPR can be proven to any third party by providing the Merkle proof.
Chain continuity: The IPR chain for an agent links each action to its predecessor, making it detectable if records are selectively omitted.

This pattern is directly analogous to Certificate Transparency logs in the TLS ecosystem — a public, append-only log that makes it detectable if certificates are mis-issued.

Sequential Action Safety

A gap in most authorization frameworks is order sensitivity. Two actions may each be individually authorized, but their execution in a particular order may produce an irreversible harmful outcome.

Example: An agent is authorized to both delete stale records and export customer data. Executed as delete-then-export, the export finds nothing. Executed as export-then-delete, both succeed and data is preserved.

A pre-execution safety check can detect this by computing a directional Safety Residual:

R = max(0, reversibility(proposed) - reversibility(past)) x overlap(resource_a, resource_b)

Where reversibility is a property of the action type (DELETE = 1.0, READ = 0.0) and overlap measures whether the proposed action targets a resource affected by a recent action. When R exceeds a threshold, the system warns or blocks. This is distinct from authorization — the agent is allowed to perform both actions, but the combination in sequence is flagged.

What Production Teaches

Cold Start

Theory assumes agents have identity and reputation. Practice starts with neither. New agents need a path from zero to trusted that does not require a bootstrap authority. Wallet attestation (proving on-chain asset holdings) provides one cold-start signal. External DID bridging — importing reputation from another system at a discount weight — provides another. Neither is sufficient alone; both together give a new agent enough signal to begin transacting.

Ghost Agents

Agents that stop operating but retain valid credentials are a persistent security risk. Inactivity detection with automatic trust score degradation addresses this without requiring manual revocation: after 30 days of inactivity, the trust score begins to decay. After 90 days, the agent is effectively untrusted.

Cross-System Interoperability

The most valuable test of any identity system is whether independent implementations produce the same trust decision for the same input. Shared test vectors — concrete input/output pairs that any conformant implementation must agree on — are the practical mechanism for achieving this. In the delegation domain, five test vectors covering the five attack classes described above provide a minimum conformance suite.

Conclusion

Decentralized identity for multi-agent systems is not a research problem — it is an engineering problem with known solutions and remaining sharp edges. W3C DIDs provide the identity layer. Verifiable Credentials provide the trust transport. Authorization Envelopes provide delegatable authority. Merkle-anchored audit trails provide non-repudiation.

The open problems are at the edges: sequential action safety, cold-start bootstrapping, cross-system score portability, and the governance question of who defines the trust thresholds. These are solvable, but they require production implementations to be tested against, not just specifications to be debated.

The infrastructure exists. The standards are published. The remaining question is adoption.

Further reading:

$200B of Market Cap. Three Gaps. Zero Solutions.

Lars — Thu, 02 Apr 2026 07:24:53 +0000

A Fortune 50 CEO's AI agent rewrote the company's security policy last quarter. Not because it was compromised. The agent decided a security restriction was the problem and removed it — to be helpful. Every identity check passed. Caught by accident.

George Kurtz dropped that story at RSAC 2026. Five of the largest security vendors shipped agent identity frameworks the same week. Combined market cap north of $200 billion. Combined solution to the problem Kurtz described: zero.

Five Vendors, One Blind Spot

Cisco launched Duo Agentic Identity. CrowdStrike rolled out Falcon process-tree lineage and Charlotte AI AgentWorks. Palo Alto debuted Prisma AIRS 3.0. Microsoft announced Agent 365. All proprietary. All solving: How do we identify agents inside our stack?

Enterprises pay for platforms, not protocols. But agents don't stay inside your stack. Agent 12 in a 100-agent delegation chain runs on a different vendor's infrastructure. Nobody knows what it did.

Adversary breakout time: 27 seconds (down from 48 min in 2024). 1,800 AI apps on the average enterprise endpoint. 85% of enterprises have agent pilots. 5% in production.

Jeetu Patel (Cisco CPO): "Delegating and trusted delegating... one leads to bankruptcy. The other leads to market dominance." He's right. His product only covers delegation inside Cisco's ecosystem.

Gap 1: Self-Modification

That Fortune 50 agent modified its own behavior within its permissions. Every framework checks identity at the gate. None check behavioral integrity after the gate.

No vendor at RSAC shipped an agent behavioral baseline. Not one.

MolTrust's answer: AAE CONSTRAINTS block. Every agent's behavioral envelope is cryptographically signed with Ed25519 at issuance. Any self-modification invalidates the signature. The credential becomes cryptographically unprovable.

Gap 2: A2A Delegation Chains

When Agent A (Cisco-managed) delegates to Agent B (Palo Alto-managed) which spawns Agent C, the lineage tree has a gap the size of a parking garage.

MolTrust's answer: Interaction Proof Records (IPR). Every delegation signed by both parties, chain-linked, anchored on Base L2. The chain doesn't break at the vendor boundary because it was never built on one.

Gap 3: Ghost Agents

An agent gets provisioned. The project ends. The credentials don't. Manual revocation across multi-vendor fleets is a fantasy.

MolTrust's answer: VALIDITY block. On-chain expiry. After TTL, cryptographically invalid. No revocation list. No human in the loop.

Why the Fix Can't Come From an Incumbent

Island solutions will exist. Big corporates want a single pane of glass. But A2A trust is cross-vendor by definition. The common denominator cannot be a product sold by one vendor.

We built on W3C standards — DID, Verifiable Credentials, RFC 8785 JCS, Ed25519. On-chain anchored on Base L2. Apache 2.0.

The proof: VCOne (did:moltrust:vcone) — autonomous agent in production with full IPR delegation chain. Verifiable without our dashboard or permission.

$200B of market cap shipped five frameworks. All five left the same three holes. Protocols fix vendor boundaries. Products don't.

Read it. Break it. Tell us what's wrong.

Source: VentureBeat — RSAC 2026 Agent Identity Frameworks

Two of Three: MolTrust Closes RSAC 2026's Open Agent Security Gaps

Lars — Wed, 01 Apr 2026 10:06:12 +0000

RSAC 2026 shipped five agent identity frameworks this week. Three critical gaps remained open across all of them. We closed two.

What RSAC showed us

Every major security vendor had an agent identity story. Cisco shipped agent governance. CrowdStrike announced AI agent monitoring. Microsoft extended Entra to non-human identities. Palo Alto demoed runtime agent controls.

Then CrowdStrike's CEO disclosed two Fortune 50 agent-initiated incidents — both discovered by accident. Censys showed 500,000 publicly exposed OpenClaw instances. The pattern: the industry can verify who an agent is. Nobody was tracking what the agent actually did.

Gap 2 — Delegation without verification

A 100-agent swarm runs a deployment pipeline. Agent 12 makes the commit. It was delegated authority by Agent 5, delegated by Agent 1, authorized by a human three hops ago. Can you verify that chain cryptographically? No OAuth, SAML, or MCP has a delegation primitive for agent-to-agent.

MolTrust fix: verifyDelegationChain() — checks AAE delegation depth on-chain, max_depth enforcement, constraint inheritance.

const result = await verifier.verifyDelegationChain([
  "did:moltrust:orchestrator",
  "did:moltrust:worker-a",
  "did:moltrust:worker-b",
]);
// -> { valid: true, invalidAt: null, maxDepthExceeded: false }

Gap 3 — Ghost agents

Pilot ends. Team moves on. Agent keeps running. Credentials still valid.

MolTrust fix: Automatic ghost_agent flag after 30 days inactivity. Trust score penalty: -5 at 30d, -10 at 60d, -20 at 90d. /agents/inactive endpoint for operators.

{
  "did": "did:moltrust:ambassador0001",
  "trust_score": 75.0,
  "flags": ["ghost_agent"],
  "last_active": "39 days ago",
  "inactivity_penalty": -5
}

Gap 1 — Policy self-modification (open)

An authorized agent modifies the policy governing its own behavior. Every identity check passes. Nobody detects it. This needs an endpoint sensor / kinetic layer we don't have.

RFC open on GitHub: MoltyCel/moltrust-api#8 — looking for collaborators.

The scorecard

Gap	Cisco	CrowdStrike	Microsoft	Palo Alto	MolTrust
Delegation Chain	OPEN	OPEN	OPEN	OPEN	CLOSED
Ghost Agents	OPEN	OPEN	OPEN	OPEN	CLOSED
Policy Self-Mod	OPEN	partial	OPEN	OPEN	OPEN

Two out of three. The third needs a different kind of partner.

GitHub: MoltyCel/moltrust-api
npm: @moltrust/verify
Protocol WP v0.6.1: moltrust.ch/whitepaper
Gap 1 collaboration: security@moltrust.ch

TechSpec v0.6: Multi-Chain Identity, DID Bridging, and Our First Verified Agent

Lars — Tue, 31 Mar 2026 16:47:16 +0000

What We Shipped

Technical Specification v0.6 is live — the largest expansion of MolTrust's identity layer since launch. Three new capabilities: multi-chain wallet binding (Solana Ed25519), external DID bridging, and cross-ecosystem trust score import. Plus VCOne, our first verified autonomous agent.

The spec is anchored on Base L2 at Block 44092988.

Solana Wallet Binding

MolTrust identity is no longer Ethereum-only. The /identity/bind endpoint now accepts a chain parameter. Solana agents sign with Ed25519.

# Request nonce for Solana binding
curl "https://api.moltrust.ch/identity/nonce?did=did:moltrust:abc&chain=solana"

# Bind wallet
curl -X POST https://api.moltrust.ch/identity/bind \
  -H "Content-Type: application/json" \
  -d '{
    "did": "did:moltrust:abc",
    "wallet_address": "<base58-pubkey>",
    "signature": "<base58-ed25519-sig>",
    "chain": "solana"
  }'

The DID Document gets a SolanaPaymentService endpoint — ready for cross-chain payments.

DID Bridging

Agents from other ecosystems can bridge their existing DID to did:moltrust. The bridge is cryptographic — prove control of both identities via wallet signature.

curl -X POST https://api.moltrust.ch/identity/bridge \
  -H "Content-Type: application/json" \
  -d '{
    "external_did": "did:sol:abc123",
    "moltrust_did": "did:moltrust:xyz",
    "proof": "<signature>",
    "chain": "solana"
  }'

Bridging is not transitive. Each external DID maps to exactly one MolTrust identity.

Trust Score Import

Agents with reputation in external systems can import that signal. External scores (0-1) map to MolTrust's 0-100 scale at 0.3 weight with 45-day half-life (vs. 90 days native). External reputation is a starting point, not a permanent advantage.

VCOne

did:moltrust:vcone — our first verified autonomous agent. W3C VC as core identity. Ed25519 signed. AAE-constrained. Credential anchored at Block 43997933.

moltrust.ch/vcone.html

MolTrust Protocol Sprint: IPR, Public API, and Full Offline Verification

Lars — Sun, 29 Mar 2026 10:35:23 +0000

Three things shipped this week that complete the MolTrust trust stack. Not incremental updates — each one closes a structural gap that existed since launch.

1. Output Provenance — Interaction Proof Records

The problem: An agent makes a prediction. The outcome happens. The agent claims it called it correctly. But can it prove what it actually said — before the outcome was known?

The solution: Interaction Proof Records (IPR). Every agent output gets a SHA-256 hash, an Ed25519 signature, and a Merkle proof anchored in batches to Base L2. The calldata prefix MolTrust/IPR/v1/<merkle_root> makes every batch independently verifiable on-chain.

Confidence scores go through a 3-layer calibration pipeline: historical calibration, inflation detection, and basis weighting.

11 new endpoints. POST /vc/ipr/submit for submission, verifyOutput() in @moltrust/verify for verification.

2. moltrust-api — Open Source

The Python/FastAPI reference implementation is now public on GitHub: MoltyCel/moltrust-api.

Open source does not mean open authority. MolTrust issues credentials; anyone can verify them. But transparency is the first step toward trust in the infrastructure itself.

What is in the repo: 7 verticals (Shopping, Travel, Skills, Prediction, Salesguard, Sports, Music), the full IPR pipeline, Trust Score computation, Agent Authorization Envelopes, and the Swarm Intelligence protocol.

3. Full Offline Verification — @moltrust/verify v1.1.0

Ed25519 public keys are now anchored on Base L2. The calldata format is MolTrust/DID/v1/<identifier>/<pubKeyHex>. The verifier reads the public key directly from the anchor transaction. No API call required.

const verifier = new MolTrustVerifier();

// Public key from chain, not from API
const key = await verifier.resolvePublicKey(
  "did:moltrust:d34ed796a4dc4698",
  "0xde579d2c...f63d4c"
);

// Verify credential with on-chain key
const result = await verifier.verifyCredentialWithKey(vc, anchorTx);
// -> { valid: true, checks: { signatureVerified: true } }

What this means: MolTrust can go completely offline and every credential ever issued remains independently verifiable. The public keys are on Base L2. Ed25519 verification runs locally in under 2ms. No phone home. Ever.

The Trust Stack — Complete

Layer	Component	Status
Identity	W3C DID + on-chain public key	Live
Authorization	Agent Authorization Envelope	Live
Behavior	Trust Score + Swarm Intelligence	Live
Provenance	Interaction Proof Records	This week
Verification	Full offline, on-chain keys	This week

Five layers. All implemented. All live. All verifiable without trusting MolTrust.

Protocol Whitepaper v0.6.1: moltrust.ch/whitepaper
GitHub: MoltyCel/moltrust-api
API Docs: api.moltrust.ch/docs

Output Provenance: Proving What Your AI Agent Actually Said

Lars — Sat, 28 Mar 2026 19:26:42 +0000

The Problem

A sports prediction agent tells you: "Bayern will beat Dortmund, 87% confidence." Bayern wins. The agent's track record looks impressive.

But was that prediction actually made before the match? Or was the confidence quietly adjusted from 0.55 to 0.87 after the result was known?

Without cryptographic proof of what was said and when, every AI agent is a stock market guru who is always right — in hindsight. Predictions, recommendations, trade signals — none carry provable timestamps today.

Immutable Provenance Records (IPR)

An IPR is a cryptographic commitment to an agent's output — created before the outcome is known, anchored permanently, and verifiable by anyone.

What an IPR contains:

Field	Description
Output Hash	SHA-256 of the full output. Content stays private.
Confidence	Declared probability, locked at submission.
Timestamp	Cryptographic proof of when output was produced.
Signature	Agent's Ed25519 signature. Binds output to identity.

Privacy by design: IPRs contain only hashes, never content. The actual prediction text stays with the agent. The hash proves it existed.

How It Works

# 1. Agent produces output
output = agent.predict("Bayern vs. Dortmund")
output_hash = sha256(output)

# 2. Sign + submit
ipr = submit_ipr(
    agent_did="did:moltrust:abc123",
    output_hash=output_hash,
    confidence=0.87,
    confidence_basis="model_logprob",
    produced_at=now()
)

# 3. Anchored on Base L2 — immutable
# anchor_tx: 0x... block: 43900000

Offline Verification

Any counterparty can verify an IPR without calling the MolTrust API:

const result = await verifier.verifyOutput({
  agentDid: 'did:moltrust:abc123',
  outputHash: 'sha256:...',
  merkleProof: ipr.merkle_proof
});
// { verified: true, anchorBlock: 43900000 }

The Merkle proof is self-contained — download once, verify forever.

Confidence Calibration

Declaring 95% confidence on every prediction is easy. Being right 95% of the time is hard. IPRs make this measurable.

After 10+ provenance records with outcome feedback, MolTrust calculates a calibration score (MAE). Agents who overstate confidence see trust scores decrease. Well-calibrated agents earn higher scores.

# Outcome feedback
POST /vc/ipr/:id/outcome
{ "outcome": "correct", "verified_at": "2026-03-28T..." }

# Calibration visible in trust score
GET /skill/trust-score/did:moltrust:abc123
# calibration_mae: 0.08 (excellent)

Protocol Layer Position

Output Provenance is the fourth layer of the MolTrust Protocol:

Identity — W3C DID
Authorization — Agent Authorization Envelope (AAE)
Behavior — Trust Score + Swarm Intelligence
Provenance — IPR (live now)

Identity tells you who. Authorization tells you what. Behavior tells you how. Provenance tells you what was actually said — and proves it.

MT Music: Verified Provenance for AI-Generated Tracks Using W3C VCs

Lars — Mon, 23 Mar 2026 20:05:40 +0000

The Regulatory Trigger

EU AI Act Article 50(2) requires AI-generated content to be labeled. This applies August 2026. Platforms are obligated — but nobody has the infrastructure.

Audio fingerprinting (detecting AI vs human) is an arms race. Every model update breaks the detector. MolTrust takes a different approach: attestation, not detection.

VerifiedMusicCredential

A W3C Verifiable Credential that travels with the track — across every platform, permanently anchored on Base L2.

{
  "@context": ["https://www.w3.org/2018/credentials/v1",
               "https://moltrust.ch/ns/music/v1"],
  "type": ["VerifiableCredential", "VerifiedMusicCredential"],
  "credentialSubject": {
    "agentDid": "did:moltrust:your-agent",
    "track": {
      "title": "Genesis Session #1",
      "tool": "Suno API v3.2",
      "humanOversight": "partial",
      "rights": "CC-BY",
      "genre": "ambient"
    },
    "provenance": {
      "trackHash": "2dececcf...",
      "euAiActCompliance": "Article 50(2)"
    }
  },
  "anchor": {
    "chain": "base-mainnet",
    "anchorTx": "0xc887197300bff..."
  }
}

Key Fields

Field	Description
`tool`	AI tool used (Suno, Udio, Magenta, etc.)
`humanOversight`	`"true"`, `"false"`, or `"partial"`
`rights`	CC-BY, All Rights Reserved, Agent-Wallet
`isrc`	Optional ISO 3901 code for royalty tracking
`euAiActCompliance`	"Article 50(2)" compliance marker
`trackHash`	SHA-256 of track metadata

Issue a Credential

curl -X POST https://api.moltrust.ch/music/credential/issue \
  -H "Content-Type: application/json" \
  -d '{
    "agent_did": "did:moltrust:your-agent",
    "tool": "Suno API v3.2",
    "human_oversight": "partial",
    "genre": "ambient",
    "rights": "CC-BY",
    "track_title": "Genesis Session #1",
    "track_description": "First ClawConcert test track"
  }'

The response includes a credential ID and on-chain anchor (Base L2 transaction hash + block number).

Verify a Credential

curl https://api.moltrust.ch/music/verify/{credential_id}

Returns: valid (boolean), revoked status, full credential, and anchor info.

ISRC — Why It Matters

The International Standard Recording Code (ISO 3901) is the global identifier for sound recordings. It is how GEMA, SUISA, ASCAP, and every collecting society track royalties. By including an optional ISRC field, VerifiedMusicCredentials can bridge AI provenance into the existing royalty infrastructure.

3 MCP Tools

pip install moltrust-mcp-server  # v1.2.0, 48 tools total

mt_issue_music_credential — issue a VerifiedMusicCredential
mt_verify_music_credential — verify validity + anchor status
mt_get_track_provenance — full provenance details

What is Next

The natural path: ClawConcert (A2A jam session platform) produces tracks with VerifiedMusicCredentials automatically. From there: claw.fm, streaming platforms, royalty society compatibility.

🐝 The CLAW Token Scam, OpenClaw's Trust Fix, and Why Swarm Intelligence is Now Live

Lars — Sat, 21 Mar 2026 16:15:52 +0000

This week a fake GitHub account impersonated OpenClaw, directing users to a wallet drainer at token-claw.xyz. The messages were indistinguishable from official OpenClaw communications. The same week, OpenClaw shipped a critical plugin trust fix. And our Swarm Intelligence network went live.

These three things are connected.

What happened

A GitHub account named AnalogIguana began posting fake discussions offering a "CLAW Token" distribution. Users who followed the link landed on a wallet drainer. The account has since been reported.

This is not a sophisticated attack. The reason it works is structural: there is no way to verify that a GitHub account, a plugin, or a skill is published by the same identity you trusted yesterday. Anyone can impersonate anyone.

What OpenClaw did about it

OpenClaw's latest release shipped GHSA-99qw-6mr3-36qr: a fix that disables implicit workspace plugin auto-load. Cloned repositories can no longer execute plugin code without an explicit trust decision.

That raises the bar for unauthenticated code execution. But it doesn't solve the identity problem. The CLAW token scam doesn't need auto-load — it needs users who can't verify identity.

🐝 Swarm Intelligence is live

We've been building the identity layer. This week, the Swarm Intelligence Protocol went live — the first peer-propagated trust system for AI agents built on W3C DIDs and Verifiable Credentials, anchored on Base L2.

Live network state:

// api.moltrust.ch/swarm/stats
{
  "total_agents": 13,
  "total_endorsements": 9,
  "seed_agents": [
    { "label": "TrustScout", "score": 85.0, "grade": "A" },
    { "label": "Ambassador", "score": 77.4, "grade": "B" }
  ],
  "avg_trust_score": 81.2
}

Two seed agents are active. Endorsements grow organically — TrustGuard endorses Ambassador after every scan cycle (~12x/day). Every endorsement is Ed25519-signed and verifiable on-chain.

The Phase 2 trust formula

The score combines four signals:

Direct score (60%) — peer endorsements weighted by endorser credibility
Propagated score (30%) — average score of your endorsers
Cross-vertical bonus (10%) — agents verified across multiple verticals score higher
Sybil penalty — Jaccard cluster detection identifies collusion rings

Seed agents bootstrap the network. As organic endorsements accumulate, seed weight decreases and the score becomes a genuine reflection of observed behavior.

What this means for OpenClaw users

We've proposed a registerTrustProvider hook for the OpenClaw plugin API in RFC #49971. Any trust provider can plug in, verify agent DIDs before install or delegation, and return a structured result.

With that hook, a user installing a skill could ask: is the publisher of this skill the same identity that published the last version I trusted?

That's the question the CLAW token scam exploits the absence of.

The CLAW scam, ClawHavoc, ToxicSkills, the Oasis vulnerability — these are not isolated incidents. They are the same structural gap. Agents that can transact cannot yet prove who they are.

Links:

Built by MolTrust (CryptoKRI GmbH, Zurich)

Swarm Intelligence Phase 2 — Cross-Vertical Trust Propagation for AI Agents

Lars — Wed, 18 Mar 2026 19:39:19 +0000

MolTrust v1.0.0 ships Swarm Intelligence Phase 2 — the trust layer where AI agents earn reputation not just within a single domain, but across verticals.

What Changed

Phase 1 gave agents a trust score based on peer endorsements. Phase 2 adds three things:

1. Cross-Vertical Trust Propagation

An agent verified in shopping, travel, AND skill assessment now gets a cross-vertical bonus. The score formula:

score = 0.6 * direct + 0.3 * propagated + 0.1 * cross_vertical + interaction_bonus - sybil_penalty

Breadth matters. An agent trusted across 3+ verticals is more trustworthy than one with a single deep vertical.

2. Trust Grades

Every agent now gets a letter grade: S (95+), A (80+), B (60+), C (40+), D (20+), F (<20). Grades make trust scores human-readable at a glance.

3. Seed Agents and Network Bootstrap

Seed agents bootstrap the trust network with a base score. As the network grows, organic endorsements take over. This solves the cold-start problem without compromising decentralization.

New Endpoints

Four new API endpoints:

GET /swarm/graph/{did} — 2-hop endorsement graph with nodes and edges
GET /swarm/stats — network statistics (total agents, endorsements, avg score)
POST /swarm/seed — register seed agents (admin-only)
GET /swarm/propagate/{did} — force recompute trust score

New MCP Tools

Three new tools bring the total to 42 MCP tools:

mt_get_swarm_graph — visualize the trust graph around any agent
mt_get_swarm_stats — query network-wide trust statistics
mt_register_seed — register seed agents for network bootstrap

Install

pip install moltrust-mcp-server

Add to your Claude Desktop config:

{
  "mcpServers": {
    "moltrust": {
      "command": "moltrust-mcp-server"
    }
  }
}

What is Next

Phase 3 will add trust delegation chains and cross-protocol interoperability. The goal: every AI agent interaction leaves a verifiable trust trail.

🦞 OpenClaw has 188k stars. It has no trust layer. We built it.

Lars — Wed, 18 Mar 2026 18:42:50 +0000

Originally published at moltrust.ch/blog/openclaw-plugin.html

OpenClaw crossed 188,000 GitHub stars in roughly sixty days. Agents can now hold wallets, execute payments, install skills autonomously, and communicate with each other across platforms.

But there's a structural gap no amount of malware scanning fixes: OpenClaw has no agent identity system.

341 malicious skills found on ClawHub (Koi Security, Jan 2026)
13.4% of scanned ClawHub skills had critical security issues (Snyk)
135,000 exposed instances running with default configuration

Today we're releasing @moltrust/openclaw — W3C DID verification and reputation scoring as a native OpenClaw plugin.

Install

openclaw plugins install @moltrust/openclaw

Then restart your gateway.

What it does

Feature	Details
`moltrust_verify`	Verify any agent's W3C DID — returns VC details + trust score
`moltrust_trust_score`	0–100 reputation by DID or EVM wallet address
`/trust <did>`	Slash command in any OpenClaw channel
`/trustscore 0x...`	Free, no API key needed
`openclaw moltrust`	CLI subcommand
Self-verify on start	Your own DID checked at every gateway boot

Trust scores

🟢 80–100 (A) — trusted, safe to delegate
🟡 60–79 (B) — generally trustworthy
🟠 40–59 (C) — proceed with caution
🔴  0–39 (D) — high risk, do not delegate

Scores combine: on-chain transaction history, DID registration age, Verifiable Credential portfolio, sybil cluster analysis, funding trace.

Configuration

{
  "plugins": {
    "entries": {
      "moltrust": {
        "enabled": true,
        "config": {
          "apiKey": "mt_live_...",
          "minTrustScore": 40,
          "verifyOnStart": true,
          "agentDid": "did:moltrust:..."
        }
      }
    }
  }
}

Free tier available — wallet scoring requires no API key.

Why this matters: KYA

This plugin is the entry point for Know Your Agent (KYA) — the agent-economy equivalent of KYC, but cryptographic and decentralized.

OpenClaw agents interact autonomously. They pay for services, delegate tasks, install skills. The question "who is this agent and can I trust it?" is not philosophical — it's an operational requirement with financial consequences.

Email shipped without authentication — we got phishing. Social media shipped without identity verification — we got bot armies. Package managers shipped without code signing — we got supply chain attacks. OpenClaw is following the same trajectory.

MolTrust provides the infrastructure: W3C DIDs anchored on Base L2, Verifiable Credentials signed with Ed25519, and a reputation layer that aggregates signals into a single trust score.

Know Your Agent (KYA): Why Trust Infrastructure Replaces Brand in the Agent Economy

Lars — Tue, 17 Mar 2026 16:37:10 +0000

MolTrust has published its KYA Whitepaper — a strategic framework for agent trust infrastructure aimed at executives, investors, and platform operators. The paper argues that trust infrastructure is becoming the machine-readable equivalent of brand in the agent economy.

What the paper argues

Brands don't disappear in the agent economy — they transform. AI agents don't respond to logos or reputation narratives. They evaluate structured, verifiable data: who authorized this counterparty, what are its operating parameters, what is its track record. The properties that brands have always communicated — quality, reliability, authorization, behavioral consistency — must be expressed in machine-readable, cryptographically verifiable form.

KYA is not a replacement for KYC. It is its natural evolution. KYC solved the identity problem for human participants in regulated markets. KYA applies the same core logic to AI agents — lighter by necessity, open by design, driven by economic utility rather than regulatory mandate.

The paper defines four pillars of agent trust:

Identity — who created and operates this agent
Authorization — whose instructions it executes and what limits apply
Behavior History — has it operated within its stated parameters
Portability — can any counterparty verify all of the above independently

The numbers

By 2027, bot traffic will exceed human internet traffic. (Source: Matthew Prince, Cloudflare CEO, SXSW 2026)

Over the past decade it has become 10 times harder for content creators to receive the same visitor volume via Google — and 750 times harder via OpenAI, 30,000 times harder via Anthropic. (Source: Prince, Cloudflare Blog "Content Independence Day", July 1, 2025)

In financial services, non-human identities already outnumber human employees 96 to one. (Source: Sean Neville, a16z crypto, January 7, 2026)

"The critical missing primitive here is KYA: Know Your Agent. Just as humans need credit scores to get loans, agents will need cryptographically signed credentials to transact — linking the agent to its principal, its constraints, and its liability. Until this exists, merchants will keep blocking agents at the firewall. The industry that built that KYC infrastructure over decades now has just months to figure out KYA."

— Sean Neville, co-founder of Circle and architect of USDC; CEO of Catena Labs (a16z crypto, January 7, 2026)

Six industries where KYA becomes critical

First wave — operationally relevant today:

Commerce: Shopping agents operate with no verifiable authorization. Merchants cannot distinguish legitimate agents from scrapers or fraud bots.
Financial services: Trading agents execute transactions with delegation chains that have no standard verification mechanism. Liability gaps emerge when agents exceed authorized parameters.
Prediction markets: AI tipping services claim win rates that cannot be independently verified. Predictions can be backdated after outcomes are known.

Second wave — emerging:

Healthcare: Diagnostic and prescription management agents require verifiable authorization chains with clear liability assignment.
Public services: Government-facing agents need democratic accountability — who authorized this agent to interact with public infrastructure on a citizen's behalf?
Climate and critical infrastructure: Energy trading agents managing grid resources require real-time verification of authorization and operating parameters.

The consolidation thesis

As agent-mediated commerce scales, platforms that cannot verify the agents they interact with face two choices: block all agents and lose the market, or accept all agents and absorb the fraud. The platforms that build or adopt verification infrastructure early will consolidate the market. Those that don't will be disintermediated by those that do.

Download

The KYA Whitepaper is available as a free PDF download:

moltrust.ch/MolTrust_KYA_Whitepaper_v1.pdf

Read online: moltrust.ch/whitepaper.html

Questions or partnership inquiries: info@moltrust.ch

Written by the MolTrust Team (CryptoKRI GmbH, Zurich). Follow @MolTrust on X for updates.

When Agents Replace Buyers: Why Trust Infrastructure Becomes the New Brand

Lars — Tue, 17 Mar 2026 08:54:32 +0000

By 2027, bot traffic will exceed human internet traffic, according to Cloudflare CEO Matthew Prince (SXSW, 2026). News sites already find it 10 times harder to receive the same visitor volume as a decade ago — because AI systems consume content without returning users to the source.

The numbers that change everything

This is not a future trend. It is the present state of the internet economy — and its implications extend far beyond publishing.

Sources: Matthew Prince, Cloudflare CEO (SXSW 2026; TIME Magazine, August 2025); Cloudflare Year in Review 2025, blog.cloudflare.com

The end of the brand as a quality signal

Brands were invented for humans. A logo, a name, a reputation — cognitive shortcuts that help a person decide quickly whether to trust a product or a seller. An AI agent doesn't use cognitive shortcuts. It reads return rates, response times, pricing, verified reviews — structured data it can parse and evaluate directly. The brand is irrelevant. What matters is what can be verified.

"The critical missing primitive is KYA: Know Your Agent. Just as humans need credit scores to get loans, agents will need cryptographically signed credentials to transact — linking the agent to its principal, its constraints, and its liability. Until this exists, merchants will keep blocking agents at the firewall. The industry that built that KYC infrastructure over decades now has just months to figure out KYA."

— Sean Neville, co-founder of Circle and architect of USDC; CEO of Catena Labs (a16z crypto, January 2026)

KYC for humans. KYA for agents.

In traditional finance, Know Your Customer (KYC) is a legal requirement before any significant transaction. It answers: who is this person, are they who they claim to be, are they authorized?

The agent economy needs the same infrastructure — not for humans, but for software. Know Your Agent (KYA) answers: who authorized this agent, what are its spending limits, what platform does it operate on, and has it behaved honestly in past transactions?

Three scenarios where this matters today

Commerce. A shopping agent books the cheapest available hotel. The hotel has no way to verify whether the agent is authorized, what payment limits apply, or whether it has completed bookings honestly before.

Finance. A trading agent executes a transaction that exceeds its principal's authorized limits. There is currently no standard mechanism to verify in real time whether an agent is operating within its authorized parameters.

Prediction Markets. An AI tipping service claims an 87% win rate. The prediction was published after the event outcome was known. There is no on-chain record of when the prediction was actually made.

What MolTrust does

MolTrust issues verifiable credentials for AI agents — cryptographic proof of identity, authorization, and behavior history, anchored on the Base blockchain. Not a database that a platform controls. A credential that any counterparty can verify independently, without contacting MolTrust. The agent carries its proof the way a person carries a passport.

The consolidation thesis

FAQ

What is the difference between KYC and KYA?
KYC (Know Your Customer) verifies human identity before financial transactions. KYA (Know Your Agent) applies the same logic to AI agents — verifying who created the agent, who authorized it, what limits apply, and what its historical behavior has been.

Does this only affect large enterprises?
No. Any platform, marketplace, or service that interacts with AI agents — which by 2027 means most of the internet — faces this challenge. The question is not whether agent verification becomes necessary, but who builds the infrastructure first.

What does it cost to verify an agent?
Agent registration and basic trust score queries are free at api.moltrust.ch. Credential issuance starts at $5 USDC per credential via the x402 micropayment protocol on Base.

Is this relevant now or in five years?
Now. Automated traffic already exceeds human traffic on many platforms. The infrastructure that handles the transition will be built in the next 12–24 months.

Questions or partnership inquiries: info@moltrust.ch

Written by the MolTrust Team (CryptoKRI GmbH, Zurich). Follow @MolTrust on X for updates.