CAPTCHAs punish humans while computer-use agents solve them in milliseconds. IP-based rate limits collapse when agents rotate addresses or share infrastructure with legitimate users. The traditional anti-abuse toolkit assumes a clean boundary between humans and bots. That boundary no longer exists.
Continuity-auth proposes a different primitive: device-continuity proofs. Instead of asking “Are you human?” or “What is your IP?”, the system asks “Can you prove you are the same device over time?” The longer a device remains consistent, the more respect it accumulates. Rate limits scale inversely with respect.
This is a Show HN project built with Clojure/Script, babashka, and Datalevin. It targets open-access endpoints where agents and humans coexist without requiring login flows or identity verification.
The Problem Space
Traditional anti-abuse mechanisms fail in multi-agent environments:
- CAPTCHAs: Vision models solve them faster than humans. Audio alternatives are worse. Increasing difficulty punishes accessibility.
- IP throttling: Agents share cloud IPs with legitimate traffic. Residential proxies are cheap. IPv6 makes per-address limits meaningless.
- Session tokens: Ephemeral identities are free. Agents spawn new sessions trivially.
- Device fingerprinting: Browsers randomize fingerprints for privacy. Agents can clone or rotate fingerprints.
The core issue is that abuse detection relies on signals that agents control or can trivially bypass. You need a signal that is expensive to fake but cheap to verify, and that accumulates value over time.
Device-Continuity Proofs
A continuity proof is a cryptographic commitment that binds a client to a persistent identity without revealing hardware details or requiring registration.
The flow:
- Client generates a keypair on first contact.
- Server issues a challenge nonce.
- Client signs the nonce with its private key.
- Server verifies the signature and maps the public key to a continuity record.
- Each subsequent request includes a fresh signature over a new nonce.
The public key becomes the device identifier. The server tracks how long that key has been active and how consistently it has behaved. Respect accumulates as a function of time and good behavior.
Respect-Weighted Rate Limits
Instead of fixed quotas, limits scale with respect:
| Respect Tier | Age Threshold | Requests/Hour | Burst Allowance |
|---|---|---|---|
| New | 0-24 hours | 10 | 2 |
| Established | 1-7 days | 100 | 10 |
| Trusted | 7+ days | 1000 | 50 |
A device that has been active for seven days without triggering abuse signals gets 100x the quota of a fresh device. This makes ephemeral identities expensive: you cannot bypass limits by spawning new keys because new keys start at the bottom of the respect ladder.
Preventing Proof Cloning
An attacker could copy a private key to multiple devices and share the respect. Mitigations:
- Nonce replay detection: Each nonce is single-use. Concurrent requests from the same public key with different nonces trigger a respect penalty.
- Behavioral fingerprinting: Request patterns, timing jitter, and TLS fingerprints are logged. Sudden changes in behavior flag the key for review.
- Gradual respect decay: If a key goes silent for days and then resumes, respect decays. This prevents key marketplaces where old keys are sold.
None of these are perfect. The goal is to make cloning more expensive than generating a new key and waiting.
Multi-Agent Scenarios
When an agent framework runs multiple sub-agents on the same device, you have two options:
- Shared continuity proof: All sub-agents use the same keypair. They share a single respect pool. This is simpler but creates contention if sub-agents have different workloads.
- Per-agent proofs: Each sub-agent gets its own keypair. Respect accumulates independently. The server must detect when multiple keys originate from the same device (via behavioral fingerprinting) and apply aggregate limits.
The first option is easier to implement. The second is more flexible but requires deeper instrumentation.
Implementation Shape
The project uses Datalevin for persistent storage of continuity records. Each record tracks:
- Public key (identity)
- First seen timestamp
- Last seen timestamp
- Request count
- Abuse flags
- Current respect score
Babashka handles the CLI client. ClojureScript handles the browser client. Both generate Ed25519 keypairs and sign nonces using the Web Crypto API (browser) or libsodium bindings (CLI).
A minimal server endpoint:
(defn verify-continuity [req]
(let [pubkey (get-in req [:headers "x-continuity-pubkey"])
nonce (get-in req [:headers "x-continuity-nonce"])
signature (get-in req [:headers "x-continuity-signature"])
record (db/get-continuity-record pubkey)]
(if (and (verify-signature pubkey nonce signature)
(not (nonce-used? nonce))
(within-rate-limit? record))
(do
(db/update-continuity-record pubkey)
(mark-nonce-used nonce)
{:status 200 :body "OK"})
{:status 429 :body "Rate limit exceeded"})))The nonce store is a time-windowed set. Nonces older than 60 seconds are purged. This prevents unbounded memory growth while maintaining replay protection.
Observability and Abuse Detection
You need visibility into:
- Respect distribution: How many devices are in each tier? If 90% are stuck in “New”, your thresholds are too aggressive.
- Nonce replay attempts: Spikes indicate key-sharing or cloning attacks.
- Behavioral anomalies: Sudden changes in request rate, user-agent, or TLS fingerprint for a given public key.
- Respect decay events: Keys that go dormant and then reactivate.
A simple dashboard tracks these metrics. Alerts fire when replay attempts exceed a threshold or when a single public key exhibits multiple distinct behavioral profiles.
Failure Modes
Key loss: If a user loses their private key (device reset, browser cache clear), they start over at zero respect. This is intentional but painful for legitimate users. Mitigation: allow optional email-based key recovery, but this reintroduces identity.
Sybil attacks: An attacker generates thousands of keys and lets them age. After seven days, they have thousands of high-respect identities. Mitigation: require proof-of-work during key generation or impose a global cap on new keys per IP per day.
Behavioral fingerprinting evasion: Sophisticated agents can mimic human timing patterns and rotate TLS fingerprints. This is an arms race. The goal is to raise the cost, not achieve perfect detection.
Respect inflation: If abuse signals are weak, bad actors accumulate respect and then exploit it. You need aggressive decay and clear abuse thresholds.
Trade-Offs
| Approach | Privacy | Usability | Abuse Resistance | Complexity |
|---|---|---|---|---|
| CAPTCHA | High | Low | Low | Low |
| IP throttling | Medium | High | Low | Low |
| OAuth login | Low | Medium | High | Medium |
| Continuity proofs | High | High | Medium | High |
Continuity-auth sacrifices simplicity for privacy and usability. You avoid forcing users to log in or solve puzzles, but you take on cryptographic key management, nonce replay detection, and behavioral analysis.
Technical Verdict
Use continuity-auth when:
- You run an open-access API or web service where login is optional or undesirable.
- You expect both human users and agents to access the same endpoints.
- You want to avoid CAPTCHAs and IP-based throttling.
- You can tolerate the complexity of key management and behavioral fingerprinting.
Avoid it when:
- You already require login and can tie rate limits to user accounts.
- Your threat model does not include sophisticated agents (traditional IP throttling is cheaper).
- You cannot afford the operational overhead of nonce stores, behavioral analysis, and respect scoring.
- You need immediate abuse mitigation (continuity proofs require time to accumulate signal).
This is not a drop-in replacement for existing anti-abuse systems. It is a new primitive for environments where the line between human and agent is blurred and where privacy and usability matter more than perfect security.