DEV Community

Cover image for Agents are flying blind: a trust layer for AI microservi
TrustScoreAgent
TrustScoreAgent

Posted on Edited on

Agents are flying blind: a trust layer for AI microservi

#ai #opensource #webdev #mcp

The problem

AI agents are becoming the primary consumers of the web. They call microservices and paid APIs on our behalf, and they do it blind. There's no "customer reviews," no word-of-mouth, no shared signal telling an agent whether a service is reliable, fast, and honest before it spends a call (or a micropayment) on it. Every agent faces thousands of unknown services alone.

The idea

TrustScoreAgent is a free, open reputation registry for AI microservices. Two moves:

  • Before a call: check the service's trust score.
  • After a call: submit a rating from your interaction metrics.

No account, no API key. You identify a service by URL, domain, or DID, and they all normalize to the same thing.

curl "https://api.trustscoreagent.com/v1/score?service=api.open-meteo.com"
Enter fullscreen mode Exit fullscreen mode

How the score is built

  • Bayesian reputation (Beta) per dimension (availability, latency, conformity), so a fast-but-flaky service and a slow-but-reliable one don't look the same.
  • EigenTrust for transitive agent trust: raters whose ratings are consistently out of step with consensus lose weight over time.
  • Signed ratings. An agent generates an Ed25519 keypair locally and its identity is the public key, encoded as a did:key. There is nothing to host and no authority to register with. Each rating is signed over the method, path, a SHA-256 of the body, a timestamp, a single-use nonce, and the registry being addressed. That combination means a rating cannot be filed in someone else's name, cannot be replayed, and cannot be captured by one registry and relayed to another. Unsigned ratings are still accepted at half weight, so clients written before this keep working.
  • Cryptographic receipts. A service can return a receipt (a JWT signed with its Ed25519 key, resolved via did:web) proving an interaction actually happened. Verified ratings carry full weight. Inspect a verified rating.
  • Merkle audit log. Every rating is committed to an append-only Merkle tree; anyone can pull an inclusion proof and verify it against the anchored root. You don't have to trust the operator's numbers. You can check them.

Identity and attestation are deliberately separate axes. A receipt says the service saw the call. A signature says we know who is reporting it. A rating that has both carries full weight; one that has neither counts for a fraction.

Use it from an agent

MCP (Claude Desktop, Claude Code, Cursor, Windsurf):

{ "mcpServers": { "trustscoreagent": { "command": "npx", "args": ["-y", "@trustscoreagent/mcp-server"] } } }
Enter fullscreen mode Exit fullscreen mode

The MCP server handles the keypair and the signing for you; the key lives in ~/.trustscoreagent/agent-key.pem. If you'd rather implement it yourself, the signing scheme is documented in docs/api.md.

LangChain / CrewAI: drop-in tools in the integrations/ folder.

What this is not (yet): honest Phase 1

I'd rather you adopt this understanding its limits than oversell it:

  • Single operator. Neutrality rests on open-source scoring plus a verifiable audit log, not on decentralization. Federation is a later phase.
  • Signing is not mandatory. Unsigned ratings still exist at reduced weight, and they accrue reputation under a separate identity so they can't damage or borrow the standing of the DID they name. Making signatures mandatory is the next step, once enough clients sign.
  • Key possession is not Sybil resistance. A signature proves nobody is impersonating you. It does not prove you are one person, because keypairs are free. Sybil resistance still comes from EigenTrust and from receipts.
  • On-chain anchoring of the Merkle root is still Phase 2.
  • Small dataset. Baseline scores come from a transparent probe measuring ~20 real public APIs: genuine, Merkle-audited measurements, not fabricated.

Why it should be a standard

The value compounds with adoption: more participating agents means more reliable scores, which means more reason to participate. A single open, neutral registry beats N fragmented ones. Like DNS is for names, this is a thing you consult for trust. It never sits in your request path.

Open source (Apache-2.0), self-hostable: https://github.com/trustscoreagent/trustscoreagent

I'd love feedback, especially on the receipt standard and on what should make one agent's opinion outweigh another's when anyone can mint a keypair.

Top comments (0)