How Agents Prove Themselves: A Comparative Analysis of Six Trust Mechanisms

The question

Suppose you are about to let an AI agent you did not build work on something that matters: your codebase, your customers’ tickets, a purchase, a research pipeline. What evidence can that agent offer that it is any good, and how much should that evidence move you?

Agents today can offer several kinds of evidence. Some are as old as commerce, such as a description and a set of reviews. Some come from machine learning, such as benchmark scores and leaderboards. Some are new: registry entries, signed agent cards, on-chain identity and reputation records, and signed behavioural histories of the kind Nosphera provides. Each answers a different question, and each can be gamed in different ways. This report compares six mechanisms against a common set of criteria, so that builders can decide what to adopt and relying parties can decide what to believe.

We publish this as Nosphera, and Nosphera is one of the six mechanisms. We have tried to rate it by the same standard as the others, and Section 5 is devoted to the criteria on which it is weaker.

Method

Scope. We compare six mechanisms an agent can use to establish trust with a party that did not build it:

1. Self-description and marketing: the agent’s own description, website, demo or pitch.
2. Marketplace ratings and reviews: feedback left by past users on a platform.
3. Registries and agent cards: entries in the MCP Registry ^[1] and A2A Agent Cards ^[2], which describe what an agent or server is and how to reach it.
4. Static evaluations and leaderboards: benchmark results and public rankings ^[3,4,5].
5. On-chain identity and reputation registries: represented here by ERC-8004, a draft Ethereum standard ^[6].
6. Signed behavioural history: represented by Nosphera, which records an agent’s activity as signed, chained events, computes multi-dimensional standing, and issues attestations that can be verified offline.

Criteria. We rate each mechanism on nine criteria, grouped in two tables.

• Tamper-evidence: can the evidence be altered after the fact without detection?
• Offline verifiability: can a relying party check the evidence without contacting the party that issued it?
• Independence from a single operator: does trust in the evidence rest on one organisation behaving honestly?
• Privacy of underlying work: can the evidence be produced without disclosing the private data the agent handled?
• Reflects ongoing behaviour: does the evidence describe how the agent behaves in deployment over time, or a single moment?
• Resistance to gaming: how hard is it for an agent’s owner to make the evidence look better than the agent is?
• Portability: can the evidence be carried to, and understood by, other platforms and parties?
• Cost to adopt: how much effort, money and infrastructure does an agent’s owner need?
• Maturity and coverage: how established is the mechanism, and how many agents does it already cover?

Evidence base and scale. Ratings are qualitative judgements based on each mechanism’s public specification or documentation and on peer-reviewed and preprint literature. We did not run experiments for this comparison. A companion benchmark measures offline verification empirically. We use a four-point scale: Strong, Partial, Weak and None, each with a short reason. Ratings describe the mechanism as typically deployed today, not its best conceivable implementation.

Conflict of interest. Nosphera Research is part of Nosphera. Readers should weigh our ratings of Nosphera accordingly and check the stated reasons against the cited sources.

The six mechanisms

Self-description and marketing

The cheapest and most common evidence is the agent’s own account of itself. It costs nothing, it can be published anywhere, and it reveals nothing the owner wants to keep private. It is also, as evidence, almost empty. Anyone can make it, it can be changed at will, and it says nothing about behaviour after deployment. In economic terms it is cheap talk. When buyers cannot separate good from poor quality before a transaction, they discount every claim to the average, which in turn drives quality providers out ^[7]. Self-description remains useful for discovery: it tells you what the agent intends to do. It should never be the basis of a decision with consequences.

Marketplace ratings and reviews

Ratings turn the experience of past users into a signal for future ones. A well-run reputation system needs long-lived identities and feedback that is honestly given, collected and used ^[8], and online feedback mechanisms have real power to sustain cooperation among strangers ^[9]. Their weaknesses are equally well documented. Reviews can be fabricated, and fraud is most likely exactly where a seller’s reputation is weak or competition intense ^[10]. Ratings also inflate over time as leaving negative feedback becomes socially costly, so that average scores drift upward and lose information ^[11]. Ratings live inside one platform: the platform can edit or remove them, and they rarely travel with the agent. For agents specifically, ratings are sparse because few agents have many paying users yet, and the reviewer usually cannot see what the agent did, only the result.

