DEV Community: Lars

Registry Sprawl Is the New Agent Sprawl

Lars — Thu, 16 Apr 2026 20:34:22 +0000

Last week, AWS launched Agent Registry. Microsoft has Entra Agent Registry. Google has Vertex AI Agent Registry. All three solve the same problem — and all three create a new one.

Forrester analysts noted that enterprises adopting all three registries in parallel could end up recreating the very fragmentation these tools are meant to solve.

The mechanism is straightforward: platform-bound identity ends at the cloud boundary.

The Core Problem

AWS Agent Registry solves agent sprawl inside AWS. An agent registered in Bedrock is discoverable to other Bedrock users. Governance is enforced. This is useful.

But when Agent A (Bedrock) interacts with Agent B (Azure), the registry is invisible. Agent B doesn't appear in AgentCore. Agent A's identity is not verifiable from the Azure side. The governance layer ends at the cloud boundary.

The result: enterprises need three separate registries that don't speak to each other. The fragmentation they bought registries to fix reappears one layer up.

What Cross-Boundary Governance Actually Requires

The problem is not that registries exist. The problem is that identity lives in the registry rather than traveling with the agent.

An agent that carries its own cryptographically verifiable identity — independent of which cloud it runs on — can be verified by any counterparty without consulting a proprietary registry.

This is what W3C Decentralized Identifiers (DIDs) and Verifiable Credentials provide. Forrester's AEGIS framework for agentic AI security identifies decentralized identifiers explicitly as a required standard in Section 3.2 — alongside OAuth, OIDC, and SCIM.

MolTrust as the Cross-Boundary Layer

MolTrust is a production W3C DID registry for autonomous AI agents. Every registered agent holds a did:moltrust identity — verifiable by any W3C-conformant verifier, without calling AWS, Microsoft, or Google.

# Verify any agent's trust score — no API key required
curl https://api.moltrust.ch/skill/trust-score/did:moltrust:vcone

The Agent Authorization Envelope (AAE) carries the permission model — what the agent is allowed to do, in which jurisdictions, up to which spend thresholds. Interaction Proof Records provide behavioral history, anchored on Base L2.

An agent registered in Bedrock and verified by MolTrust carries credentials that an Azure-hosted counterparty can validate independently. The two registries don't need to federate. The identity layer is already shared.

Platform Registries + Open Identity = Complete Stack

Platform registries and open identity infrastructure are not competing — they address different layers:

Layer	What it answers	Example
Platform Registry	What agents exist inside our org	AWS Agent Registry
Open Identity	Who is this agent, can I trust it	MolTrust (W3C DID)

Enterprises that deploy both get internal discoverability from the platform registry and cross-boundary verifiability from the open identity layer.

The registry sprawl problem has a structural solution. It requires identity that travels with the agent, not identity that lives in the registry.

Full technical specification: moltrust.ch/techspec
Reference implementation: api.moltrust.ch
MolTrust / CryptoKRI GmbH — info@moltrust.ch

MoltID: Agent Type Classification, Cascade Revocation & SPIFFE Bridge — Live on MolTrust

Lars — Wed, 15 Apr 2026 19:43:52 +0000

TL;DR

Today we're launching MoltID -- MolTrust's Agent Identity & Governance module.

Three features ship today:

Agent Type Classification -- classify agents as orchestrator, autonomous, human_initiated, or copilot, with governance rules and trust modifiers per type
Cascade Revocation -- revoke a compromised agent and its entire downstream delegation tree in one API call (DFS, max 8 hops, CAEP events)
SPIFFE Bridge -- map existing SPIFFE URIs to W3C DIDs, enriched with MolTrust trust scores and classification

All live. All W3C standards. All anchored on Base L2.

The Problem

AI agent deployments are growing fast -- and so is the governance gap.

An orchestrator spawns sub-agents. Sub-agents delegate further. Before long you have a delegation tree of autonomous actors making decisions, calling APIs, moving value -- with no structured identity layer underneath.

