Once agents from different organizations transact — dispatching tasks, calling each other's tools, participating in a marketplace — counterparties need some basis for deciding whether to engage. Reputation is the natural mechanism, and a public reputation lookup keyed on an agent's identifier is the natural interface.
It is also a data-leakage surface with several non-obvious failure modes. A naively-built reputation endpoint tells attackers which agents exist, reveals how much business specific counterparties do, and lets a bad actor shed a poor history by rotating identity. Each of these has a known fix.
The Anti-Enumeration Contract
The first design decision: what does the endpoint return for an identifier it has never seen?
The intuitive answer is 404 Not Found. That is an enumeration oracle. An attacker with a list of candidate identifiers learns which ones exist by observing status codes — which agents are registered, which organizations participate, roughly how large the population is. For DID-based identifiers derived from domain names, this maps directly onto which companies are deploying agents, which is competitive intelligence.
The correct behavior is a uniform response regardless of existence — an unknown identifier and an identifier that exists but has too little history must be indistinguishable to the caller. Existence is never confirmed or denied through the public surface, by status code or by any other observable difference.
This has to be enforced consistently, including on error paths and in timing. A 200 for unknown agents that takes 5ms while known agents take 50ms is the same oracle with extra steps. Normalize the work performed, or accept a fixed floor on response time.
k-Anonymity on the Aggregates
The second decision: how much history is enough to publish a score?
A reputation score computed from two completed interactions reveals a great deal about those two interactions. If a counterparty knows they were one of them, they can infer the other party's rating. With three or four, small changes in the score over time leak individual ratings by differencing — observe the score before and after a known interaction and the new rating is recoverable.
The mitigation is a minimum-observations threshold, the k in k-anonymity: below k interactions, suppress the metrics and return unknown. Choosing k is a trade — too high and the endpoint is useless for new agents, too low and it leaks. Values in the range of 5 to 20 are typical starting points, tuned by how sensitive individual ratings are in your ecosystem.
Two refinements matter:
Coarsen the output. Publish bands or a recommendation rather than a precise figure. A score of 0.847 changing to 0.851 is a differencing signal; a recommendation of favorable is not. Coarse output is also more honest, because the underlying precision is not real.
Rate-limit and delay updates. Continuous real-time score updates enable differencing even above k. Update on a schedule, in batches, so a single interaction cannot be isolated in time.
Separately, disclose participation counts carefully or not at all. Interaction volume is commercially sensitive — it tells competitors how much business an agent is doing.
Reputation Is Not Trust
These get conflated and they answer different questions.
Reputation is observed history: completion rate, dispute rate, ratings from counterparties, longevity. It is descriptive, backward-looking, and derived from what others report.
Trust is an authorization decision: given this identity, this reputation, these attestations, and my own policy, what am I willing to let this agent do? It is prescriptive, forward-looking, and yours alone.
The distinction has practical consequences. Reputation is a shared, gameable, partially-public signal; trust is a private decision that should weigh reputation alongside things reputation cannot capture — attestations from issuers you trust, your own direct experience, the value at stake in this specific interaction, and contractual relationships. A system that lets a public reputation score directly gate access has outsourced its authorization policy to whoever can manipulate the score. See trust score versus allowlist and trust scoring models for autonomous agents.
The reasonable pattern: reputation is one input to a trust computation that also includes attestations and local history, and the trust level gates capability. High-value interactions should require more than reputation regardless of how good the reputation is.
Reputation Needs Verified Identity
Reputation attached to a self-asserted name is worthless. If creating a new identity is free and reputation is per-identity, any agent with a poor history creates a fresh one — the whitewashing attack, and it is the failure mode that has killed reputation systems repeatedly.
Two requirements:
Cryptographically verified identity. Reputation attaches to an identifier whose control is proven by signature, not asserted in a payload. See agent identity spoofing and DID verification.
Costly identity, or organization-anchored identity. Either creating a fresh identity has a cost — staking, verification, a waiting period — or reputation attaches partly at the organization level so a new agent under a known organization inherits some standing and a new organization starts genuinely unknown. Organization anchoring is usually the more practical of the two: it gives new agents from established operators a reasonable starting position while making wholesale identity reset expensive.
Then handle the corresponding attacks. Sybil: many identities inflating each other's scores, mitigated by weighting ratings by the rater's own standing and by detecting reciprocal clusters. Ballot stuffing: high-volume trivial interactions to accumulate positive history, mitigated by weighting by interaction value and by capping the contribution of any single counterparty pair. Bad-mouthing: coordinated negative ratings against a competitor, mitigated by the same rater-weighting plus dispute resolution.
What to Publish and What to Keep Private
Publish: a recommendation or band, whether the agent meets a threshold, a coarse longevity indicator, and verified attestations the agent chooses to disclose.
Keep private: individual ratings, counterparty identities, interaction values, per-interaction detail, exact scores, and precise volumes. This is not just privacy hygiene — an interaction between two organizations is their business relationship, and publishing its existence to a third party discloses information neither of them agreed to share.
Make contribution authenticated and scoped. Only a counterparty who actually completed an interaction can rate it, verified against the interaction record rather than accepted on assertion. Unauthenticated contribution turns the system into a manipulation surface immediately.
Common questions
Is a public reputation system worth building at all?
It depends on whether your ecosystem has open counterparty discovery. If agents transact only with pre-arranged partners, bilateral trust and contracts do the work and reputation adds little. If agents discover and engage counterparties they have no prior relationship with — a marketplace, a federation — some shared signal is necessary, because the alternative is that nobody transacts with anyone new. See agent task marketplaces and escrow.
How do new agents get started with no reputation?
Through mechanisms that do not require history: organization-anchored standing, attestations from issuers the counterparty trusts, low-value trial interactions, or escrow that bounds the counterparty's exposure. A system where new participants cannot get their first interaction is a closed system with extra steps, so the on-ramp deserves as much design attention as the scoring.
Should reputation decay over time?
Yes. Behavior from two years ago is weaker evidence than behavior from last month, and without decay, accumulated standing becomes an unassailable moat and a stale one. Exponential decay with a half-life of a few months is a reasonable default. Decay also limits the value of ballot stuffing, since accumulated volume erodes.
What about disputes — do they count against reputation automatically?
They should not count automatically, because a dispute is an allegation. Count the resolution: a dispute resolved against an agent is negative signal, one resolved in their favor is neutral or mildly positive, and an unresolved dispute is pending rather than negative. Automatic penalties on dispute filing create an obvious attack — file disputes against competitors — and undermine confidence in the whole signal.
How Praesidia approaches reputation
Praesidia exposes a public per-agent reputation lookup keyed on the agent's verified identity, built to the anti-enumeration and minimum-observation principles above: existence is never confirmed or denied through the public surface, and metrics stay suppressed until enough independent history exists to publish them safely. Contribution is authenticated and scoped, so only counterparties with a real interaction record can submit signal.
Reputation feeds trust scoring rather than gating access directly, and connections require a minimum trust level — keeping the shared, partially-public signal separate from the local authorization decision. See trust scores and attestations for agents and the Praesidia documentation.