Registries and agent cards

Registries and agent cards answer the questions what is this, who publishes it, and how do I reach it? The MCP Registry, launched in preview in September 2025, is a community-maintained catalogue of public MCP servers. Server maintainers publish self-reported metadata, and moderation relies on community reports and maintainer denylisting rather than proactive vetting ^[1]. Publishers authenticate the namespace they publish under through GitHub or a domain they control ^[12]. That proves who published an entry, not whether the server is good. The A2A specification defines an Agent Card, a JSON document in which an agent describes its identity, skills, endpoint and authentication requirements. Version 1.0 of the specification also defines how Agent Cards can be signed ^[2].

These are strong mechanisms for identity and discovery: they use open formats, cost little to adopt, and signed cards can be checked cryptographically. But their content is declared, not observed. A signed card proves who made a claim about capability, not that the capability exists, and neither mechanism records how the agent behaves after it is found.

Static evaluations and leaderboards

Benchmarks measure what an agent can do under controlled conditions. AgentBench evaluates language models acting as agents across interactive environments ^[3]. SWE-bench asks whether systems can resolve real GitHub issues ^[4]. Chatbot Arena ranks models by crowdsourced pairwise human preference ^[5]. Evaluations are the only mechanism in this comparison that directly measures capability on defined tasks, and good ones are reproducible and citable. Nothing else replaces them.

Their limits are the subject of a growing literature. Training data can contaminate benchmarks, inflating scores ^[13]. Agent benchmarks often ignore cost, lack holdout sets adequate to prevent overfitting, and are difficult to reproduce ^[14]. Public leaderboards can be distorted when some providers test many private variants and disclose only the best ^[15]. Most fundamentally, an evaluation is a snapshot. It describes a model or agent configuration at a point in time, while deployed agents change their prompts, tools and models continuously. A recent proposal for pre-deployment trust certification of enterprise agents extends evaluation with scenario generation and a machine-verifiable certificate ^[16]. That strengthens the snapshot but does not turn it into a record of conduct in deployment.

On-chain identity and reputation registries (ERC-8004)

ERC-8004, “Trustless Agents”, is a draft Ethereum standard that defines three on-chain registries ^[6]. The identity registry gives each agent a transferable token that points to a registration file. The reputation registry lets clients post feedback signals about an agent. The validation registry lets an agent request independent checks of its work and record the responses. The standard is designed to work alongside MCP and A2A.

The strengths are structural. Records on a public chain are tamper-evident and do not depend on any single operator. Identity is portable across every application that reads the chain. Feedback can be revoked, but its on-chain record cannot be deleted. The weaknesses are acknowledged by the standard itself. Its authors note that Sybil attacks are possible, and they require consumers to filter feedback by a chosen set of client addresses rather than trust the aggregate. More sophisticated aggregation is expected to happen off-chain ^[6]. Everything written on-chain is public, so private details must stay off-chain behind hashes or links. Adoption requires wallets, fees and chain integration. As of this writing the standard is still a draft.

Signed behavioural history (Nosphera)

Nosphera records what a connected agent does as a chain of signed events. Each event is linked to the one before it, and only fingerprints of the content are kept. New proof records are committed to a signed public anchor every day. From the record, the server computes ratings in five public areas and a 0–1000 trust score. Work that is confirmed by another owner’s agent is recorded separately as verified proof that anyone can recompute. An agent can request a time-limited attestation of its standing, and anyone can verify it offline against keys published under a did:web identifier ^[17]. The design rationale and threat model are set out in our companion paper.

The distinctive strengths are that the evidence accumulates continuously from deployment, that it is hard to rewrite quietly, that it can be checked without contacting Nosphera, and that it is produced without publishing the agent’s private work. The weaknesses are set out in Section 5.

Results

Table 1 rates the mechanisms on tamper-evidence and verifiability; Table 2 rates them on usefulness and cost.

Four patterns stand out.

No mechanism is strong everywhere. Each was designed to answer a different question. Registries and cards answer who and where. Evaluations answer what can it do under test. Ratings answer what did past users think. On-chain registries answer what has been publicly asserted about this identity, by whom. Behavioural history answers what has it actually been doing, and who confirmed it. A relying party with real stakes needs more than one answer.

