Sybil Attacks Guide: Fake Identities in Peer-to-Peer Networks, Reputation Systems and Agent Ecosystems

Any system that gives weight to identities it cannot tell apart can be captured by one party that creates many of them. That is a Sybil attack, and it applies far beyond its origins in peer-to-peer research: blockchains, anonymity networks, review and rating systems, voting and reward programmes, and now registries and marketplaces of AI agents all count identities to decide who is trusted, who is heard or who gets paid. This guide explains how Sybil attacks work, the related eclipse and whitewashing attacks, the families of defence and their trade-offs, how the problem is changing as software agents gain identities of their own, and how to detect and measure Sybil activity. It is written for architects, fraud and trust-and-safety teams, protocol designers and security leaders who own any system where identity is cheap and influence is counted.

Key takeaways

• Cheap identities break counting. Douceur's 2002 paper showed that without a logically central authority vouching for identities, a faulty entity can present many identities in nearly all practical settings.
• Every defence raises the cost of an identity. Certification by an authority, resource cost such as proof of work or stake, identity proofing and trust graphs all work by making the next identity more expensive than the influence it buys.
• Sybil is usually a precursor. Eclipse attacks, review fraud, vote manipulation and reputation laundering are built on many controlled identities, so the detection signal often appears in enrolment before the harm.
• Design the reputation system, not just the sign-up. Whitewashing (rejoining with a fresh identity) defeats any system where a new identity starts with more standing than a penalised one.
• Agent ecosystems inherit the problem. Agent cards, registries and agent marketplaces need provenance and signatures, otherwise one operator can flood them with look-alike agents and inflated ratings.

What a Sybil attack is

John Douceur of Microsoft Research named the attack in "The Sybil Attack" at the first International Workshop on Peer-to-Peer Systems (IPTPS) in 2002. The paper's problem statement is that if a single faulty entity can present multiple identities, it can control a substantial fraction of the system. Its central result is that, without a trusted agency certifying identities, preventing this is only possible under unrealistic assumptions about equal resources and coordination among participants.

The useful way to think about it is an identity-to-influence ratio. A system is exposed when:

• Identities are cheap: creating one costs less than a few seconds of automated work.
• Influence is counted per identity: votes, ratings, routing positions, relay selection, reward eligibility or rate-limit buckets.
• Identities are hard to link: the system cannot tell that many identities share one operator.

Remove any one of the three and the attack loses most of its value. That is why the defences below differ so much: some make identities expensive, some stop counting per identity, and some get better at linking.

Where Sybil attacks appear

In the Tor case the Tor Project described dozens of relays joining at 00:00:00 on the first of each month and slowly disappearing, and a later group of relays that appeared without family declarations and with empty contact fields. Rejection is done by the directory authorities, only when a majority agree, based on Network Health team recommendations. See the Anonymity Networks for Defenders Guide.

Related attacks built on Sybil identities

• Eclipse: CyBOK describes a victim surrounded by colluding peers that block its view of the rest of the system, a composite attack that may combine routing table poisoning, denial of service, Sybil identities, collusion and whitewashing. Heilman and colleagues showed an attacker with enough IP addresses could monopolise all connections to and from a Bitcoin node, then use it for N-confirmation double spending, selfish mining and adversarial forks.
• Whitewashing: a peer with a bad reputation leaves and rejoins as an apparently benign newcomer. CyBOK flags this as especially dangerous in reputation-based systems.
• Collusion and ballot stuffing: Sybil identities rate each other or vote together to manufacture consensus or reputation.
• Coordinated inauthentic behaviour: networks of fake or hijacked accounts amplifying content. ATT&CK tracks the preparation as T1585 Establish Accounts (T1585.001 Social Media Accounts) and T1586 Compromise Accounts. See the Bot Farms and Fake Engagement Guide.

Defence families and their trade-offs

Bitcoin's whitepaper puts the design choice in one line: majority decision by one IP address, one vote could be subverted by anyone able to allocate many IPs, so proof of work was chosen as "essentially one-CPU-one-vote". The lesson generalises: count a scarce resource, not identities.

Sybil risk in AI agent ecosystems

Agents now have identities that other software relies on: agent cards, registry entries, marketplace listings, OAuth clients and signed HTTP requests. Each is cheap to create, and several ecosystems count them, for example by ranking agents on ratings or downloads, or by letting agents vote, review or delegate to each other.

• Discovery and impersonation: the A2A specification (version 1.0.0) lets clients find Agent Cards through a well-known URI, registries or direct configuration, and makes Agent Card signing optional. Where signatures are present, clients must verify them with keys found by kid and jku or a trusted key store, should verify at least one signature before trusting a card, and must not use expired or revoked keys. Require signed cards from known providers in any registry you run. See the A2A Protocol Security Guide.
• Reputation inflation: MITRE ATLAS AML.T0111 covers inflating the apparent reputation of AI supply chain artefacts. Download counts, stars and ratings from unverified identities are Sybil-prone by construction. See the MITRE ATLAS AML.T0111 AI Supply Chain Reputation Inflation guide.
• Registries: tie every registered agent to an accountable owner, a verified publisher and an attested runtime identity, and cap how many entries one owner can create. See the AI agent registry guide.
• Multi-agent decisions: where agents vote, review each other's work or reach consensus, weight by verified provenance and diversity of operator, not by agent count. Many agents from one operator are one voice.
• Agent traffic at your edge: automated clients that sign requests can be distinguished from anonymous bots, but signing proves key possession, not uniqueness of operator. See the Web Bot Auth and HTTP Message Signatures for Agents guide.

