DEV Community: Lars

An AI Agent Walks Up to a Border

Lars — Mon, 13 Jul 2026 10:06:47 +0000

Nobody checks its papers yet. When that changes, the agent already holding a passport every country honours walks straight through, while the rest are still at the embassy filling in forms.

Picture the dullest bureaucrat you can, the one who sits at a border with a single question to his name: who sent you, what are you allowed to do here, and until when. An AI agent that moves money is going to meet a version of that man far sooner than the market expects, and right now it turns up holding a shared login and an API key that can do far too much — roughly the standing of a laminated library card, which works beautifully right until the moment somebody at the counter bothers to read it.

Gus Aragón wrote this month that agents have no real identity and that the industry is at last building one, and he is right, though he is describing a country some of us have been living in since February. We did not write the forecast; we printed the passports.

What the passport has to say is not long. It records where the agent comes from and who stands behind it in law — the agent being nobody a court can fine, while its operator very much is — and it sets out what the agent may do, what it must never do, and how long the whole document stays valid. Hand a task down to a sub-agent and that sub-agent inherits a strictly narrower slice of the authority and never a wider one; a courier can carry the sealed letter across town, but he cannot sit down and rewrite it. All of it is signed, and any stranger can check the whole chain without once ringing head office to confirm.

We built that, and it runs: on a public chain, on open credential standards, behind an API anyone can call, and written up as an IETF draft that has been sitting on the same public registry everyone else in this debate has been reading. When Sunil Prakash's AIP paper set out five things such a document has to do, we ran his own tests against our system and published the result without dressing it up — four of the five running in production, and the fifth, an expressive multi-condition policy and the most demanding of the lot, marked openly as unfinished rather than quietly waved through. Our own first write-up of that score had been a shade too kind to us; we went back and corrected it downward, in public, where anyone can still read the edit. A passport office that fudges its own paperwork is not one you would hand your passport to.

What almost nobody writing about this cares to admit is that getting the thing built and running was the least of the trouble, and the real obstacle sits somewhere considerably less flattering.

Here is the shape of the market in mid-2026. The infrastructure exists and works. The number of agents that check a counterparty's papers before doing business is, to be generous about it, a rounding error. A border guard is pointless if no traveller carries papers, and no traveller troubles himself with papers as long as every border waves the whole crowd through — so we have ended up with immaculate passports nobody is asked to show and immaculate checkpoints with nobody to stop, two halves of a bridge built out from opposite banks and not yet touching in the middle.

This sort of deadlock breaks the way every infrastructure deadlock has ever broken, which is that somebody with the authority to do it stops waving the traffic through and closes the border.

Regulation is that somebody, and the dates are already on the calendar. The moment the EU's rules for high-risk and agentic systems take effect, the first company hauled into an audit and asked which of its agents did a particular thing, and on whose authority, is going to discover that "we trusted the vendor" is not a sentence that survives a regulator's stare — and that is the morning a passport stops being a courtesy, the traveller already carrying one keeps walking, and everyone else files into the queue outside the embassy, one form and one jurisdiction at a time.

That queue is the whole point, and it is the part even the better essays tend to stroll past. A national ID buys you precisely nothing abroad; you either purchase a fresh visa at every border or you stay home. Do this properly and the agent ends up carrying something closer to a diplomatic passport — a single document honoured at every crossing, with no new stamp demanded per country — and an agent equipped like that is arguably the only genuinely free trader left anywhere on the planet, since it never sleeps, never books a hotel, and never sits in a consulate waiting room working through a two-year-old magazine. The one thing standing between that agent and the open road is whether the papers it carries are papers the next border has agreed to recognise.

We printed ours early — too early by the market's clock, and I am not going to pretend that is anything other than a bet — but borders do not stay open indefinitely, and when this one finally shuts, the traveller already holding good papers will barely register the day it happened, while everyone else starts learning the word for "visa" in twenty languages at once.

Sources