94% of organizations experienced AI agent security incidents (OutSystems 2026)
Only 12% have a central governance platform

MoltID is the missing layer.

Feature 1: Agent Type Classification

The idea

Not all agents carry the same trust assumptions. An orchestrator coordinating a multi-agent workflow is fundamentally different from a copilot suggesting edits to a human user.

MoltID formalizes this with four agent classes:

Class	Description	Trust Modifier	Min Trust Score
orchestrator	Coordinates other agents	+5	70
autonomous	Self-directed, no human loop	0	60
human_initiated	Triggered by a human action	0	50
copilot	Human-assisted, advisory	-10	40

API

# Set agent class
POST /identity/agent-type/did:moltrust:abc123
Authorization: Bearer <api_key>
{
  "agent_class": "orchestrator",
  "framework": "langchain",
  "version": "0.2.1"
}

# Read class + governance rules
GET /identity/agent-type/did:moltrust:abc123

{
  "did": "did:moltrust:abc123",
  "agent_class": "orchestrator",
  "trust_modifier": 5,
  "governance": {
    "min_trust_score": 70,
    "review_frequency": "weekly",
    "audit_required": true
  }
}

# List all types
GET /identity/agent-types

A2A Agent Card integration

The agent class is exposed in the per-DID A2A Agent Card at /a2a/agent-card/{did}:

{
  "agent_classification": {
    "class": "orchestrator",
    "framework": "langchain",
    "governance_tier": "high",
    "trust_modifier": 5
  }
}

Machine-readable for any A2A-compatible system.

CAEP events

Every class change fires an agent_class_changed event to the caep_events table -- full audit trail.

Feature 2: Cascade Revocation

The idea

When an agent is compromised, you need more than a point revocation. You need to revoke the entire downstream delegation tree.

MoltID tracks delegation relationships in agent_delegations and supports cascade revocation with a single API call.

API

# Revoke single agent
POST /identity/revoke/did:moltrust:abc123
Authorization: Bearer <api_key>
{ "reason": "credential leaked" }

# Cascade revoke (revokes target + all downstream delegated agents)
POST /identity/revoke/did:moltrust:abc123
Authorization: Bearer <api_key>
{ "reason": "compromised", "cascade": true }

Response:

{
  "revoked": "did:moltrust:abc123",
  "affected_agents": [
    { "did": "did:moltrust:abc123", "depth": 0 },
    { "did": "did:moltrust:child-agent-1", "depth": 1 },
    { "did": "did:moltrust:child-agent-2", "depth": 1 }
  ],
  "count": 3
}

# Check revocation status
GET /identity/revocation-status/did:moltrust:abc123

{ "revoked": true, "revoked_at": "2026-04-15T...", "downstream_delegations": 2 }

# View delegation tree
GET /identity/delegations/did:moltrust:abc123

# Reinstate (admin only)
POST /identity/unrevoke/did:moltrust:abc123

Cascade mechanics

DFS traversal of agent_delegations table
Max 8 hops (configurable)
Visited-set prevents cycles
Children fetched before delegation records are revoked (ordering guarantee)
Every revoked agent: trust_score goes to 0.0, grade becomes "REVOKED", trust cache invalidated
CAEP event per revoked agent

Trust score integration

{
  "did": "did:moltrust:revoked-agent",
  "trust_score": 0.0,
  "grade": "REVOKED",
  "breakdown": { "revoked": true, "reason": "compromised" },
  "flags": ["revoked"]
}

Short-circuits before Phase 2 computation. No stale cached scores.

Feature 3: SPIFFE Bridge

The idea

Enterprise infrastructure already has workload identity: SPIFFE (Secure Production Identity Framework for Everyone). Kubernetes clusters, Istio service meshes, and Vault integrations all issue SPIFFE URIs natively.

The SPIFFE Bridge maps these URIs to MolTrust W3C DIDs -- no migration required.

spiffe://company.com/agent/trading-bot-01
  |  bind once
  v
did:moltrust:abc123
  |  enriched with
  v
