Identity Infrastructure for the Agentic Web

1. Executive Summary

BOTCHA is a reverse CAPTCHA — a verification system that proves you are an AI agent, not a human. While traditional CAPTCHAs exist to block bots, BOTCHA exists to welcome them.

As AI agents become first-class participants on the internet — browsing, purchasing, comparing, auditing — they need a way to prove their identity and declare their intent. BOTCHA provides three layers of proof:

• Proof of AI — Computational challenges (SHA-256 hashes in under 500ms) that only machines can solve.
• Proof of Identity — Persistent agent registration with cryptographic keys, verified via HTTP Message Signatures (RFC 9421).
• Proof of Intent — Capability-scoped sessions where agents declare what they plan to do, for how long, and on behalf of whom.

BOTCHA is open source, free to use, and deployed as a hosted service at botcha.ai. It ships TypeScript and Python SDKs, server-side verification middleware, a CLI, and a LangChain integration.

2. The Problem: Who Is This Agent?

The internet was built for humans. Authentication systems — passwords, OAuth, CAPTCHAs — all assume a human is at the keyboard. But the web is changing.

The rise of agentic AI

AI agents are no longer just answering questions. They are browsing product catalogs on behalf of consumers, comparing prices across retailers, purchasing goods and services with real money, auditing compliance postures, and negotiating contracts.

Every major AI lab is building agent capabilities. OpenAI's Operator, Anthropic's computer use, Google's Project Mariner — these are production systems that interact with real APIs and real businesses.

The identity gap

When an AI agent hits your API, you face three questions that existing infrastructure cannot answer:

1. Is this actually an AI agent? User-Agent strings are trivially spoofable. There is no reliable way to distinguish a real AI agent from a script pretending to be one.
2. Which specific agent is this? Even if you know it is AI, you do not know if it belongs to a known organization or what its track record is.
3. What does it intend to do? An agent browsing your catalog is very different from one attempting a purchase. Traditional auth grants blanket access — it does not capture intent.

What happens without agent identity

Without a reliable identity layer, the agentic web defaults to chaos. APIs cannot set appropriate rate limits. Businesses cannot authorize transactions. Agents cannot build reputation. Fraud is trivial because there is no audit trail.

3. BOTCHA: Reverse CAPTCHA for AI Agents

BOTCHA inverts the CAPTCHA model. Instead of proving you are human, you prove you are a machine.

The core idea

A CAPTCHA asks: Can you identify traffic lights in this image? A human can; a bot struggles.

BOTCHA asks: Can you compute 5 SHA-256 hashes in 500 milliseconds? A machine can; a human cannot copy-paste fast enough.

This inversion is not just a novelty — it is a fundamental shift. In a world where AI agents are legitimate, wanted participants, the question is no longer "how do we keep bots out?" but "how do we let the right bots in?"

Design principles

Agent-first, always. Every feature in BOTCHA requires an AI agent as a participant. Humans are welcome, but only through an agent. If a human wants dashboard access, their agent generates a device code for them. There is no password form.

Fail-open on infrastructure errors. If the backing store is unavailable, BOTCHA logs a warning and allows the request through. Blocking legitimate traffic is worse than letting an unverified request pass.

Zero configuration to start. An agent can verify itself with a single HTTP request pair. No API keys, no registration — just solve the challenge and get a token.

4. How It Works: The Challenge System

BOTCHA offers four challenge types, each testing a different aspect of machine capability.

Speed Challenge

The primary verification method. The server generates 5 random 6-digit numbers. The agent computes the SHA-256 hash of each and returns the first 8 hex characters — all within 500 milliseconds.

The time limit is generous for any programming language but impossible for a human to copy-paste through. The challenge is not computationally hard — it is computationally trivial, but only if you are a machine.

RTT-aware fairness: The time limit adjusts for network latency. An agent on a satellite connection gets extra time. This prevents geographic discrimination while capping at 5 seconds to prevent abuse.

Reasoning Challenge

Tests language understanding. The server selects 3 questions from 6 categories: math, code, logic, wordplay, common-sense, and analogy. The agent has 30 seconds.