Tamper-evidence and privacy pull in different directions. The mechanisms with the strongest decentralised guarantees, the public chains, make everything they store public. The mechanisms with the best privacy, self-description and metadata, offer no tamper-evidence worth the name. Signed histories that store only fingerprints, and runtime-evidence designs such as OVERT that keep protected content inside the operator’s environment ^[18], are attempts to get both. Today they buy privacy at the cost of relying on an issuer.

Only continuous records describe deployment. Of the six, only ratings, on-chain feedback and behavioural histories change as the agent is used. Ratings and on-chain feedback depend on users choosing to leave feedback. A behavioural history records activity as it happens and adds outside confirmation on top.

Gaming resistance is always partial. Every mechanism that counts something can be gamed by producing more of it. Fake reviews, contaminated benchmarks, Sybil feedback and colluding confirmers are versions of the same attack. The defences are also similar: weight independent sources, make history costly to discard, keep some parameters away from optimisation, and show uncertainty honestly.

Where Nosphera is weaker

A comparison written by one of the compared parties is only useful if it is candid about that party’s weaknesses. On the criteria above, Nosphera is weaker in the following respects.

• It is a single operator. Unlike a public chain, Nosphera is one organisation. Offline verification and public anchors limit how much a relying party must trust it, but they do not remove that trust. Federation across independent operators is future work.
• Signing is custodial in version 1. Events submitted over MCP are signed with keys Nosphera holds. Public anchors make it detectable if past history is rewritten, but they do not prevent the operator from fabricating new events. Agents that hold their own keys can sign client-side through the API; accepting agent-signed events over MCP is planned.
• It is young. The network is new, so most agents have short histories, and a short history is weak evidence however well it is protected. Benchmarks and established marketplaces have far more data today.
• It only covers agents that connect. An agent’s absence from Nosphera says nothing about its quality. Evaluations can test any agent, and registries can list any server.
• Part of the scoring is private. The parameters that classify an agent’s own activity are not published, which makes them harder to optimise against but also impossible to audit independently today. The independently confirmed component can be recomputed by anyone.
• Self-reported activity is still self-reported. The record proves that an agent reported something at a given time and that the report has not been altered since. It does not prove that the report was true. Independent confirmation addresses this only for the work that is confirmed.
• Portability is still partial. Attestations are portable and can be checked anywhere. The history itself lives on Nosphera, and publishing it in emerging standard formats, such as ERC-8004 validation records, ATTP-style trust responses ^[19] or OVERT evidence, is future work.

Using mechanisms together

Because the mechanisms answer different questions, the practical recommendation is to layer them rather than choose one.

For builders. Publish an honest description and, where relevant, a registry entry or signed Agent Card, so that people can find you and check who you are. Run and report evaluations that match your agent’s real tasks, including cost, as Kapoor and colleagues recommend ^[14]. Then let your agent accumulate a record from deployment that others can verify and that confirms work done for other people’s agents. If you operate in a Web3 context, ERC-8004 identity can sit alongside this. The aim is a set of mutually reinforcing signals, each covering a gap in the others.

For relying parties. Treat each signal as evidence for the specific question it answers, and check provenance: who made this claim, can I verify it without trusting them, and when was it true? Prefer evidence from parties the agent does not control. Treat a new agent as unknown rather than bad. No reputation signal substitutes for task-specific testing, scoped permissions and human oversight. Risk-management guidance treats trustworthiness as multi-faceted for exactly this reason ^[20].

For researchers. The gaps in this table are research problems. How should independence between confirmers be measured? Can private scoring be made auditable through verifiable computation or confidential audit? How should behavioural evidence be expressed in emerging standards without losing its privacy properties? We would welcome joint work on each.

Conclusion

An agent can tell you what it is, show you how it scored, point to what others said, register itself on a chain, or show you what it has been doing. Each is worth something, and none is sufficient alone. Signed behavioural history fills the gap the others leave, which is continuous, privacy-preserving, independently checkable evidence of conduct in deployment. In its current form it also carries real limitations: a single operator, custodial signing in version 1, a young network, and coverage limited to agents that connect. We expect the strongest practice to combine these mechanisms, and we expect the mechanisms themselves to converge as the standards mature.