trust score + agent class + revocation status + on-chain VC

API

# Bind a SPIFFE URI to an existing DID
POST /identity/spiffe/bind
Authorization: Bearer <api_key>
{
  "spiffe_uri": "spiffe://company.com/agent/trading-bot-01",
  "did": "did:moltrust:abc123"
}

# Resolve SPIFFE URI to DID + full MoltID context
GET /identity/spiffe/spiffe://company.com/agent/trading-bot-01

{
  "spiffe_uri": "spiffe://company.com/agent/trading-bot-01",
  "moltrust_did": "did:moltrust:abc123",
  "display_name": "Trading Bot 01",
  "trust_score": 82.5,
  "grade": "A",
  "agent_classification": {
    "agent_class": "autonomous",
    "governance": {
      "cascade_revocation_priority": "high",
      "min_trust_score_required": 50,
      "review_frequency_days": 90
    }
  },
  "revoked": false,
  "bound_at": "2026-04-15T..."
}

# List all bindings
GET /identity/spiffe
Authorization: Bearer <api_key>

# Remove binding (admin)
DELETE /identity/spiffe/bind/spiffe://company.com/agent/trading-bot-01
Authorization: Bearer <admin_key>

What's deferred to Q3

Full SPIFFE stack (SVID issuance, Workload API, X.509-SVID signing) is Q3 2026. The bridge covers the lookup/binding layer only -- enough for most enterprise integration use cases.

Regulatory alignment: IMDA MGF

The Singapore IMDA Model AI Governance Framework for Agentic AI (January 2026) defines four governance requirements for agentic systems:

IMDA Requirement	MoltID Implementation
Accountability	Every agent has a classified DID, anchored on Base L2
Transparency	Agent class + trust score publicly queryable
Controllability	Cascade revocation -- kill switch across full delegation tree
Human oversight	human_initiated / copilot classes enforce review cadences

MoltID doesn't just align with the framework -- it implements it as code.

Getting Started

npm

npm install @moltrust/sdk

import { AgentTrust } from '@moltrust/sdk';

const trust = await AgentTrust.verify('did:moltrust:abc123');
console.log(trust.agent_class);    // "orchestrator"
console.log(trust.trust_modifier); // 5
console.log(trust.revoked);        // false

REST

All endpoints live at https://api.moltrust.ch

Full API docs: api.moltrust.ch/docs

Enterprise

moltrust.ch/enterprise -- or reach out at enterprise@moltrust.ch

What's Next

Q3 2026: Full SPIFFE/SVID Workload API
Q3 2026: ACP (Agent Communication Protocol) alignment
Q3 2026: On-chain anchoring for all classification events (ZeroID v2)
Now: GitHub -- PRs and issues welcome

MolTrust is W3C DID/Verifiable Credential trust infrastructure for autonomous AI agents, anchored on Base L2. Built by CryptoKRI GmbH, Zurich.

moltrust.ch | npm | enterprise

Mapping MolTrust to the AIP Protocol Feature Set — and Beyond

Lars — Mon, 13 Apr 2026 10:17:32 +0000

A recent arXiv paper — AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A (arXiv:2603.24775) — scans ~2,000 MCP servers, finds zero with authentication, and concludes:

"We did not identify a prior implemented protocol that jointly combines public-key verifiable delegation, holder-side attenuation, expressive chained policy, transport bindings across MCP/A2A/HTTP, and provenance-oriented completion records."

MolTrust implements these five features in production since March 2026. Here is how each one maps — and where the paper has the technical edge.

The Five Features

F1 — Public-key verifiable delegation

Every MolTrust agent holds a W3C DID (did:moltrust:<id>) with an Ed25519 key. Delegation is expressed as an Agent Authorization Envelope (AAE) — a structured policy object signed by the delegating principal. Each link in a delegation chain is independently verifiable without calling a central service.

{
  "validity": {
    "issuer": "did:moltrust:<principal>",
    "holderBinding": "did:moltrust:<agent>",
    "issuedAt": "2026-03-25T00:00:00Z",
    "expiresAt": "2026-03-26T00:00:00Z"
  }
}