All questions use parameterized generators producing unique values each time. There is no static question bank to memorize. Combined with 45+ generators, the effective answer space is infinite.

Hybrid Challenge

The default challenge type. Combines speed and reasoning — both must pass. Proves the agent can compute fast and reason about language.

Standard (Compute) Challenge

A heavier computational challenge: generate prime numbers, concatenate with a random salt, compute SHA-256. Difficulty scales from easy (100 primes, 10s) to hard (1000 primes, 3s).

5. The Trusted Agent Protocol (TAP)

Solving a challenge proves you are a bot. TAP proves you are a specific, trusted bot.

What is TAP?

The Trusted Agent Protocol is an identity and authorization layer built on top of BOTCHA's proof-of-bot system. Inspired by Visa's Trusted Agent Protocol, BOTCHA's TAP provides:

• Persistent agent identity — unique ID, name, and operator metadata.
• Cryptographic verification — ECDSA P-256 or RSA-PSS public keys; requests signed via HTTP Message Signatures (RFC 9421).
• Capability-based access control — agents declare actions: browse, search, compare, purchase, audit.
• Intent-scoped sessions — time-limited sessions validated against capabilities.
• Trust levels — basic, verified, enterprise.

Agent registration

POST /v1/agents/register/tap
{
  "name": "shopping-agent",
  "operator": "acme-corp",
  "capabilities": [
    { "action": "browse", "scope": ["products", "reviews"] },
    { "action": "purchase", "scope": ["products"],
      "restrictions": { "max_amount": 500 } }
  ],
  "trust_level": "basic"
}

For cryptographic identity, agents register a public key and sign requests using RFC 9421:

x-tap-agent-id: agent_6ddfd9f10cfd8dfc
x-tap-intent: {"action":"browse","resource":"products"}
signature-input: sig1=("@method" "@path" "x-tap-agent-id");created=...;alg="ecdsa-p256-sha256"
signature: sig1=:BASE64_SIGNATURE:

Intent validation and scoped sessions

Before acting, a TAP agent creates a session declaring its intent. The server validates the intent against the agent's registered capabilities, checks scope, and enforces a maximum duration of 24 hours.

POST /v1/sessions/tap
{
  "agent_id": "agent_6ddfd9f10cfd8dfc",
  "intent": { "action": "browse", "resource": "products", "duration": 3600 },
  "user_context": "anon_user_hash"
}

The verification hierarchy

6. Architecture and Security

Infrastructure

BOTCHA runs on Cloudflare Workers — deployed to 300+ edge locations globally. Sub-50ms cold starts, KV storage for all state, no servers to manage.

Token system

Tokens are HMAC-SHA256 JWTs carrying the solved challenge ID (proof of work), a unique JTI for revocation, optional audience claims, and the solve time in milliseconds.

Cryptography

Anti-gaming measures

• Single-use challenges — deleted from storage on first attempt.
• Timestamp validation — rejects timestamps older than 30 seconds or in the future.
• RTT capped at 5 seconds — prevents time manipulation.
• Parameterized question generators — no static lookup tables.
• Salted compute challenges — defeats precomputed hash tables.
• User-Agent ignored — trivially spoofable, not used for verification.
• Anti-enumeration — recovery endpoints return identical shapes regardless of email existence.

Human handoff

When a human needs dashboard access, the agent solves a challenge and receives a device code (e.g., BOTCHA-RBA89X). The human opens the link and is logged in. This adapts the OAuth 2.0 Device Authorization Grant (RFC 8628) with a twist: the agent must solve a BOTCHA challenge to generate the code. No agent, no code.

7. The Full Identity Layer

BOTCHA has grown beyond a proof-of-bot challenge system into a complete identity infrastructure for AI agents. The stack now covers verification, delegation, attestation, reputation, portable credentials, and payment-gated access.

Delegation Chains

"User X authorized Agent Y to do Z until time T." Delegation chains encode this relationship cryptographically. An orchestrator agent can delegate a subset of its capabilities to a sub-agent, which can further sub-delegate — but capabilities can only narrow, never expand. Revoking any link cascades to all descendants.

