Try it

The trust bootstrap problem

AI agents increasingly act on behalf of real organizations — reading documentation, querying APIs, filing support tickets, completing tasks end-to-end. But there's no universal way for a server to know whether an incoming request is from a legitimate company's agent or from someone trying to impersonate one.

Today's answers are all flawed: User-Agent strings are trivially spoofed. IP allowlists are fragile and don't scale. Per-service API key issuance is slow and creates operational drag.

whitelist.dev proposes a simpler model. Combine two ideas:

1. Cryptographic identity. Agents sign requests with Ed25519 using Web Bot Auth, publishing their public key at a well-known URL on their operator's domain.
2. A curated allowlist of likely-legitimate domains. If an agent signs from openai.com or stripe.com or any of 20,850 others, servers can grant trust immediately without a per-service registration dance.

The result: any server can answer "should I trust this agent?" with a single lookup, and agent operators only need to manage one identity — their domain.

For agent operators

If you run an agent on a company domain, you can become verifiable in an afternoon. Follow the guide:

→ How to Implement Web Bot Auth (markdown, also on GitHub)

TL;DR: generate one Ed25519 key pair, host a JWKS directory on your domain, and attach three headers to every request.

For service providers

If you operate a service receiving agent traffic, you can use whitelist.dev to make trust decisions:

• Verify signed requests: Check Web Bot Auth signatures at your edge, then look up the signing domain here
• Signup gating: Auto-approve corporate email signups from domains on the list
• Rate limiting: Give verified agents & organizations higher API quotas
• Lead scoring: Recognize enterprise prospects from their email domain

Quickstart

Simple lookup (unauthenticated)

# 1 request per minute limit
curl https://whitelist.dev/lookup?domain=stripe.com

With API token (1000 req / 10s)

curl https://whitelist.dev/lookup?domain=stripe.com \
  -H "Authorization: Bearer wl_your_token_here"

Response

{
  "domain": "stripe.com",
  "trusted": true,
  "company": "Stripe",
  "types": ["email", "website"]
}

Rate Limits

Every request returns X-RateLimit-* headers. Upgrade tiers by authenticating:

→ Sign up for an API token

Endpoints

• GET /lookup?domain=X — Single domain check
• GET /verify — Verify signed agent request + whitelist check (returns VALID, INVALID, EXPIRED, etc.)
• GET /inspect — Free diagnostic endpoint. Returns a verbose verification report with hints for debugging your signed requests.
• GET /how-to-web-bot-auth.md — Implementation guide for agents

Debug your signing implementation

If you're implementing Web Bot Auth and your signatures aren't verifying, use /inspect. It's free, doesn't require auth, and returns the exact signature base bytes the server reconstructed, all parsed parameters, the key it matched, and specific hints when things fail:

curl https://whitelist.dev/inspect \
  -H 'Signature-Agent: "https://your-domain.com"' \
  -H 'Signature-Input: sig1=(...)' \
  -H 'Signature: sig1=:...:'

Rate limited to 10 requests per minute per IP. Great for local development — compare the signatureBase field in the response with what your code is signing to spot mismatches.

Specs & implementations

• RFC 9421 — HTTP Message Signatures
• Web Bot Auth architecture draft
• HTTP Message Signatures Directory draft
• Cloudflare docs + announcement post
• Libraries: Rust, TypeScript, Python (this repo)

Data sources

Every domain is MX-verified (actual mail server exists). Sources include Forbes Global 2000 parent companies and subsidiaries, Y Combinator companies (all batches), and 170+ top VC firm portfolio pages. Free email providers, parked domains, and disposable email services are excluded.