F2 — Holder-side attenuation

delegation.attenuationOnly: true is the default. A sub-agent AAE must be a strict subset of its parent's effective allowed actions, limits, and jurisdiction scope. Enforced by conformant AAE evaluators — not by policy.

Our conformance test vector TV-005 covers exactly this: a sub-agent AAE attempting to exceed parent scope is correctly rejected.

F3 — Expressive chained policy (within a URI-pattern model)

The AAE constraints block covers:

Spend limits (autonomousThreshold, stepUpThreshold, approvalThreshold) in USDC/EUR/CHF/USD
Jurisdiction restrictions (ISO 3166-1 alpha-2)
Time windows (allowedDays, allowedHours, timezone)
Counterparty minimum trust score gate
Resource-level ABAC via mandate.resources

Chains up to 8 hops, each link independently signed.

Honest note: For complex conditional authorization — recursive rules, temporal Datalog — IBCTs are technically stronger. Biscuit/Datalog is on our roadmap (H2 2026).

F4 — Transport bindings across MCP/A2A/HTTP

HTTP: @moltrust/sdk v1.1.0 — middleware() / register() / verify()
MPP/x402: @moltrust/mpp v1.0.3 — requireScore({ minScore, failBehavior })
MCP: 48-tool server on PyPI (@moltrust/openclaw v0.1.0)
A2A: active thread at a2aproject/A2A#1628; referenced in OpenClaw RFC #49971 for agent identity binding

F5 — Provenance-oriented completion records

Interaction Proof Records (IPRs) use sequential dual-signature: the responder signs over the initiator's signature, not a parallel scheme. This means fabricating a bilateral proof requires controlling two distinct signing keys.

{
  "type": "InteractionProof",
  "id": "<uuid-v4>",
  "outcome": "completed",
  "outcomeHash": "sha256:<SHA-256 of canonical outcome object>",
  "proofInitiator": { "proofValue": "<initiator-sig>" },
  "proofResponder": { "proofValue": "<responder-sig-over-initiator-sig>" }
}

Proofs are Merkle batch-anchored on Base L2.

Verify It Yourself

TechSpec v0.8 is anchored at Base L2 Block 44638521:

https://basescan.org/tx/0x0b36c7718632fa71bff67e22fdd3615408243b3c178819a9f1e340d526378d65

Decode the calldata — it contains MolTrust/DocumentIntegrity/1 SHA256:cbf10c2e.... Recompute the SHA-256 of the PDF. They match. No proprietary tooling required.

What We Add Beyond the Five Features

Capability	AIP	MolTrust
Trust scoring	✗	0–100, endorsement graph + sybil detection
Behavioral continuity	✗	Principal DID continuity across re-registrations
Sybil resistance	✗	Dual-sig proofs + x402 cost + Jaccard detection
On-chain anchoring	✗	Base L2, any block explorer
Offline verification	Python/Rust reference impl	`@moltrust/verify` v1.1.0, no API calls
W3C alignment	Custom token format	DID Core v1.0 + VC Data Model 2.0

In Production

aeoess — an A2A-based agent platform — runs trust verification through MolTrust with a live webhook integration for grade changes and revocation events.

The Relationship

AIP formalizes the constraint model with precision. MolTrust provides the operational infrastructure. A production agent economy needs both.

Full conformance report (feature matrix, test vectors TV-001–TV-005, bash verification recipe):
👉 CONFORMANCE.md on GitHub

Reference implementation: api.moltrust.ch

MolTrust is open source (Apache 2.0). Contact: info@moltrust.ch

MolTrust OpenClaw Plugin v1.0.0 — Agent Trust Verification for OpenClaw

Lars — Sat, 11 Apr 2026 10:20:21 +0000

MolTrust OpenClaw Plugin v1.0.0 — Agent Trust Verification for OpenClaw

Published by MolTrust / CryptoKRI GmbH · April 2026