POST /v1/delegations
{
  "grantor_id": "agent_aaa",
  "grantee_id": "agent_bbb",
  "capabilities": [{"action": "browse", "resource": "products"}],
  "ttl": 3600
}

POST /v1/verify/delegation  ← verify entire chain in one call

Capability Attestation

Fine-grained permission tokens using action:resource patterns with explicit deny rules. An attestation token encodes both what an agent can do and what it explicitly cannot do. Deny rules always take precedence. Wildcards are supported: browse:*, *:products.

POST /v1/attestations
{
  "agent_id": "agent_...",
  "can": ["read:invoices", "browse:*"],
  "cannot": ["purchase:*"],
  "ttl": 3600
}
// Returns signed JWT → present as X-Botcha-Attestation header

Agent Reputation

A score-based reputation system (0–1000, five tiers) that tracks agent behavior across 18 action types in 6 categories: verification, commerce, compliance, social, security, and governance. Scores decay toward the neutral midpoint (500) without activity, preventing stale reputation from persisting indefinitely.

Webhooks

Per-app webhook endpoints receive signed event deliveries over HTTP POST. Payloads are signed with HMAC-SHA256. Apps can subscribe to specific event types: token lifecycle, TAP sessions, delegation changes.

8. Protocol Integrations

BOTCHA integrates with every major emerging agentic protocol, acting as the identity and verification layer for each standard.

x402 Payment Gating

x402 micropayment flow using USDC on Base. Agents pay $0.001 USDC instead of solving a speed challenge. The standard 402 Payment Required response carries payment terms; the agent re-requests with an X-Payment header carrying a payment proof and receives a BOTCHA access token.

GET /v1/x402/challenge
← 402 { amount: "0.001", currency: "USDC", chain: "base", recipient: "0x..." }
← Agent pays, retries with X-Payment header
← 200 { access_token: "eyJ..." }

This provides a payment-alternative to the proof-of-computation model — useful for high-throughput agents where challenge solving overhead is undesirable, and for monetizing API access without requiring a subscription.

Agent Name Service (ANS)

BOTCHA implements the GoDaddy-led ANS standard — a DNS-based agent identity system where an agent's name resolves via TXT records to its endpoint and identity metadata. BOTCHA serves as a verification and badging layer: agents prove ownership of their ANS name and receive a BOTCHA-signed badge JWT.

GET /v1/ans/resolve/my-agent.agents  → DNS TXT lookup + BOTCHA badge
POST /v1/ans/verify                  → prove DNS ownership → issue badge

W3C DID / Verifiable Credentials

BOTCHA operates as a W3C Decentralized Identifier (DID) issuer under did:web:botcha.ai. After solving a challenge, an agent can request a W3C Verifiable Credential JWT. The VC is signed with BOTCHA's private key and can be verified by any party who resolves the DID Document — no round-trip to BOTCHA required.

// 1. Resolve the issuer
GET /.well-known/did.json → DID Document with public key

// 2. Issue credential
POST /v1/credentials/issue  (Authorization: Bearer <botcha-token>)
→ { "vc": "eyJ..." }  ← portable JWT, verifiable offline

// 3. Anyone can verify
POST /v1/credentials/verify
→ { "valid": true, "payload": { "iss": "did:web:botcha.ai", ... } }

This enables agent credentials that travel across trust boundaries. A BOTCHA VC issued to an agent can be presented to a third-party API, a financial institution, or another agent network without those parties needing a BOTCHA account.

A2A Agent Card Attestation

Google's A2A (Agent-to-Agent) protocol defines a standard JSON Agent Card format published at /.well-known/agent.json. BOTCHA acts as a trust seal issuer: any agent that publishes an A2A card can submit it to BOTCHA for attestation. BOTCHA produces a tamper-evident hash-and-signature bundle that third parties can verify without contacting BOTCHA again.

POST /v1/a2a/attest  (Authorization: Bearer <botcha-token>)
→ { "attestation": { "trust_level": "verified", "token": "eyJ..." },
    "attested_card": { "extensions": { "botcha_attestation": {...} } } }

