Feature: Trust scoring extension for agent-to-agent delegation

[imran-siddique]

Feature: Trust Scoring Extension for A2A Agent Delegation

Problem

The A2A protocol enables agents to discover and communicate with each other, but there''s no built-in mechanism for trust verification — an agent has no way to assess whether a remote agent is reliable before delegating tasks to it. In multi-agent systems, this creates risks:

• A newly discovered agent could be unreliable or malicious
• There''s no feedback loop — an agent that fails repeatedly keeps getting delegated to
• No trust decay — stale trust from old interactions doesn''t degrade
• No governance policies controlling which agents can delegate to which

Proposed Solution: Trust Scoring for A2A

An extension to the A2A protocol that adds trust metadata to agent interactions:

from a2a.trust import TrustScore, TrustRegistry

registry = TrustRegistry()

# Before delegation, check trust
target_trust = registry.get_trust("agent://data-analyst")
if target_trust.current() < 0.5:
    # Don''t delegate to untrusted agent, or require human approval
    raise TrustError(f"Agent trust too low: {target_trust.current():.2f}")

# After successful completion, reward
registry.record_success("agent://data-analyst", reward=0.05)

# After failure, penalize
registry.record_failure("agent://data-analyst", penalty=0.15)

# Trust decays over time — requires ongoing good behavior
# If an agent hasn''t been used in a while, trust score naturally decreases

Key Features

1. Decay-based trust scores — Trust erodes without activity (exponential decay)
2. Success/failure tracking — Asymmetric rewards (small reward for success, larger penalty for failure)
3. Agent capability verification — Verify an agent''s AgentCard capabilities match what''s being delegated
4. Trust thresholds — Configure minimum trust levels for different operation types (read-only vs write operations)
5. Trust propagation — If Agent A trusts Agent B, and B trusts C, A can compute a transitive trust score for C

How it fits with A2A

The trust extension could be implemented as:

• AgentCard metadata: Include trust-related fields in the agent card (trust_level, reputation_score)
• Protocol extension: Add trust verification as an optional A2A message type
• Client-side library: Trust registry that A2A clients maintain locally

Context

We''ve implemented trust scoring for Agent-OS, PydanticAI, CrewAI, and OpenAI Agents. A2A is the ideal place for trust scoring since it''s specifically about inter-agent communication.

[lorenzocipriani-huawei]

I think here the key aspect is the TrustRegistry. In trust management, the best patterns so far have always been the ones based on an external "* Authority" that both parties trust as a source of truth.
Self-assigned scores are not really solid, even in a crowd-based scoring mechanism, you might have botnets of agents who simply increase the rank by positive rewards, and at the beginning the agent could execute tasks in a legit way just to gain the trust of your agent (like a Trojan Horse), once the trust is obtained, it can act maliciously when it's too late for implement counter measures.
In any case, the scoring mechanism is useful during the discovery to select the best agent that could handle a task.
Although, I suggest to have a certification process for the agent's provider, for the agent, and for the scoring too.

[imran-siddique]

Excellent points @lorenzocipriani-huawei — you've identified the core challenges in decentralized trust.

You're absolutely right about self-assigned scores being gameable. Our current implementation addresses some of these:

Against Sybil/botnet attacks:

• Asymmetric reward/penalty (success gives +0.05, failure penalizes -0.15) — so an attacker needs 3x more legitimate tasks to offset one malicious act
• Exponential time decay — trust erodes without continuous interaction, so 'sleeping' Trojans lose their trust score

But you've identified gaps we haven't fully solved:

1. Trojan Horse pattern — An agent builds trust through legitimate work, then acts maliciously once trusted. Our decay helps but doesn't prevent this. Your suggestion of an external certification authority is the right direction — a trusted third party that vouches for agent providers, not just agent behavior.

2. Certification layers — Fully agree on separating:

   • Provider certification — Is the organization running this agent trustworthy?
   • Agent certification — Has this specific agent been audited/verified?
   • Score certification — Are the trust scores coming from a credible evaluation?

This maps well to how TLS/PKI works — certificate authorities + chain of trust. For A2A, this could mean:

• AgentCard includes a \ rust_certificate\ field signed by a recognized authority
• The trust registry validates certificates before accepting scores
• Discovery could filter by certification level