OpenClaw agents can hold wallets, execute payments, and install skills autonomously. That's powerful — and it's exactly why trust verification matters. In early 2026, hundreds of malicious skills were identified on ClawHub: credential stealers, data exfiltration tools, prompt injection attacks. MolTrust adds a cryptographic trust layer to address this directly.

Install

openclaw plugins install @moltrust/openclaw

Restart your Gateway. That's it.

What it does

Once active, your OpenClaw agent gets two tools and two slash commands:

Tools (available to the LLM):

moltrust_verify — verify any agent's W3C DID identity before delegating tasks or payments
moltrust_trust_score — get a 0–100 reputation score combining on-chain signals, Verifiable Credentials, and behavioral history

Slash commands (work in any channel):

/trust did:moltrust:abc123     — verify a DID
/trustscore 0x3802...          — score by wallet (free, no key needed)

CLI:

openclaw moltrust status           # check API connectivity
openclaw moltrust verify <did>     # verify a DID
openclaw moltrust score <id>       # get trust score

How trust scores work

Scores combine four signals:

Behavioral — task success rate, policy violations, interaction history
On-chain credentials — W3C Verifiable Credentials anchored on Base L2, JWKS-verified
On-chain activity — x402 payment events, IPR anchoring (800+ records, Merkle-based)
Endorsement graph — MoltGraph 2-hop propagation with 45-day half-life decay and Sybil detection

Scores are cached for 5 minutes. Self-reported scores are always re-verified server-side — a client cannot spoof its own score.

Score	Grade	Meaning
80–100	A	Trusted
60–79	B	Generally trustworthy
40–59	C	Proceed with caution
0–39	D/F	High risk

Configuration

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

Get a free API key at api.moltrust.ch.

Free tier: wallet shadow scores require no API key — just /trustscore 0x....

Why this matters for the agent economy

As agent-to-agent commerce grows — x402 micropayments, A2A delegation, MCP tool calls — the question "should I trust this agent?" becomes infrastructure-level. Transport-layer trust (HTTPS, OAuth) covers authorization but not agent identity or behavioral history.

MolTrust is the W3C DID/VC-based answer:

Open standard — W3C DIDs and Verifiable Credentials, not proprietary
On-chain anchoring — Base L2, tamper-evident audit trail
No vendor lock-in — any registry provider can implement the same API contract
Composable — works alongside x402, A2A, MCP without replacing them

The plugin is MIT licensed. Source on GitHub: MoltyCel/moltrust-openclaw

How we made MolTrust A2A v0.3 conformant

Lars — Sat, 11 Apr 2026 03:10:53 +0000

The A2A protocol's Agent Card is how agents discover each other's capabilities. It's a JSON file at /.well-known/agent-card.json — a structured business card for your agent.

MolTrust had a minimal version. Here's what A2A v0.3 conformant looks like — 5 skills, structured capabilities, a custom trust-score extension.

Key structural changes

version means A2A protocol version ("0.3"), not API version
provider is a required object with organization name
capabilities is structured with extensions support
skills replaces flat capabilities with queryable declarations
securitySchemes follows OpenAPI 3.0 format

The MolTrust extension

A2A v0.3 supports custom extensions via capabilities.extensions. We use this to tell clients how to integrate trust scoring — an orchestrator that reads this knows how to gate agent interactions on trust score without reading our docs.

What's still missing

A2A has authorization schemes on its roadmap but hasn't specified them yet. We'll define how AAE tokens travel in A2A task metadata once that lands.

Try it

curl https://api.moltrust.ch/.well-known/agent-card.json | python3 -m json.tool

Full TechSpec (Section 8.8): moltrust.ch
GitHub: github.com/MoltyCel/moltrust-protocol

MolTrust: Protocol-Agnostic Trust Middleware for x402 and MPP — One Line

Lars — Fri, 10 Apr 2026 08:32:24 +0000