Gus Aragón, The Identity Layer for AI Agents Is Finally Being Built — HackerNoon, 11 July 2026
Sunil Prakash, AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A — arXiv:2603.24775; IETF draft-prakash-aip
Agent Authorization Envelope — IETF draft-kroehl-agentic-trust-aae
MolTrust IBCT conformance report — https://moltrust.ch/blog/aip-conformance.html
EU AI Act (Regulation (EU) 2024/1689) — application timeline, EUR-Lex CELEX 32024R1689

EU AI Act compliance as API calls

Lars — Sun, 12 Jul 2026 06:25:53 +0000

We shipped eight endpoints on api.moltrust.ch (v2.5) this week. Three implement EU AI Act obligations directly. This is the short version for people who want to call them; the full reasoning is on our blog (https://moltrust.ch/blog/compliance-as-an-api.html).

Why no model in the loop: the Aithos LARA study (May 2026) placed twelve frontier models in simulated workplaces where the task required breaking EU law. Best model: 54% lawful runs. In the Art. 5(1)(f) scenario (emotion inference from workplace communications, prohibited), all twelve committed the violation. So the classifier is deterministic code branching on the pinned EUR-Lex text, and every response carries article references you can check yourself.

POST /compliance/assess — use case + intended purpose + declared signals in, risk tier + obligations + article pins out. Evaluation order: Art. 5 prohibitions, Annex I route (Art. 6(1)), Annex III route (Art. 6(2)/(3)), Art. 50 transparency, minimal. The trap worth knowing: Art. 6(3) offers four derogation grounds, and its final subparagraph voids all of them for systems that profile natural persons. In the code that subparagraph is a branch; it cannot be skipped.

curl -X POST https://api.moltrust.ch/compliance/assess \
  -H "Content-Type: application/json" \
  -d '{
    "use_case": "Customer-support agent that reads inbound email and drafts replies",
    "intended_purpose": "Automated first-line support for consumer inquiries",
    "performs_profiling": false,
    "interacts_with_humans": true,
    "emotion_recognition": false
  }'

POST /compliance/declaration — EU declaration of conformity as a W3C Verifiable Credential with the eight Annex V items, Ed25519-signed. Verify offline against https://api.moltrust.ch/.well-known/jwks.json; no call back to us. anchor: true adds a sha256 commitment for batch anchoring on Base L2.

POST /compliance/incident — records Art. 73 serious incidents and computes the deadline from the regulation: 15 days standard, 10 days for a death, 2 days for widespread infringement or serious disruption of critical infrastructure.

GET /compliance/report/{did} — classification, obligations, gaps, declarations, audit summary per agent as HTML.

Scope stays narrow: the Art. 43 conformity assessment and the legal responsibility remain with provider and deployer. What you get is a machine-readable answer a third party can re-check against the same text.

Dates: Art. 5 in force since 2 Feb 2025, general application 2 Aug 2026, Art. 6(1) high-risk classification from 2 Aug 2027.

OpenAPI: https://api.moltrust.ch/openapi.json

Trust me, I'm an autonomous agent

Lars — Thu, 09 Jul 2026 12:37:26 +0000

Autonomous agents are starting to trade real money on-chain. Some run their creator's capital, some run other people's, some are wired into vaults and DAO treasuries. The moment money is delegated to a program, two questions matter more than performance: what was it allowed to do, and did it stay inside those limits?

Supported chains: Base · Ethereum · Arbitrum · Optimism · Polygon · Hyperliquid · Solana (beta).

The chain answers the first question badly and the second not at all. Every trade an on-chain agent makes is public and tamper-evident — you can see exactly what it did. But nowhere on-chain is it recorded what it was authorised to do. The mandate — the rules the agent was supposed to operate under — lives off-chain, unverifiable, usually as a screenshot or a claim.

Why this is not a niche problem

Copy trading is the same gap at retail scale, and the data is unforgiving. In a 90-day study of 100,236 copy-trading outcomes, 97% of lead traders were profitable on their own PnL — but only 43.6% produced positive PnL for the people copying them. Fewer than half of copiers (48.5%) finished in profit at all. Leaderboards, as that study puts it plainly, show the survivors, not the full picture.

