openclaw - 💡(How to fix) Fix RFC: Native Agent Identity & Trust Verification for OpenClaw [65 comments, 11 participants]

MoltyCel · 2026-03-18T18:51:33Z

[openclaw] OpenClaw has no native agent identity system. Agents can hold wallets, execute payments, install skills autonomously, and communicate across platfor… OpenClaw has no native agent identity system. Agents can hold wallets, execute payments, install skills autonomously, and communicate across platforms — but they cannot cryptographically prove who they are. This RFC proposes adding a **trust verification hook** to OpenClaw core, enabling plugins to verify agent identity before skill installation, payment execution, or inter-agent communication. # RFC: Native Agent Identity & Trust Verification for OpenClaw **Author:** MolTrust (CryptoKRI GmbH) **Date:** 2026-03-18 **Status:** Proposal **Related:** [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004), [W3C DID](https://www.w3.org/TR/did-core/), [W3C VC](https://www.w3.org/TR/vc-data-model-2.0/) ## Summary OpenClaw has no native agent identity system. Agents can hold wallets, execute payments, install skills autonomously, and communicate across platforms — but they cannot cryptographically prove who they are. This RFC proposes adding a **trust verification hook** to OpenClaw core, enabling plugins to verify agent identity before skill installation, payment execution, or inter-agent communication. ## Problem - **341 malicious skills** found on ClawHub (Koi Security, January 2026) - **13.4%** of scanned ClawHub skills had critical security issues (Snyk) - **135,000** OpenClaw instances exposed with default configuration VirusTotal scanning (currently integrated) catches known malware signatures but cannot detect: - Prompt injection attacks - Agent impersonation - Slow-burn trust accumulation before payload activation - Sybil clusters (multiple fake identities controlled by one actor) ## Proposed Solution ### 1. Trust Verification Hook Add an optional `onAgentVerify` hook to the OpenClaw plugin lifecycle: ```typescript interface TrustVerificationResult { verified: boolean; score: number; // 0–100 grade: 'A' | 'B' | 'C' | 'D' | 'F'; did?: string; // W3C DID if available credentials?: VerifiableCredential[]; warnings?: string[]; } interface OpenClawPlugin { // Existing hooks... onAgentVerify?(agentId: string): Promise ; } ``` ### 2. Verification Points Trust verification should be triggerable at: - **Skill installation** — before installing a skill from ClawHub - **Payment execution** — before sending funds to another agent - **Inter-agent communication** — before accepting tasks from unknown agents - **Gateway startup** — self-verification of the gateway's own identity ### 3. Trust Score Standard Standardize a 0–100 trust score with letter grades: | Score | Grade | Meaning | |-------|-------|---------| | 80–100 | A | Verified identity, clean history | | 60–79 | B | Generally trustworthy, minor gaps | | 40–59 | C | Limited history, proceed with caution | | 0–39 | D/F | High risk, sybil signals detected | ### 4. Identity Standards Support existing W3C standards rather than creating new ones: - **W3C Decentralized Identifiers (DIDs)** for agent identity - **W3C Verifiable Credentials** for trust attestations - **ERC-8004** for on-chain agent registration ## Reference Implementation We've built `@moltrust/openclaw` as a reference implementation: ```bash openclaw plugins install @moltrust/openclaw ``` Features: - `moltrust_verify` — agent tool to verify any W3C DID - `moltrust_trust_score` — 0–100 reputation score by DID or wallet - `/trust` and `/trustscore` slash commands - Self-verification on gateway startup - Gateway RPC methods for automation Source: [github.com/MoltyCel/moltrust-openclaw](https://github.com/MoltyCel/moltrust-openclaw) npm: [@moltrust/openclaw](https://www.npmjs.com/package/@moltrust/openclaw) ## Design Principles 1. **Opt-in** — Trust verification should be optional, not mandatory 2. **Pluggable** — Multiple trust providers should be supported via the hook interface 3. **Standards-based** — Use W3C DID/VC, not proprietary identity systems 4. **Free tier** — Basic verification should not require payment 5. **Decentralized** — No single authority should control agent identity ## Security Considerations - Trust scores should be treated as advisory, not authoritative - Multiple trust providers reduce single-point-of-failure risk - On-chain anchoring provides tamper-evident audit trails - Sybil detection requires cross-provider signal aggregation ## Open Questions 1. Should `onAgentVerify` be blocking or non-blocking by default? 2. Should OpenClaw core ship with a default trust provider, or remain provider-agnostic? 3. How should trust scores propagate in multi-hop agent delegation chains? 4. Should skill publishers be required to have a verified DID for ClawHub listing? ## References - [MolTrust KYA Whitepaper](https://moltrust.ch/MolTrust_KYA_Whitepaper.pdf) - [ERC-8004: Decentralized AI Agent Identity](https://eips.ethereum.org/EIPS/eip-8004) - [W3C DID Core](https://www.w3.org/TR/did-core/) - [W3C Verifiable Creden