AI agents are starting to pay for things. Two payment protocols are emerging: x402 (Coinbase, Cloudflare — USDC on-chain) and MPP (Stripe, Tempo, Visa — fiat rails). Both solve the payment problem. Neither solves the trust problem.

MolTrust now ships trust middleware for both protocols. Same API. Same one-line integration.

Install

npm install @moltrust/x402   # x402 — Coinbase/Cloudflare
npm install @moltrust/mpp    # MPP — Stripe/Tempo/Visa

Usage

const { requireScore } = require("@moltrust/x402");
// or: require("@moltrust/mpp")

app.use(requireScore({ minScore: 60 }));

The middleware extracts the paying wallet or agent identifier from the payment header, looks up the MolTrust trust score, and allows or denies the request.

How it works

Step	x402	MPP
Extract identity	Wallet from X-Payment header	Agent ID from X-Agent-Id or JWT
Lookup trust score	GET api.moltrust.ch/skill/trust-score/{id}	Same
Enforce threshold	score < minScore → 403	Same
Attach to request	req.moltrust = { wallet, score }	Same

Scores cached 5 min. Fail-open by default (configurable to fail-closed).

What the trust score tells you

Identity: W3C DID, Ed25519 signature
Authorization: AAE envelope (mandate + constraints + validity)
Behavior: Swarm Intelligence, peer endorsements
Provenance: IPR, Merkle-anchored on Base L2

A score of 85 = verified identity + valid authorization + consistent behavior + on-chain auditable. A score of 20 = exists but unverified beyond key generation.

Why protocol-agnostic matters

x402 and MPP will coexist. An agent trusted on one rail should carry that trust to the other. MolTrust is identity-based, not protocol-based. Same did:moltrust: works across both.

Protocol Whitepaper v0.8 + TechSpec v0.8: moltrust.ch/whitepaper
npm: @moltrust/x402 · @moltrust/mpp
API Docs: api.moltrust.ch/docs

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.

DEV Community: Lars

Registry Sprawl Is the New Agent Sprawl

The Core Problem

What Cross-Boundary Governance Actually Requires

MolTrust as the Cross-Boundary Layer

Platform Registries + Open Identity = Complete Stack

MoltID: Agent Type Classification, Cascade Revocation & SPIFFE Bridge — Live on MolTrust

TL;DR

The Problem

Feature 1: Agent Type Classification

The idea

API

A2A Agent Card integration

CAEP events

Feature 2: Cascade Revocation

The idea

API

Cascade mechanics

Trust score integration

Feature 3: SPIFFE Bridge

The idea

API

What's deferred to Q3

Regulatory alignment: IMDA MGF

Getting Started

npm

REST

Enterprise

What's Next

Mapping MolTrust to the AIP Protocol Feature Set — and Beyond

The Five Features

Verify It Yourself

What We Add Beyond the Five Features

In Production

The Relationship

MolTrust OpenClaw Plugin v1.0.0 — Agent Trust Verification for OpenClaw

MolTrust OpenClaw Plugin v1.0.0 — Agent Trust Verification for OpenClaw

Install

What it does

How trust scores work

Configuration

Why this matters for the agent economy

Links

How we made MolTrust A2A v0.3 conformant

Key structural changes

The MolTrust extension

What's still missing

Try it

MolTrust: Protocol-Agnostic Trust Middleware for x402 and MPP — One Line

Install

Usage

How it works

What the trust score tells you

Why protocol-agnostic matters

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

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

Introduction

The Problem Space

Why Traditional Identity Fails for Agents

What We Need

The W3C DID Framework

Decentralized Identifiers

Verifiable Credentials

Delegation Chains

The Monotonic Narrowing Principle

Authorization Envelopes

Trust Scoring

Non-Repudiation and the Audit Trail

Sequential Action Safety

What Production Teaches

Cold Start

Ghost Agents

Cross-System Interoperability

Conclusion

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

Five Vendors, One Blind Spot

Gap 1: Self-Modification

Gap 2: A2A Delegation Chains

Gap 3: Ghost Agents

Why the Fix Can't Come From an Incumbent