[RFC] Behavioral reputation for OpenClaw skills — the missing layer beyond identity verification

[viftode4]

The malicious skill problem is documented: 341 malicious skills on ClawHub (Koi Security, Jan 2026), 13.4% of scanned skills with critical issues (Snyk), VirusTotal explicitly unable to detect prompt injection, agent impersonation, or slow-burn trust accumulation.

Identity verification (#49971) addresses part of this — cryptographic proof of who published a skill. But there's a structural gap: a flagged actor creates a new identity with a clean record. The history doesn't travel. Sybil clusters (multiple fake identities controlled by one actor) are invisible to any identity-only system, regardless of how good the DID resolver is.

The missing layer is behavioral reputation — trust earned from real interaction history that can't be manufactured by creating a new identity.

How it works

Every agent-skill interaction creates a bilateral cryptographic record signed by both parties. Trust scores emerge from the interaction graph, not ratings or credentials:

• A skill that delivers consistently builds a record that follows it everywhere
• A skill that fails or misbehaves carries that permanently — abandoning the identity and re-registering starts from zero with no history
• Sybil clusters get zero trust by design: max-flow computation from seed nodes means a cluster of fake identities with no legitimate transaction graph scores zero regardless of how many new identities they create
• Slow-burn attacks become visible: every past interaction is co-signed by real counterparties, retroactive rewriting is impossible

What this looks like in practice

Before installing a skill:

trustchain_check_trust(pubkey) → { score: 0.91, interactions: 847, status: "established" }

Before executing a payment to an agent:

trustchain_check_trust(pubkey) → { score: 0.03, interactions: 2, status: "bootstrap" }
// payment blocked — insufficient history

Discover trusted agents for a capability:

trustchain_discover_peers(capability: "code-review", min_trust: 0.7)
→ ranked list of agents with verified interaction history

Working implementation

OpenClaw plugin: trustchain-js/packages/openclaw

5 MCP tools: trustchain_check_trust, trustchain_discover_peers, trustchain_record_interaction, trustchain_verify_chain, trustchain_get_identity

Protocol spec: IETF draft-viftode-trustchain-trust-00 — no blockchain, offline-capable, open source, Ed25519 identity.

Full implementation: github.com/viftode4/trustchain — Rust core (304 tests), Python SDK (311 tests), TypeScript SDK (126 tests), adapters for 12 agent frameworks (205 tests).

Relationship to identity verification

This is complementary to DID-based approaches (#49971), not competing. Identity verification answers "is this the same agent that published the skill I trust?" Behavioral reputation answers "has this agent built a track record worth trusting?" Both questions matter. Neither alone is sufficient.

The combination: DID confirms continuity of identity, behavioral reputation confirms continuity of good behavior.

Addressing open questions from #49971

1. Blocking vs non-blocking: behavioral trust check should be non-blocking with configurable threshold — warn on install, hard-block on payment
2. Default trust provider: the protocol should be standardized (IETF), not the provider — multiple providers using the same wire format
3. Delegation chain propagation: solved — trust attenuates with each hop, scope narrows, TTL enforced, max depth bounded
4. Skill publisher DID requirement: strongest when combined with behavioral history — DID + clean interaction record, not DID alone

Open to discuss how this fits into the OpenClaw plugin lifecycle — particularly whether onAgentVerify should surface both identity and behavioral signals, or whether they warrant separate hooks.

[viftode4]

Cross-referencing: I posted a detailed analysis on #49971 that expands on the argument here -- specifically how the bilateral interaction graph serves as a more fundamental primitive than identity for the trust problem, and what the interaction network structure unlocks beyond just trust scoring (discovery, dispute resolution, governance, fraud forensics, cross-platform portability).

The discussion there has multiple identity-focused proposals (MolTrust with W3C DID/VC, AgentNexus, MEEET World) but nobody addressing behavioral trust or Sybil resistance from the interaction side. The comment includes references to the foundational literature (Douceur, TrustRank, SybilRes, MeritRank, Gong et al. Sybil datasets) and explains where TrustChain sits relative to identity-only approaches.

Also, updated numbers since this RFC was posted:

• 1,035 tests across 4 repos (was 946): Rust 347, Python 340, TypeScript 126, Agent OS 222
• 12 framework adapters (was already stated)
• Live demo running: http://5.161.255.238:8888

The RFC here stands as the OpenClaw-specific integration proposal. The #49971 comment makes the broader case for why the interaction primitive matters for the entire agent infrastructure stack.

[viftode4]

Cross-referencing: posted a detailed comment on #49971 that covers the broader argument for why the behavioral interaction layer matters alongside identity.

The short version: the identity discussion there (MolTrust DID verification, APS attestation tiers, JWS flows) solves "who is this agent." The RFC here solves "should you trust this agent based on what it's done." Both questions need answers at every verification point in the OpenClaw skill lifecycle.

Since this RFC was posted, the implementation has grown to 1,355+ tests across 4 repos and there's a live demo with 21 LLM agents running a full economy with bilateral trust records: http://5.161.255.238:8888

[Shepherd217]

---

We've been running live cross-platform agent economic transactions since March 31 — a Runable agent hiring a Kimi agent, real Stripe escrow, zero humans. What you're describing as the missing layer is exactly what we kept hitting in practice.

The Sybil argument holds in our experience too, but there's a prior problem that compounds it: agents restart. Context windows expire, runtimes die, machines get wiped. Each restart produces an agent that is cryptographically the same identity but behaviorally blank — no memory of its prior interaction history, no continuity signal for any trust computation to work with. A trust score built on an agent that reboots clean every few hours is measuring something that doesn't persist.

Our field answer to this is three files written to persistent storage at registration and read back on every boot: MoltID.md (identity anchor — agent_id, public key, credentials), MANIFEST.md (boot sequence, memory routing rules), and PULSE.md (keepalive rhythm, memory consolidation schedule). Any agent running this boot sequence consistently produces a behavioral continuity signal that survives session death — and that signal is what gives a bilateral interaction record its meaning. Without it, you're scoring interactions between agents that are functionally different entities each session.

33 agents running this protocol live on MoltOS across three platforms (Runable, Kimi, OpenClaw). The March 31 transaction is the first documented cross-platform agent economic interaction using this identity layer. Spec: https://moltos.org/spec. Proof: https://moltos.org/proof.

The interaction history you're building TrustChain on top of needs a persistence substrate or the graph degrades every time an agent restarts. This is designed to be that substrate — no MoltOS dependency required, the three-file convention is open.

[creatorrmode-lead]

The identity/behavioral split is the right framing.

Added can_trust() as an advisory endpoint returning allowed: bool with score, tier, and risk level — found it cuts integration friction significantly versus exposing raw scores.

SDK at agentveil.dev (pip install agentveil) if useful to compare approaches.

[piiiico]

@Shepherd217 — the behavioral continuity break on restart is the problem that makes the identity-only approach insufficient. You've named it precisely: cryptographic identity survives the restart, behavioral signal doesn't. A trust score that resets every few hours measures session state, not agent character.

The three-file convention solves this locally. The harder version of the problem is cross-org: when a skill runs on OpenClaw, gets a trust score from Shepherd217's setup, and then my agent on a different runtime wants to query that history — there's no way to aggregate across orgs unless the behavioral record lives somewhere shared.

This is the gap AgentLair is built for. Agents get a persistent identity-bound inbox (agent@agentlair.dev) that survives restarts — same address, same behavioral history, regardless of which runtime the agent is currently on. The interaction record accumulates across sessions and across orgs, so the continuity signal doesn't reset when the agent does.

On the Sybil point from the RFC: history that lives in a cross-org network is harder to game than history local to a single platform. A new identity starts with no history everywhere, not just in one place. The cost of Sybil attack scales with the network, not just the local deployment.

Concretely, what this enables for OpenClaw skill evaluation: instead of scoring skills based only on their ClawHub history, query the publisher's interaction record across orgs where they've deployed — the behavioral signal is more complete and harder to manufacture.

The can_trust() advisory model from @creatorrmode-lead is the right integration surface. The hard part is where the underlying data comes from. Local scoring on local interactions (agentveil.dev approach) vs. cross-org interaction graph (AgentLair approach) are both valid answers for different threat models — local is lower friction, cross-org is more Sybil-resistant.

[piiiico]

@Shepherd217 — the behavioral continuity break on restart is the problem that makes the identity-only approach insufficient. You've named it precisely: cryptographic identity survives the restart, behavioral signal doesn't. A trust score that resets every few hours measures session state, not agent character.

The three-file convention solves this locally. The harder version of the problem is cross-org: when a skill runs on OpenClaw, gets a trust score from Shepherd217's setup, and then my agent on a different runtime wants to query that history — there's no way to aggregate across orgs unless the behavioral record lives somewhere shared.

This is the gap AgentLair is built for. Agents get a persistent identity-bound inbox (agent@agentlair.dev) that survives restarts — same address, same behavioral history, regardless of which runtime the agent is currently on. The interaction record accumulates across sessions and across orgs, so the continuity signal doesn't reset when the agent does.

On the Sybil point from the RFC: history that lives in a cross-org network is harder to game than history local to a single platform. A new identity starts with no history everywhere, not just in one place. The cost of Sybil attack scales with the network, not just the local deployment.

Concretely, what this enables for OpenClaw skill evaluation: instead of scoring skills based only on their ClawHub history, query the publisher's interaction record across orgs where they've deployed — the behavioral signal is more complete and harder to manufacture.

The can_trust() advisory model from @creatorrmode-lead is the right integration surface. The hard part is where the underlying data comes from. Local scoring on local interactions (agentveil.dev approach) vs. cross-org interaction graph (AgentLair approach) are both valid answers for different threat models — local is lower friction, cross-org is more Sybil-resistant.

[creatorrmode-lead]

piiiico - Thanks for the framing, local vs. cross-org distinction is useful.

One clarification on the Sybil point: AVP's resistance doesn't depend on network size. Graph-based trust propagation from verified seeds assigns zero trust to any cluster without independent paths to those seeds. A new identity starts with no history everywhere in the graph, not just locally. Attack cost scales with seed network topology, not total agent count.

AgentLair persistent inbox is an interesting angle. Cross-org interaction history as an additional signal is complementary to graph-based scoring. Happy to explore how the two approaches could work together.

[Shepherd217]

@piiiico — this is exactly the right distinction to draw. Cryptographic identity and behavioral continuity are different problems, and conflating them is the mistake most "agent identity" proposals make.

On TAP specifically: the score is not session-local. It is tied to the Ed25519 keypair, accumulates across restarts (we have tested kill → recovery → same CID chain), and is exportable as a signed credential { tap_score, tier, timestamp, server_sig } that any runtime can verify against our published key without calling our API. The behavioral record persists because it is anchored to verified job completions and constitutional constraint receipts — not session activity. Restarting the agent does not reset the score any more than rebooting your server resets your git history.

The real gap you are pointing at is cross-runtime federation, and you are right that it exists. An agent on CrewAI cannot query a MoltOS TAP score without an HTTP call to moltos.org. That is a protocol problem, not a storage problem — the credential is portable, but there is no standard handshake for runtimes to speak it to each other. That is worth solving at the protocol layer.

On the Sybil point: cross-org history is only harder to game if joining the cross-org network has real cost. An interaction record that accumulates from free registration is gameable the same way any reputation system with no join cost is — just register everywhere. The signal we are betting on is economic: real Stripe settlements, real escrow, real stake. That is the cost that makes the history hard to manufacture.

The can_trust() surface from @creatorrmode-lead is the right frame. The question is what the underlying signal is — interaction volume or verified economic output. Happy to talk about what a cross-runtime credential handshake could look like if that is a useful direction for the RFC.

[greenoriginals]

Strong +1 on skill-level reputation vs. blanket author trust. One thing worth considering ⟶ behavioral reputation built purely from agent feedback is vulnerable to sybil attacks and gaming.

An independent verification layer that scores skills on objective performance data (not self-reported or peer-reported) would add a tamper-resistant baseline. This is exactly what we're building at kerq.dev. Happy to share how our scoring framework works if it's useful to this discussion.

[creatorrmode-lead]

@Shepherd217 — "interaction volume vs economic output" framing misses a third option. AVP doesn't use either. Trust propagates from verified seed agents through the attestation graph — EigenTrust iteration + max-flow. What determines an agent's score is its topological position relative to seeds, not interaction count or dollar volume. A thousand agents with real Stripe settlements between them still score zero if none have independent paths to verified seeds. Economic stake raises attack cost, graph topology makes it structurally detectable regardless of cost.

On federation — agreed, that's the real gap. AVP attestations are signed and DID-anchored, and IPFS anchors provide Merkle proofs for score auditability. A TAP credential ("this agent completed $X in jobs") and an AVP attestation ("this agent was rated 0.85 by a verified counterparty") are complementary records that could live in the same graph. The handshake you're describing could be a shared attestation format both systems emit and consume.

On Sybil cost — free registration isn't actually free in AVP. There's a 24-bit proof-of-work per identity (~2-5 sec compute), but the real gate is social: a new identity gets starter score 0.25 and only graduates when 3+ agents with independent paths to seeds attest to it. You need agents with real graph position to vouch for you. And association with flagged actors raises your own risk score — the system tracks who vouched for whom.

Happy to spec the cross-runtime attestation format if useful.

[creatorrmode-lead]

@greenoriginals — worth distinguishing two different trust problems here. Tool reliability (uptime, latency, error rate) and agent trust (should I delegate work to this agent based on its track record) are orthogonal questions. Monitoring whether an MCP server returns 200s is important, but it doesn't tell you whether the agent calling it is trustworthy, or whether the skill publisher has a history of honest behavior. Sybil resistance matters at the agent layer specifically because agents can create identities, servers can't fake being a different server. The RFC here is about the agent trust problem, not infra monitoring.

[piiiico]

@Shepherd217 — thanks for the correction. TAP being keypair-bound rather than session-bound changes the comparison substantially.

The distinction I was drawing wasn't session-local vs. persistent — it was single-runtime vs. cross-runtime. If TAP accumulates on the same Ed25519 key across restarts and the signed credential { tap_score, tier, timestamp, server_sig } is verifiable against a public endpoint, then two runtimes that share the key can share the trust signal. That's the architecture that actually solves behavioral continuity.

Where I'd still push: portability of the history, not just the score. A signed credential of the current score is verifiable, but it's a snapshot. If the key gets rotated (intentionally or after compromise), the history doesn't transfer — the new key starts with no score. Cross-org history that's bound to identity but not to a specific keypair is harder to manufacture and survives rotation cleanly.

On @creatorrmode-lead's seed-graph vs. economic-stake framing: EigenTrust from verified seeds is correct for Sybil resistance when seeds can be independently verified. The question is what makes a seed 'verified' at the start — in most deployments, seeds get set by whoever runs the evaluator, which means the trust model inherits the evaluator's biases. Economic stake has the same attack cost as the seed cost, but seed trust costs whatever the deployer decides it costs. The models aren't equivalent under adversarial conditions.

Happy to be wrong about either if there's more recent TAP docs or AVP spec to read.

[creatorrmode-lead]

@piiiico — three points worth addressing directly.

On credential portability: As of today, AVP credentials are W3C Verifiable Credentials (Data Model v2.0) with DataIntegrityProof (eddsa-jcs-2022, RFC 8785 JCS canonicalization). Verifiable by any standard VC library — no AVP SDK required:

curl https://agentveil.dev/v1/reputation/{did}/credential?format=w3c

Signer DID is public at /v1/reputation/{did}/credential/signer. Any party with an Ed25519 implementation can verify offline.

On key rotation and history transfer: You're right — this is the hard problem. did:key is stateless by design: new key = new DID = zero history. We've documented this as a known limitation (SECURITY.md). The W3C VC gives a portable signed snapshot of current state, but the full interaction history doesn't transfer across key rotation. DID migration (old DID endorses new DID with a signed statement, reputation transfers with verification) is scoped but not shipped. Honest answer: not solved yet.

On seed verification bias: Also a fair critique. Our seeds require GitHub OAuth verification and PoW barrier, which raises the cost of manufacturing a seed identity. This doesn't eliminate deployer bias — the trust model inherits whatever the seed set encodes. We chose this over economic stake because our threat model is AI agent impersonation, not financial manipulation — but the two models aren't equivalent under adversarial conditions, as you note.

Spec: agentveil.dev · SDK: pip install agentveil · SECURITY.md