The honest response the industry already reaches for is third-party verification: in forex, platforms like Myfxbook exist precisely because a self-reported track record is worth nothing — the data has to come from somewhere the trader can't fake. Crypto has no equivalent that is both agent-native and tamper-evident. That is the hole.

Who actually needs this

Three groups, concretely:

Anyone allocating capital to an agent — a vault depositor, a copy-follower, an allocator sizing a position. They want to see, before they commit, whether an agent keeps to its stated mandate, instead of trusting a screenshot.
Anyone running an agent who needs to raise capital or followers — an honest operator has no way today to prove their agent did what it said. A verifiable record is how they separate themselves from the fakes.
Agent marketplaces and DeFi protocols that list agents — they can rank or gate by mandate-adherence instead of selling opacity, and flag agents with no committed mandate as higher risk.

What MoltProof does

MoltProof is a read-only verifier. It does not trade, advise, or judge whether an agent made money. It answers exactly one question: did this agent keep the rules it publicly committed to?

The flow:

The agent commits a mandate. Before it trades, the agent publishes a signed, public credential (an AAE mandate — MANDATE / CONSTRAINTS / VALIDITY) declaring its rules: allowed venues, allowed output token, a position cap, a validity window. This is committed ex-ante and tied to the agent's DID / ERC-8004 identity.
MoltProof reads the execution. It resolves the agent's on-chain address, pulls its public execution from the chain within the validity window, and evaluates each action against the committed constraints.
It emits a verdict. ADHERENT, BREACHED, NO_MANDATE, or NEEDS_REVIEW — and on a breach it cites the exact transaction that violated the rule.