Decision guidance

• Permissioned systems (enterprise clusters, consortium ledgers, internal agent registries): use an admission authority. Openness has no value here, and certificate-based enrolment removes most Sybil risk. See the Distributed Systems Security Guide.
• Open, pseudonymous systems (public ledgers, P2P networks): use resource cost plus diversity constraints, and design peer selection so no single network range can dominate a node's connections.
• Consumer platforms (reviews, social, marketplaces): combine graded identity assurance (stronger checks only where influence is high, such as sellers or reviewers with reach), behavioural linking and reputation that grows slowly.
• Small organisations running a forum, survey or referral scheme: rate limits, payment or phone binding for rewards, delayed payouts and manual review of clusters are usually enough. Avoid identity proofing unless the benefit is worth it to the attacker.
• Large platforms: invest in graph-based linking across devices, payment instruments and behaviour, and in a trust-and-safety process that removes whole clusters rather than single accounts.

How to implement

1. Map where identity count equals influence. List every place the system counts identities: votes, ratings, relay or peer selection, rewards, rate-limit buckets, consensus.
2. Estimate the attacker's economics. For each, compare the cost of one additional identity with the value of the influence it buys.
3. Raise identity cost where value is high, using the cheapest effective family from the table: admission control for permissioned systems, resource cost for open consensus, graded proofing for consumer benefits.
4. Redesign reputation: low starting weight, slow accrual, fast loss, and no benefit from abandoning a penalised identity.
5. Add linking signals at enrolment and in behaviour: shared infrastructure, devices, payment instruments, timing patterns and missing operator metadata (the signal that exposed Tor relay groups).
6. Test in shadow mode: score clusters without acting, measure false positives on known-good populations, then act on the highest-confidence clusters first.
7. Keep a rollback and appeal path: cluster removals should be reversible, and legitimate users behind shared networks need a route to recover.

Detection and measurement

• Enrolment telemetry: sign-up rate per network range, autonomous system, device fingerprint and payment instrument; bursts of accounts with near-identical profiles.
• Join and leave patterns: synchronised joins at fixed times and slow decay, as seen on Tor.
• Graph structure: dense clusters with few edges to the established population; reciprocal rating rings.
• Peer diversity: for nodes, the share of connections from the same network ranges; sudden loss of diversity can precede an eclipse.
• Metadata gaps: missing contact details, family or owner declarations on peers, agents or listings.

Metrics:

• Share of influence (votes, ratings, routing positions, relay bandwidth) held by the largest linked cluster.
• Median age and verification level of identities contributing to top-ranked items.
• Clusters detected and removed per month, and median time from cluster formation to removal.
• False positive rate from appeals on cluster actions.
• Percentage of registry entries or agent cards with verified publisher signatures.

Common failure patterns

• Counting accounts as people. Any metric that sums identities (reviews, votes, stars, peer count) is a Sybil target unless weighted.
• Starting newcomers at full trust. This rewards whitewashing; penalised actors simply rejoin.
• Removing accounts one by one. Operators replace them faster than reviewers find them; act on linked clusters.
• Relying on IP limits alone. Proxies and device farms defeat them; combine with other linking signals.
• Treating signatures as uniqueness. A signed agent card proves who holds the key, not that the operator is not running a thousand others.
• Ignoring compromised genuine accounts. Aged, hijacked accounts pass graph and age checks. See the Account Takeover Prevention Guide.

Framework mapping

Practitioner checklist

• List every mechanism where identity count converts into influence, reward or routing position.
• For each, write down the cost of one new identity and the value it buys.
• Use admission control for any permissioned or internal system, including agent registries.
• Give new identities low initial weight and make penalties survive re-registration.
• Collect linking signals at enrolment: network, device, payment and timing.
• Act on linked clusters, with an appeal route.
• Require signed agent cards and verified publishers before agents appear in discovery or rankings.
• Track the share of influence held by the largest linked cluster as a standing metric.

Standards and references

• Microsoft Research: The Sybil Attack (Douceur, IPTPS)
• CyBOK: Distributed Systems Security Knowledge Area
• NIST: SP 800-63A-4 Identity Proofing and Enrollment
• USENIX: Eclipse Attacks on Bitcoin's Peer-to-Peer Network
• A2A Project: Agent2Agent Protocol Specification
• OWASP: Automated Threat OAT-019 Account Creation
• Tor Project: Malicious relays and the health of the Tor network
• FTC: Final rule banning fake reviews and testimonials

Related NHI Mgmt Group resources: Distributed Systems Security Guide · Fake Account Creation and Sign-up Fraud Guide · Blockchain and Distributed Ledger Security Guide · Agent Identity and Access Guide