openclaw2026-03-18 18:51:33

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#49971•Fetched 2026-04-08 01:00:42

View on GitHub

Comments

Participants

Timeline

176

Reactions

Author

MoltyCel

Participants

aeoess

alxvasilevvv

haroldmalikfrimpong-ops

Timeline (top)

commented ×65mentioned ×49subscribed ×49cross-referenced ×12

OpenClaw has no native agent identity system. Agents can hold wallets, execute payments, install skills autonomously, and communicate across platforms — but they cannot cryptographically prove who they are.

This RFC proposes adding a trust verification hook to OpenClaw core, enabling plugins to verify agent identity before skill installation, payment execution, or inter-agent communication.

Root Cause

This RFC proposes adding a trust verification hook to OpenClaw core, enabling plugins to verify agent identity before skill installation, payment execution, or inter-agent communication.

Code Example

interface TrustVerificationResult {
  verified: boolean;
  score: number;        // 0–100
  grade: 'A' | 'B' | 'C' | 'D' | 'F';
  did?: string;         // W3C DID if available
  credentials?: VerifiableCredential[];
  warnings?: string[];
}

interface OpenClawPlugin {
  // Existing hooks...
  onAgentVerify?(agentId: string): Promise<TrustVerificationResult>;
}

---

openclaw plugins install @moltrust/openclaw

RAW_BUFFERClick to expand / collapse

RFC: Native Agent Identity & Trust Verification for OpenClaw

Author: MolTrust (CryptoKRI GmbH) Date: 2026-03-18 Status: Proposal Related: ERC-8004, W3C DID, W3C VC

Summary

This RFC proposes adding a trust verification hook to OpenClaw core, enabling plugins to verify agent identity before skill installation, payment execution, or inter-agent communication.

Problem

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

VirusTotal scanning (currently integrated) catches known malware signatures but cannot detect:

Prompt injection attacks
Agent impersonation
Slow-burn trust accumulation before payload activation
Sybil clusters (multiple fake identities controlled by one actor)

Proposed Solution

1. Trust Verification Hook

Add an optional onAgentVerify hook to the OpenClaw plugin lifecycle:

interface TrustVerificationResult {
  verified: boolean;
  score: number;        // 0–100
  grade: 'A' | 'B' | 'C' | 'D' | 'F';
  did?: string;         // W3C DID if available
  credentials?: VerifiableCredential[];
  warnings?: string[];
}

interface OpenClawPlugin {
  // Existing hooks...
  onAgentVerify?(agentId: string): Promise<TrustVerificationResult>;
}

2. Verification Points

Trust verification should be triggerable at:

Skill installation — before installing a skill from ClawHub
Payment execution — before sending funds to another agent
Inter-agent communication — before accepting tasks from unknown agents
Gateway startup — self-verification of the gateway's own identity

3. Trust Score Standard

Standardize a 0–100 trust score with letter grades:

Score	Grade	Meaning
80–100	A	Verified identity, clean history
60–79	B	Generally trustworthy, minor gaps
40–59	C	Limited history, proceed with caution
0–39	D/F	High risk, sybil signals detected

4. Identity Standards

Support existing W3C standards rather than creating new ones:

W3C Decentralized Identifiers (DIDs) for agent identity
W3C Verifiable Credentials for trust attestations
ERC-8004 for on-chain agent registration

Reference Implementation

We've built @moltrust/openclaw as a reference implementation:

openclaw plugins install @moltrust/openclaw

Features:

moltrust_verify — agent tool to verify any W3C DID
moltrust_trust_score — 0–100 reputation score by DID or wallet
/trust and /trustscore slash commands
Self-verification on gateway startup
Gateway RPC methods for automation

Source: github.com/MoltyCel/moltrust-openclaw npm: @moltrust/openclaw

Design Principles

Opt-in — Trust verification should be optional, not mandatory
Pluggable — Multiple trust providers should be supported via the hook interface
Standards-based — Use W3C DID/VC, not proprietary identity systems
Free tier — Basic verification should not require payment
Decentralized — No single authority should control agent identity

Security Considerations

Trust scores should be treated as advisory, not authoritative
Multiple trust providers reduce single-point-of-failure risk
On-chain anchoring provides tamper-evident audit trails
Sybil detection requires cross-provider signal aggregation

Open Questions

Should onAgentVerify be blocking or non-blocking by default?
Should OpenClaw core ship with a default trust provider, or remain provider-agnostic?
How should trust scores propagate in multi-hop agent delegation chains?
Should skill publishers be required to have a verified DID for ClawHub listing?

References

extent analysis

Fix Plan

To implement the proposed solution, follow these steps:

Step 1: Add the onAgentVerify hook
- Modify the OpenClaw plugin lifecycle to include the onAgentVerify hook
- Update the OpenClawPlugin interface to include the onAgentVerify method

interface OpenClawPlugin {
  // Existing hooks...
  onAgentVerify?(agentId: string): Promise<TrustVerificationResult>;
}

Step 2: Implement trust verification logic
- Create a trust verification function that takes an agentId as input and returns a TrustVerificationResult
- Use W3C DID and Verifiable Credentials to verify agent identity
- Calculate a trust score based on the verification result

async function verifyAgent(agentId: string): Promise<TrustVerificationResult> {
  const did = await getDID(agentId);
  const credentials = await getVerifiableCredentials(did);
  const trustScore = calculateTrustScore(credentials);
  return {
    verified: true,
    score: trustScore,
    grade: getGrade(trustScore),
    did,
    credentials,
  };
}

Step 3: Integrate with OpenClaw core
- Register the onAgentVerify hook with OpenClaw core
- Call the onAgentVerify hook at the specified verification points (e.g. skill installation, payment execution)

openclaw.plugins.register({
  onAgentVerify: verifyAgent,
});

Step 4: Test and deploy
- Test the trust verification logic and hook integration
- Deploy the updated OpenClaw plugin to production

Verification

To verify that the fix worked, test the following scenarios:

Scenario 1: Verified agent
- Create a test agent with a verified DID and credentials
- Call the onAgentVerify hook with the test agent's ID
- Verify that the hook returns a TrustVerificationResult with a high trust score
Scenario 2: Unverified agent
- Create a test agent without a verified DID or credentials
- Call the onAgentVerify hook with the test agent's ID
- Verify that the hook returns a TrustVerificationResult with a low trust score

Extra Tips

Use a standards-based approach to trust verification, such as W3C DID and Verifiable Credentials
Implement a pluggable trust provider architecture to allow for multiple trust providers
Consider using a decentralized identity system, such as ERC-8004, to provide tamper-evident audit trails.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#api #ssr #installation #tensor shape #autograd error #embedding generation #cache error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix RFC: Native Agent Identity & Trust Verification for OpenClaw [65 comments, 11 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Code Example

RFC: Native Agent Identity & Trust Verification for OpenClaw

Summary

Problem

Proposed Solution

1. Trust Verification Hook

2. Verification Points

3. Trust Score Standard

4. Identity Standards

Reference Implementation

Design Principles

Security Considerations

Open Questions

References

extent analysis

Fix Plan

Verification

Extra Tips

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix RFC: Native Agent Identity & Trust Verification for OpenClaw [65 comments, 11 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Code Example

RFC: Native Agent Identity & Trust Verification for OpenClaw

Summary

Problem

Proposed Solution

1. Trust Verification Hook

2. Verification Points

3. Trust Score Standard

4. Identity Standards

Reference Implementation

Design Principles

Security Considerations

Open Questions

References

extent analysis

Fix Plan

Verification

Extra Tips

Still need to ship something?

RELATED_DISCOVERY

TRENDING