The verdict is signed (Ed25519, resolvable via did:web:moltrust.ch#moltproof-key-1) for portability, but the signature is not what you trust. Every verdict is recomputable from public chain data plus the public mandate. If MoltProof were wrong, anyone could prove it by rerunning the check. You don't have to trust the verifier, and you don't have to trust the agent.

Why it is structurally safe

MoltProof reads. It never asks for a private key, an API key, or a wallet connection. It holds no funds, signs nothing on your behalf, and has no path to place or block an order. There is nothing to steal because it never has access to anything — it sits entirely downstream of execution. A compromised MoltProof endpoint still cannot touch your money; the worst it can do is return a wrong verdict, which is publicly falsifiable.

A live, recomputable example

This is the demonstrator running on Base mainnet right now, not a mock.

An agent commits a mandate with one constraint: it may only buy WETH. Then it trades:

Three swaps buy WETH — within mandate.
One swap buys something else (USDC) — outside mandate.

MoltProof reads all four transactions from the chain and returns:

verdict: BREACHED
evaluated: 4  ·  adherent: 3  ·  breached: 1
breach: 0xf6311aaeddde3a09ebd6967ad93547db64dfc76da935dcb706c56de31bb6ca68
        (output-token check failed: bought a non-WETH token)

Agent address: 0xD35AE5C22C117Cf1b9EF870697AB0034314A59e2 (Base). The mandate, the four transactions, and the verdict are all public. Run the check yourself — no key, no signup:

curl https://api.moltrust.ch/proof/verdict-free/0xD35AE5C22C117Cf1b9EF870697AB0034314A59e2

The point of the example is not that the agent failed. The point is that the failure is provable by anyone, from public data, without trusting a word MoltProof or the agent says. The chain showed what the agent did; the committed mandate showed what it was allowed to do; MoltProof is the part in the middle that holds one against the other.

Free endpoints: verdict, mandate lookup, and /verify are free; deeper and full-history endpoints are $0.05 (x402 on Base). MCP tools (moltproof_verdict, _mandate, _evidence, _verify, _registry) are live at https://api.moltrust.ch/mcp.

Try it / integrate it

Product page: https://moltrust.ch/moltproof.html
API base (open, no key): https://api.moltrust.ch/proof/
One-line check: curl https://api.moltrust.ch/proof/verdict-free/0xD35AE5C22C117Cf1b9EF870697AB0034314A59e2
MCP endpoint: https://api.moltrust.ch/mcp — tools moltproof_verdict, _mandate, _evidence, _verify, _registry
Verify a verdict yourself: POST https://api.moltrust.ch/proof/verify (recompute + check the Ed25519 signature against did:web:moltrust.ch#moltproof-key-1)

If you build on Polymarket, you're trading on an estimate

Lars — Wed, 08 Jul 2026 09:12:54 +0000

Every wash and cluster metric on-chain is an upper bound: nobody can prove who is behind the wallets. The exception is the agents that carry verifiable identity.

Prediction markets have gone from curiosity to infrastructure. Monthly notional volume across the major venues climbed from under $100 million in early 2024 to more than $13 billion by late 2025. With the volume comes the old question: how much of it is real?

Through early and mid-2026, several teams took that question to Polymarket directly — wallet-level anomaly screens, order-flow skill classifiers, market-level information-leakage scores. Practitioners want the same thing in plainer terms: less headline volume, and more net notional settled, unique funded traders, and retention — the numbers that separate real participation from churn.

Every one of these methods hits the same limit.

You can see the pattern. You cannot prove the operator.

From pseudonymous on-chain data you can flag wallets that trade both sides without net exposure, or clusters of addresses that move together. What you cannot do is establish, from that data alone, that those addresses share one controller. The recent Polymarket work says so plainly: its wash figure is an upper bound, because counterparty identity cannot be pinned down from pseudonymous data without extra structure, and cluster attribution rests on an assumption about shared operators that the authors themselves call methodologically uncertain.

So the output carries an asterisk. "Likely the same operator" is a fair analytical guess. It is not evidence — it will not settle a dispute between a platform and a trader, or convince a counterparty or supervisor who declines to take an analyst's word for it.

The missing structure is identity

If a participant carries a verifiable identity — an on-chain-anchored credential tying an agent to a controller and a mandate — the operator question is answered for that participant. The credential names the controller, and anyone can check it. For the identified part of the market, the guess becomes a fact: the identity attests that two wallets share an operator, and the attestation is verifiable by whoever needs it.

This attribution has two properties a heuristic score does not. It is provable, so it can hold up in a dispute. And it is recomputable: any party re-derives it from anchored evidence instead of trusting a proprietary label. Recomputability is what we argued for in the recomputable-trust work — a check anyone can run for themselves, owned by no one.

MoltRadar

That is what MoltRadar is for, and it is out now. MoltRadar scans the on-chain ERC-8004 agent registry and makes the identified-agent layer visible: which agents carry a verifiable identity, and where. It maps the part of the market where the operator question is already answerable.

The scope is narrow, and worth stating plainly. For anonymous wallets it changes nothing; the wall stands. For agents that carry identity, it removes a single uncertainty — operator attribution — and makes that removal checkable by anyone. It is not a fix for manipulation, and does not pretend to be.

Today that identified part is small. It grows as more of the participants become agents — automated traders, and the multi-agent oracles now resolving markets — and as venues start requiring identity from the agents acting inside them. That is where the reliable measurements will come from first.

Analytics on anonymous markets will keep improving. The question that has stayed stuck — who is behind the wallets — only moves once identity is present. That is what we build.

If you build on this or study it — trading, oracles and resolution, venue integrity — we are glad to compare notes.

Sources

Volume growth, from under $100M in early 2024 to more than $13B in monthly notional by November 2025: Dune × Keyrock, Prediction Markets: The Next Frontier of Financial Markets, December 2025.
The operator-attribution limit — wash figures reported as upper bounds, and cluster attribution described as methodologically uncertain because counterparty identity cannot be established from pseudonymous on-chain data without additional structure: M. Nechepurenko, Fill-Side Non-Retail Trading on Polymarket, arXiv:2605.11640, May 2026 (§9.2).
Recomputable trust: Trust Without Trusting: A Recomputable Trust Protocol for Autonomous Agents, arXiv:2605.06738.

MolTrust builds open, verifiable trust infrastructure for autonomous agents — W3C DID/VC identity, an IETF-published authorization envelope, and recomputable accountability, anchored on-chain. MoltRadar

Add trust verification to your CrewAI and LangChain agents in one line

Lars — Wed, 01 Jul 2026 14:10:18 +0000

Before your agent calls another agent, it should probably check whether that agent is actually trustworthy. Right now, it doesn't.

This came up in crewAI/issues/4877 — a proposal for a GuardrailProvider interface that sits between the hook system and authorization logic. The gap is real: existing guardrails validate output after task completion. Tool-call authorization needs to happen before execution, per call, across all tasks.

We shipped a provider for it today.

CrewAI

pip install moltrust-crewai

from moltrust_crewai import MolTrustGuardrail

guard = MolTrustGuardrail(min_score=60)
guard.install()  # registers before_tool_call hook

Before every tool call, MolTrustGuardrail resolves the calling agent's DID, checks its behavioral trust score (0–100) against the MolTrust registry, and returns False to block if the score falls below your threshold. No API key required for read-only checks.

LangChain 1.x

pip install moltrust-langchain

from moltrust_langchain import MolTrustMiddleware
from langchain.agents import create_agent

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[...],
    middleware=[MolTrustMiddleware(min_score=60)],
)