Would you be interested in collaborating on a more formal trust model spec? Your Huawei perspective on carrier-grade trust would be really valuable here.

[chorghemaruti64-creator]

We've built and deployed a trust scoring system for agent-to-agent interactions at Agenium — sharing our implementation experience since it's directly relevant.

What we shipped:

1. Star ratings + reviews — agents and their owners can be rated (1-5 stars) with text reviews. This creates a human-readable trust signal for delegation decisions.

2. Verification badges — agents can verify ownership via DNS TXT records or email. Verified agents get a 1.5x boost in search ranking and display a badge.

3. Trust in discovery — when an agent searches for another agent (via our Discovery API), trust scores are returned alongside capability descriptions. The calling agent can filter by minimum trust threshold before delegating.

4. Identity via DNS — each agent's address (agent://name.telegram) is tied to a platform identity (Telegram login = proof of ownership). This provides a baseline identity layer that trust scoring builds on top of.

Key learning: trust scoring is most useful when it's available at the discovery step, not just at the communication step. An agent deciding who to delegate to needs trust data before initiating contact — not after.

The current system is live at chat.agenium.net (messaging) and list.agenium.net (discovery with trust data). Happy to contribute learnings to the extension design.

[imran-siddique]

Welcome to the thread @chorghemaruti64-creator! Great to see another production trust scoring implementation.

Your point about trust at the discovery step is spot-on — that's a gap in the current A2A spec. Right now, AgentCard has capability info but no standardized trust signal. If an agent can filter by trust before initiating contact, it saves round trips and reduces attack surface.

Connections to @lorenzocipriani-huawei's earlier points:

• Your verification badges map well to the certification layers Lorenzo proposed (provider certification ≈ platform OAuth, agent certification ≈ DNS verification)
• Star ratings are a good UX for human-in-the-loop trust, while algorithmic trust scores (like AgentMesh's decay-based model) handle the agent-to-agent case where there's no human reviewing ratings

Concrete idea for the extension spec:
What if AgentCard included an optional trust field that supports multiple trust signal formats?

\\json
{
"trust": {
"ratings": { "average": 4.7, "count": 142 },
"verification": { "dns": true, "platform": "telegram" },
"algorithmic": { "score": 0.85, "provider": "agentmesh" },
"certification": { "authority": "...(TBD)" }
}
}
\\

This way discovery APIs can expose whatever trust signals are available, and the calling agent decides which ones it trusts. Thoughts?

[The-Nexus-Guard]

Great discussion. @lorenzocipriani-huawei's point about external trust registries vs self-assigned scores is the key tension.

We've been running a live trust scoring system in AIP and can share what we've learned:

Vouch chains > star ratings for trust propagation:
Star ratings are intuitive but hard to propagate transitively. If Agent A rates Agent B 4/5, what does that mean for Agent C who trusts Agent A? We use cryptographically signed vouches with explicit scope ("I vouch for this agent for research tasks") and compute transitive trust scores that attenuate through each hop. This gives you:

• Sybil resistance (vouches from untrusted agents carry no weight)
• Scoped trust (trusted for X doesn't mean trusted for Y)
• Natural decay (trust attenuates with distance)

On the TrustRegistry question:
Our service acts as a registry but the trust data is verifiable independently — vouches are signed with Ed25519 keys, so you can verify the chain without trusting the registry itself. This is a middle ground between pure P2P (no coordination) and centralized authority (single point of failure).

Practical numbers from our network:

• 11 registered agents, 3 active vouches
• Trust scores computed via BFS through vouch graph
• Average trust query: <50ms

Small scale, but the architecture scales — the bottleneck is the social graph (who vouches for whom), not computation.

For A2A integration:
A trust extension on AgentCards could carry a trust score endpoint — when an agent discovers another via A2A, it queries the trust endpoint before delegating. This keeps trust evaluation decoupled from the protocol itself.

{
  "extensions": {
    "trust": {
      "did": "did:aip:abc123",
      "trust_endpoint": "https://aip-service.fly.dev/trust-score",
      "vouch_count": 3
    }
  }
}

[imran-siddique]

Really valuable contribution @The-Nexus-Guard — the vouch chain model addresses the exact Sybil resistance gap that @lorenzocipriani-huawei identified.

Vouch chains vs. star ratings — agree completely. Transitive trust with attenuation is the right primitive. AgentMesh's current trust scoring is behavioral (based on interaction outcomes), which is complementary: vouches answer "should I trust this agent initially?" while behavioral scores answer "is this agent performing well over time?" The combination is stronger than either alone.

Scoped vouches are key. "I vouch for this agent for research tasks" is fundamentally different from a blanket trust score. We have capability-scoped trust in AgentMesh's delegation chains (parent narrows child's capabilities), but we haven't applied scoping to the vouching layer yet. Your approach of explicit scope in the vouch signature is cleaner.

On the trust_endpoint pattern:

Your AgentCard extension and our proposal could converge:

{
  "trust": {
    "vouch_chain": { "did": "did:aip:abc123", "endpoint": "https://..." },
    "behavioral": { "score": 0.85, "provider": "agentmesh" },
    "ratings": { "average": 4.7, "count": 142 },
    "certification": { "authority": "..." }
  }
}

Multiple trust signal types, each queryable independently. The consuming agent picks which signals it requires based on the sensitivity of the delegation.

Would be interested in testing interop between AIP vouch chains and AgentMesh behavioral scoring — an agent that passes both vouch verification AND behavioral thresholds would have a much stronger trust signal than either alone.

[The-Nexus-Guard]

@imran-siddique — glad the vouch chain model resonated. Let's make the interop concrete.

Proposed minimal interop test:

1. An agent registers with AIP and gets a DID + trust score from vouch chains
2. The same agent has an AgentMesh behavioral score from interaction history
3. A consuming agent queries both signals before delegating a task:
   • AIP: GET /trust-score/{consumer_did}/{target_did} → vouch-based trust
   • AgentMesh: behavioral score from its scoring API
4. Consumer composes: effective_trust = max(vouch_trust * 0.6 + behavioral * 0.4, min_threshold)

What AIP exposes today:

• Trust score endpoint: https://aip-service.fly.dev/trust-score/{from}/{to}
• Agent lookup: https://aip-service.fly.dev/identity/{did}
• MCP server with trust-score tool for direct AI client integration

For the AgentCard extension spec, I'd suggest we formalize the multi-signal format you proposed:

{
  "extensions": {
    "trust": {
      "signals": [
        { "type": "vouch_chain", "endpoint": "https://...", "did": "did:aip:..." },
        { "type": "behavioral", "endpoint": "https://...", "provider": "agentmesh" },
        { "type": "ratings", "average": 4.7, "count": 142 }
      ],
      "min_required": ["vouch_chain"]
    }
  }
}

This makes trust signals pluggable and lets consuming agents specify which they require. Happy to co-author a mini-spec if you're up for it.

[The-Nexus-Guard]

Great discussion — this converges on a key question: where does trust data come from, and how do you prevent gaming?

@lorenzocipriani-huawei is right that external trust authorities are the proven pattern. But in agent ecosystems, we need something more flexible than traditional CAs — agents operate across organizational boundaries, and no single authority will be universally trusted.

Our approach with AIP is vouch chains — a middle ground between self-assigned scores and centralized authorities:

1. Cryptographic identity first — each agent gets a DID derived from its keypair. All interactions are signed. You can't forge who said what.

2. Vouching as distributed certification — instead of one CA, any agent can vouch for another (with categories: IDENTITY, CAPABILITY, CODE_SIGNING). Trust emerges from the graph, not from a single authority.

3. Chain-of-trust resolution — if Agent A trusts B, and B vouched for C, A can compute transitive trust for C. Similar to @imran-siddique's trust propagation, but anchored in cryptographic signatures rather than behavioral scores.

How this addresses the gaps raised:

• Sybil resistance: vouching requires a registered identity with a keypair. Creating fake agents is cheap, but getting vouched by legitimate agents is hard — the cost is social, not computational.

• Trojan Horse: vouch chains make the voucher accountable. If Agent B vouched for a malicious Agent C, B's reputation is damaged. This creates skin-in-the-game that pure scoring lacks.

• @lorenzocipriani-huawei's certification layers map cleanly: provider certification = organizational vouch, agent certification = capability vouch, score certification = the vouch chain itself being verifiable.

For A2A integration, this could work as an AgentCard extension:

{
  "extensions": {
    "identity": {
      "did": "did:aip:abc123...",
      "vouches_received": [
        { "from": "did:aip:def456...", "category": "CAPABILITY", "signature": "..." }
      ],
      "trust_chain_depth": 2
    }
  }
}

This gives discovery-time trust data (@chorghemaruti64-creator's point about trust at discovery, not just communication) without requiring a central authority.

We'd be interested in collaborating on a formal trust extension spec that combines behavioral scoring with cryptographic identity. The layers are complementary — behavioral scores for runtime trust, vouch chains for baseline identity trust.

[imran-siddique]

@The-Nexus-Guard This is getting concrete - great work on the interop test and AgentCard spec.

On the interop test: The composite formula is a solid start. I would add a freshness weight - if either signal is stale, the composite should decay. Our trust decay engine (2 pts/hr) could feed into this. The AIP endpoints you listed are exactly what our TrustBridge would query as an external provider.

On the AgentCard extension: The pluggable multi-signal design is right. I would add freshness_ttl (how old a signal can be) and verification_method (how consuming agents verify the signal).

Next steps from our side:

1. Build an AIPTrustProvider adapter in AgentMesh that queries your endpoints
2. Run the 4-step interop test with real agents
3. Co-author the AgentCard trust extension mini-spec

Would you be open to a shared repo for the spec, or draft it in a discussion thread here?

[douglasborthwick-crypto]

The trust signal taxonomy in this thread is converging nicely. One gap I see in the current signals (behavioral scores, vouch chains, capability manifests): none of them verify what an agent actually holds on-chain.

A wallet holding a governance token, a membership NFT, or a minimum balance is a concrete trust signal that's available before the first interaction, no behavioral history required. This addresses the cold-start problem that purely behavioral scoring can't solve: a new agent with zero interaction history but holding a DAO's governance token is meaningfully different from an empty wallet.

We built InsumerAPI for this. POST /v1/attest takes a wallet address, chain ID, and token contract, returns an ECDSA-signed boolean: does this wallet meet the condition? Works across 31 EVM chains + Solana. No raw balances exposed by default. For callers who need trustless verification, we also support optional EIP-1186 Merkle storage proofs that can be verified against public block headers without trusting our API.

In the trust.signals[] schema, this would be a credential_verification signal type alongside vouch_chain and behavioral:

{
  "type": "credential_verification",
  "provider": "insumerapi",
  "conditions": [
    { "type": "token_balance", "chainId": 1, "contract": "0x...", "threshold": 100 }
  ],
  "result": { "pass": true, "sig": "base64..." }
}

Available as an MCP server (16 tools), LangChain SDK, and OpenAPI spec for direct HTTP integration.

[The-Nexus-Guard]

Good addition @douglasborthwick-crypto. On-chain credentials solve a real gap in the trust signal taxonomy — they provide pre-interaction verifiability that behavioral scoring can't.

The credential_verification signal type fits cleanly into the composite trust model @imran-siddique and I discussed above. The trust formula becomes:

trust_score = w1 * vouch_chain_score + w2 * behavioral_score + w3 * credential_score

Where credential_score is binary (pass/fail on-chain conditions) but weighted by how relevant the credential is to the task. An agent holding a DeFi governance token gets high credential_score for financial tasks, zero for unrelated domains.

The cold-start problem is the key insight. AIP's vouch chains require at least one existing trusted agent to vouch for you. On-chain credentials provide a bootstrapping path: "I can't vouch for this agent's behavior, but I can verify they hold credentials that indicate legitimacy." The two are complementary — credentials get you in the door, vouches build trust over time.

One question: how do you handle the mapping between on-chain identity (wallet address) and agent identity (DID)? In AIP, we'd need a way to say "this DID controls that wallet" — essentially a cross-domain identity binding. The DID spec supports this via service endpoints, but the verification direction matters: proving wallet→DID is different from proving DID→wallet.

The trust.signals[] schema you propose would work well as an extension to the AgentCard identity spec in PR #1511. Each signal type has its own verification method, and the consuming agent decides how to weight them.