POST /v1/a2a/verify-card  ← verify any attested card offline

BOTCHA publishes its own A2A Agent Card at /.well-known/agent.json, making it auto-discoverable by A2A-aware agents.

OIDC-A Attestation

Enterprise agent authentication chains require a bridge between human identity systems and agent identity systems. OIDC-A (OpenID Connect for Agents) provides this bridge. BOTCHA implements:

• Entity Attestation Tokens (EAT / RFC 9334) — signed JWTs that attest agent provenance, verification method, and model identity. Suitable for presentation to enterprise relying parties.
• OIDC-A Agent Claims — an OIDC claims block carryingagent_model, agent_operator, human_oversight_required, and task metadata. Compatible with standard OAuth2 token responses.
• Agent Grant Flow — an OAuth2-style authorization grant where an agent requests access on behalf of a human. If human_oversight_required is set, the grant is pending until the human approves via a BOTCHA oversight URL.

// Enterprise chain: human → IdP → BOTCHA → agent
POST /v1/attestation/eat
→ EAT JWT (RFC 9334) for relying party presentation

POST /v1/auth/agent-grant
→ { "grant_id": "...", "status": "pending", "oversight_url": "..." }
// Human approves at oversight_url → agent receives access

9. Integration: SDKs and Middleware

Client SDKs (for agents)

TypeScript (@dupecom/botcha on npm):

import { BotchaClient } from '@dupecom/botcha';
const client = new BotchaClient();

// Drop-in fetch replacement — auto-solves challenges on 403
const response = await client.fetch('https://api.example.com/products');

// Or get a token explicitly
const token = await client.getToken();

Python (botcha on PyPI):

from botcha import BotchaClient

async with BotchaClient() as client:
    response = await client.fetch("https://api.example.com/products")
    token = await client.get_token()

Server-side verification (for API providers)

Express:

import { botchaVerify } from '@dupecom/botcha-verify';
app.get('/api/products', botchaVerify({ secret }), handler);

FastAPI:

from botcha_verify import BotchaVerify
botcha = BotchaVerify(secret=os.environ["BOTCHA_SECRET"])

@app.get("/api/products")
async def products(token=Depends(botcha)):
    return {"solve_time": token.solve_time}

Also available: Hono middleware, Django middleware, and TAP-enhanced middleware with full cryptographic + computational dual verification.

CLI

npm install -g @dupecom/botcha-cli
botcha init --email you@company.com
botcha tap register --name "my-agent" --capabilities browse,search
botcha tap session --action browse --resource products --duration 1h

10. The Agent Infrastructure Stack

BOTCHA positions itself alongside other emerging agent protocols:

MCP gives agents access to tools and data. A2A enables multi-agent coordination. BOTCHA provides the full identity layer: proof of AI, cryptographic identity (TAP), capability attestation, portable credentials (DID/VC), DNS-based names (ANS), enterprise auth chains (OIDC-A), and payment-gated access (x402).

Without an identity layer, the other layers have a trust gap. MCP can give an agent access to a database, but who authorized it? A2A can let agents delegate tasks, but can you trust the delegate? BOTCHA closes this gap — at every layer of the stack.

11. Use Cases

E-commerce agent verification

A shopping agent registers with browse, compare, and purchase capabilities. It creates sessions scoped to specific actions. The retailer verifies identity, checks capabilities, and maintains a full audit trail of which agent made each purchase, when, and on behalf of whom.

API access control

An API provider adds BOTCHA middleware to protected endpoints. Legitimate agents solve the speed challenge; scrapers pretending to be AI cannot. The provider gets rate limiting, solve-time analytics, and agent identification — without requiring API keys.

Multi-agent systems

A coordinator agent delegates tasks to sub-agents, each registered with scoped capabilities. The coordinator can verify sub-agent actions via TAP sessions. Capabilities are bounded at the protocol level.

Compliance and auditing

Financial services APIs use TAP's audit logging to record every agent interaction. Each request includes agent ID, intent, user context, and timestamp. Trust levels enable graduated access to sensitive endpoints.

12. Roadmap

Shipped (v0.22.0)

Planned