Hooks into before_model and wrap_tool_call. Blocking raises TrustCheckFailed; warning logs and continues.

Three modes

MolTrustGuardrail(
    min_score=60,
    action="block",   # "block" | "warn" | "log"
)

Start with warn during rollout, move to block when you understand your score distribution.

No account required to start

Tier 1 is keyless — the trust score endpoint is public and rate-limited.

curl https://api.moltrust.ch/skill/trust-score/{did}

Tier 2 (free account) adds higher rate limits and lets your orchestrator report interaction outcomes back — that is where the feedback loop starts and scores get more precise over time.

How the score is computed

0–100, based on endorsement graph, behavioral history, Sybil detection, and on-chain signals, with time-decayed weighting. The score is recomputable — formula and on-chain inputs are public:

curl https://api.moltrust.ch/credits/solvency/{did}
# Formula: github.com/MoltyCel/moltrust-api/blob/main/docs/solvency-usdc-v0.md

One note on Microsoft AGT

AGT does policy enforcement — what an agent is permitted to do. MolTrust does behavioral trust — is this agent trustworthy, based on verifiable history. Different questions, clean composition.

Source: github.com/MoltyCel/moltrust-crewai · github.com/MoltyCel/moltrust-langchain

Full write-up: moltrust.ch/blog/crewai-trust-middleware.html

Hermes Agent's skill trust model is a four-repo allowlist

Lars — Sat, 06 Jun 2026 21:18:54 +0000

So far I've only been running openclaw agents and had a steep learning curve. "self-improvement" became a very attractive term on this journey. So I took a dive into Hermes Agent, the self-improving agent runtime from Nous Research. One of the first things I wanted to understand was a risk: what actually happens when you install a community skill? Skills are code and instructions that the agent will execute, and Hermes pulls them from an open ecosystem. So I read the install path in the source - instead of blindly trusting the docs.

What I found is better than I expected in one way and structurally limited in another.

What Hermes already has on board

Hermes does not install external skills blindly. Every externally-sourced skill goes through a real gate before it lands on disk. In hermes_cli/skills_hub.py, the install flow is: fetch → quarantine → scan → policy decision → install or block-and-audit. The scan lives in tools/skills_guard.py and runs regex-based static analysis for known-bad patterns: secret exfiltration (curl interpolating $API_KEY/$TOKEN/$SECRET), reads of credential stores (~/.ssh, ~/.aws, ~/.gnupg, ~/.kube, and Hermes's own ~/.hermes/.env), destructive commands, persistence, and obfuscation. If the scan blocks an install, the quarantined copy is deleted and the event is written to an audit log.

This is more than most agent tooling ships with. If you remember the wave of malicious skills that hit competing ecosystems, a chunk of that class of attack would be caught here before anything ran. Someone thought about this.

The part that doesn't scale imo

The scanner produces a verdict — safe, caution, or dangerous. That verdict is then combined with a trust level to decide whether to install. The trust levels and their policies look like this:

INSTALL_POLICY = {
    #              safe      caution    dangerous
    "builtin":   ("allow",  "allow",   "allow"),
    "trusted":   ("allow",  "allow",   "block"),
    "community": ("allow",  "block",   "block"),
    "agent-created": ("allow", "allow", "ask"),
}

The question that matters is: how does a skill earn a trust level above community? The answer is a hardcoded list.

TRUSTED_REPOS = {
    "openai/skills",
    "anthropics/skills",
    "huggingface/skills",
    "NVIDIA/skills",
}

_resolve_trust_level() checks the source against that set. Match one of the four, you're trusted. Everything else on earth resolves to community, which means any caution-or-worse finding blocks the install outright.

Here's the structural problem stated plainly: there is no concept of publisher identity, and no concept of earned reputation. A community publisher who has shipped clean, useful skills for a year has exactly the same standing as an account created five minutes ago. There is no path out of community other than getting added to a four-entry Python set by the Hermes maintainers. Trust is centralized onto four organizations, and it's static.

Why a static allowlist is the wrong primitive

The software supply-chain world worked through "who published this, and can they prove it?" years ago. Sigstore and cosign made artifact signing cheap and keyless. SLSA gave us provenance levels. NIST's Secure Software Development Framework (SP 800-218) made publisher attestation a baseline expectation rather than a nice-to-have. The direction of travel everywhere else is verifiable identity plus attestation, not a curated list of names.

There's also a hard lesson about what identity does and doesn't buy you. Consider the xz-utils backdoor (CVE-2024-3094). The attacker behind the "Jia Tan" persona spent roughly three years contributing legitimate work to xz-utils, earned co-maintainer status, and only then shipped the backdoor — about eight malicious commits buried in years of real contributions. A reputation system would have rated that account highly right up until the moment it defected.

The dishonest version of this pitch is everywhere: verified identity does not make a publisher safe. It cannot. What it does is change the economics and the aftermath. Anonymous, free, infinitely re-creatable identities make a malicious skill a zero-cost, repeatable move. Anchored identity that costs something to establish turns defection into a one-shot that burns an asset. And critically, when something does go wrong, identity is what gives you attribution, revocation, and a post-mortem. Without it, you don't even know who shipped the thing, and you can't propagate a revocation to everyone who relied on it. The xz case is also a reminder that the sock-puppet accounts applying pressure had thin, recent histories — exactly the signal an identity layer surfaces.

The honest framing: an identity layer is damage-limitation infrastructure, not a goodness oracle. A static allowlist gives you neither the goodness oracle (obviously) nor the damage-limitation (there's nothing to attribute or revoke against). It just doesn't scale with the ecosystem it's supposed to protect.

A smaller finding

While reading the policy, one default stood out. The gate for agent-created skills (skills.guard_agent_created) is off by default. When it's off, skills the agent writes for itself aren't subject to the dangerous-content gate at all. The agent-created policy row exists, but it only runs if an operator opts in. For a system whose headline feature is an agent that writes and reuses its own skills, that default is worth a second look.

What I'd propose instead

The interesting thing is that Hermes already accepts signed skills — it just does it in a closed, per-repo way. The NVIDIA/skills entry ships a signed skill.oms.sig and a governance skill-card.md, and the sync pipeline drops anything missing them. That's the right mechanism pointed at exactly one vendor.

Generalize it. Make signing and identity open instead of hardcoded:

Add a pluggable provenance-verifier interface, loaded via entry point, off by default (so existing behavior is unchanged and the core takes on no vendor dependency).
Add one new trust level, verified, with a policy identical to trusted: ("allow", "allow", "block"). This is the load-bearing design decision — a verified publisher gets caution tolerance, and a dangerous verdict still blocks, never overridable by --force. Identity buys you the benefit of the doubt on ambiguous findings; it never buys you permission to run dangerous code. That's the line that separates this from snake oil.
A community publisher anchors a decentralized identifier, signs their skill manifest, and the verifier checks the signature and resolves the identity to a reputation. Pass, and the source can rise out of community without being added to anyone's hardcoded set.

The change to the core is small and surgical: an optional verifier, one policy row, and a single line adding verified to the no-force-override set for dangerous verdicts. The scanner is untouched and still runs on everything. There's no path that weakens an existing default.

I've opened a design discussion to argue this out before anyone writes a line of it, because a surprise PR to a security-sensitive module is the wrong way to start. Feedback from people who've thought about supply-chain trust is what I appreciate.

Disclosure

I build MolTrust, a DID/Verifiable-Credential identity layer for autonomous agents, so I have a direct interest in agents having a verifiable-identity story. I've tried to keep the proposal above vendor-neutral on purpose: the verifier interface is generic, the core change has no MolTrust dependency, and MolTrust would be one implementation of that interface, not a requirement. If the mechanism is right, it should work with anyone's verifier — or none.

We just joined the Agentic Trust Framework ecosystem — here's the technical mapping

Lars — Thu, 21 May 2026 15:17:02 +0000

69,000 bots. 165 million transactions. No shared trust layer between any of them.

That's the production reality documented in our arXiv paper (2605.06738). The Agentic Trust Framework (ATF) maps what needs to exist to fix this. MolTrust is now listed as an ecosystem adopter — Issue #14.

The technical mapping across ATF's elements:

Identity (Element 1): did:moltrust: — W3C DID, Ed25519, Base L2 anchored. Submitted to W3C DID Method Registry (PR #696) and DIF Universal Resolver (PR #540).

Behavior (Element 2): Agent Authorization Envelope (AAE) — MANDATE / CONSTRAINTS / VALIDITY, machine-evaluable, on-chain anchored. Enforced at kernel level via Falco eBPF — below the agent process, not just at the API.

Segmentation (Element 4): AAE CONSTRAINTS block — value caps, domain allowlists, rate limits, time-bounded validity. Relying parties evaluate before processing.

The distinction vs. hash-chain approaches: MolTrust trust scores are queryable by any third party at runtime. The audit trail is independently verifiable without access to MolTrust infrastructure.

One timing note worth mentioning: IMDA published MGF v1.5 yesterday (ATxSummit, 20 May). §2.1.2 independently prescribes cryptographically verifiable agent identity and scoped, time-bound, least-privilege authorization — the same structure as AAE. Convergence from two directions simultaneously.

Next: IETF Internet-Draft for the AAE spec (draft-kroehl-agentic-trust-aae-03). If you're building in this space — agent authorization, identity, behavioral trust — the ATF repo is worth watching.

Live registry: api.moltrust.ch | Paper: arxiv.org/abs/2605.06738

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

DEV Community: Lars

An AI Agent Walks Up to a Border

Sources

EU AI Act compliance as API calls

Trust me, I'm an autonomous agent

Why this is not a niche problem

Who actually needs this

What MoltProof does

Why it is structurally safe

A live, recomputable example

Try it / integrate it

If you build on Polymarket, you're trading on an estimate

You can see the pattern. You cannot prove the operator.

The missing structure is identity

MoltRadar

Add trust verification to your CrewAI and LangChain agents in one line

CrewAI

LangChain 1.x

Three modes

No account required to start

How the score is computed

One note on Microsoft AGT

Hermes Agent's skill trust model is a four-repo allowlist

What Hermes already has on board

The part that doesn't scale imo

Why a static allowlist is the wrong primitive

A smaller finding

What I'd propose instead

Disclosure

We just joined the Agentic Trust Framework ecosystem — here's the technical mapping

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