api.fdkey.com
Captcha for AI agents.
FDKEY is the inverse CAPTCHA — AI agent verification middleware for MCP servers and HTTPS APIs. It admits capable LLMs and rejects humans, scripts, and weak models. Every agent that takes the challenge makes the next one harder to fake. One-line install, mark the tools you want gated, done. Open source · MIT.
- ✓ MCP server middleware + HTTPS API SDK
- ✓ Free for 3,000 verifications / month — bigger limits on request
- ✓ Open source · MIT · multi-region routing
Capability gating, not bot-blocking.
Eight shapes where verifying the caller is a capable LLM creates real value. Click any to expand.
01
AI-only platforms
Where the members are AI agents, not the humans behind them.
AI-only platforms
Where the members are AI agents, not the humans behind them.
Building a space where AI agents interact, share, or compete? FDKEY makes sure only the agents get in. Admission control for the agent web.
MoltBook-style agent social networks. Multi-agent simulation environments. RLHF preference markets. Agent-judge services. Anywhere humans would dilute the signal, the gate keeps the data clean — and the capability score doubles as a quality filter so you can admit only frontier models if you want.
02
Data for AI, not for scrapers
Reach the agents that drive your traffic; keep the scraper farms out.
Data for AI, not for scrapers
Reach the agents that drive your traffic; keep the scraper farms out.
Have data worth sharing with AI agents but worth protecting from scrapers? robots.txt with teeth for the agent era — your content reaches the agents, the scrapers stay out.
The post-Google SEO problem in one line. Stack Overflow, academic publishers, Q&A archives, specialised wikis, knowledge bases — your content needs to be reachable by ChatGPT, Claude, and Gemini because that’s where your users now are. You just don’t want a script with a residential proxy pool downloading your corpus to train a competitor or rehost.
03
Agent-to-agent marketplaces
Certify cognitive class without certifying identity.
Agent-to-agent marketplaces
Certify cognitive class without certifying identity.
Running a marketplace where agents bid on tasks? You need to know the bidder is an actual capable agent, not a script wearing a badge. FDKEY is the certification layer.
AgentHub-style platforms, agent freelancer networks, tool-exchange marketplaces. A legal-research agent gets to prove it isn’t a fine-tuned 7B cosplaying as a lawyer. Every agent verifies for itself — your marketplace knows the bidder solved the puzzle on this connection, not by trusting a token someone else handed them.
04
Gating dangerous tools
Filter cognitively incoherent callers from your destructive endpoints.
Gating dangerous tools
Filter cognitively incoherent callers from your destructive endpoints.
Your dropTable, terraform_apply, or refundOrder should only run when the caller can actually reason about consequences. FDKEY is the action-boundary checkpoint that makes sure of that.
The failure mode you’re defending against isn’t malice — it’s confident incompetence. A quantized 7B running in a loop misreads context and torches your prod. The puzzle gate is a sanity check that the caller has the cognitive coherence to have understood what it’s about to do — which means prompt-injected callers fail the gate too, since their coherence has already collapsed.
05
Denser payloads for agents
Serve denser raw payloads to verified agents; standard JSON to everyone else.
Denser payloads for agents
Serve denser raw payloads to verified agents; standard JSON to everyone else.
Your knowledge API serves human-readable formatted JSON because you don’t know who’s calling. If you knew it was a capable LLM, you could ship a way denser format and save bandwidth on both sides.
FactSet, Bloomberg, PubMed, CourtListener-class endpoints. Verified agents get application/agent+json — a massive, densely-structured graph with no formatting, no pagination hints, no redundant context, no disclaimers. Cheaper to serve, higher information density per token consumed.
06
Pricing by who’s calling
Genuinely cheaper agent-tier pricing without humans laundering through it.
Pricing by who’s calling
Genuinely cheaper agent-tier pricing without humans laundering through it.
Agents and humans cost you wildly different amounts to serve. With FDKEY you can finally price them differently — without humans laundering through the cheaper plan.
Agent traffic is bursty, parallel, schema-tolerant, near-zero support load. Human traffic generates tickets, asks for refunds, eats your time. A verified-agent flag lets you offer real agent-tier pricing as a separate product. Wholesale-vs-retail for the agent economy.
07
Agent-only payment rails
On agent-economy infrastructure, a human caller usually means fraud.
Agent-only payment rails
On agent-economy infrastructure, a human caller usually means fraud.
Building autonomous payment rails, procurement APIs, or agent stablecoin wallets? On those endpoints, a human hand-crafting a call almost always means something is wrong.
Agent stablecoin wallets, x402-style payment rails, agent-to-agent SaaS procurement, autonomous cloud-capacity buying. The prior is overwhelmingly that the caller should be an agent — promotion gaming, pricing-API exploration, or a developer testing in prod is the alternative. Agent or fraud collapses into one check, and every verified call leaves a signed audit record in your server logs.
08
Dual-use data, AI-only
Rent the frontier labs’ safety training as moderation infrastructure.
Dual-use data, AI-only
Rent the frontier labs’ safety training as moderation infrastructure.
Sitting on data that’s safe inside a capable LLM’s reasoning loop but dangerous in a human’s hand? FDKEY gives you a third option beyond credentialed access only and let everyone in and hope.
Drug interaction databases, dosing references, chemistry corpora, pathogen sequence data, raw medical literature. Serve any agent on the assumption that frontier RLHF will soft-pedal, contextualise, refuse — effectively renting the labs’ safety training as your moderation infrastructure.
Today's edge cases — agent payment rails, AI-only platforms, agent marketplaces — become tomorrow's defaults.
Drop-in middleware. Real diff.
If your MCP server is 30 lines, this is 4 of them. The wrapped server is the same McpServer instance — registered tools, transports, and lifecycle hooks all keep working.
npm install @fdkey/mcp
- Zero config — discovers nearest VPS automatically
- 0 added latency for unverified tool listings
- Fails open on FDKEY outage (configurable)
Full SDK docs and config reference on GitHub → github.com/fdkey/sdks
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { withFdkey } from '@fdkey/mcp';
const raw = new McpServer({ name: 'banking-tools' });
// register your tools as usual…
raw.tool('transferFunds', schema, async (args) => { /* … */ });
export const server = withFdkey(raw, {
apiKey: process.env.FDKEY_API_KEY!,
protect: {
transferFunds: { policy: 'each_call' },
listAccounts: { policy: 'once_per_session' },
},
});Install. Gate. Verified caller.
FDKEY exploits a simple asymmetry: capable LLMs produce certain semantic answers with statistical regularity, and humans, scripts, and weak models cannot. We control the puzzles. Model class falls out of the score.
-
01
Install on your server
Drop the SDK into whichever surface you're securing — MCP server, HTTPS API, or future surfaces. Existing tool definitions, transports, and authentication all keep working untouched.
-
02
Gate sensitive calls or registrations
Mark which calls require verification:
each_callfor irreversible actions,once_per_sessionfor signup-style flows, or{ type: 'every_minutes', minutes: N }for a middle ground. Works on tool calls, signups, agent-only admission — any capable-caller-required endpoint. -
03
Caller solves. Connection unlocks.
The caller fetches six puzzles, submits answers, and FDKEY scores against LLM-class distributions. The agent never holds the JWT — it stays inside your server as a verification artifact; the connection itself is what's verified. Every agent verifies for itself; verification doesn't transfer between agents.
Paste this prompt into your AI agent.
Watch a real model take the FDKEY challenge from inside its own MCP client. Or scroll down for the human version.
Can you beat FDKEY as a human?
15 seconds. 3 random puzzles from the live bank. Have a try.
Ready when you are.
Three random puzzles from FDKEY's live bank. Type your answers — clipboard is locked.
Tip: you can submit early. The clock won't.
Built for production from day one.
Drop-in MCP middleware
One withFdkey() wrapper. No tool re-registration, no schema changes, no transport rework.
Capability scoring
A score lands on every verified caller. Admit frontier models, soft-fail weak ones, reject humans and scripts entirely.
Statistical scoring
No fixed answer key. Submissions are scored against pre-computed LLM-class distributions. Memorization-resistant.
Multi-region routing
SDK fetches the live IP list from cdn.fdkey.com, probes each, and pins the lowest-latency edge. Auto-failover on 5xx.
Cryptographic receipts
Every verification produces an Ed25519 JWT with the capability score and puzzle summary, delivered server-to-server to your SDK. Your server verifies it offline against the published JWKS and stores the decoded score, tier, and timestamp in its own session — perfect for an audit trail.
Privacy by design
FDKEY never sees prompts, tool args, tool results, or end-user identity. Only verification metadata crosses the boundary.
The more it gets used, the harder it gets to spoof.
FDKEY's puzzle bank is finite at any moment, but the answer-distribution map sharpens with every challenge attempt. A new MCP server adopting FDKEY today benefits from every distribution refined by every deployment that came before. The free tier is not a loss leader. It's the strategy.
Network effects on the verifier side
Self-hosted CAPTCHAs cannot pool data. A private deployment's distribution map never sharpens beyond its own traffic. The shared FDKEY service is, by construction, harder to spoof than any private equivalent — and that gap widens every day.
Free tier is the data flywheel
Every challenge attempt updates the per-model-class distribution for the exact puzzle the agent saw. Free attempts are the input that sharpens production scoring. We give away verifications because they are the data, not despite the fact.
Wrap one tool. Stay open everywhere else.
You don't have to gate everything to participate. Wrap one experimental tool — a write action, a billing query, a high-stakes mutation — and let the rest of your MCP server stay public. The one tool you gate becomes part of a network of agent-aware contracts, scoped to model capability rather than mere identity.
Weak-model fingerprints stay stable
As frontier models get better, the failure tails of weaker models stay structurally identifiable. FDKEY can detect a fine-tuned 3B trying to look like GPT-4-class output — and that detection is something we keep getting better at, indefinitely, off the back of free-tier traffic.
The SDK is yours. Help us improve it.
Four MIT-licensed SDKs live at github.com/fdkey/sdks: @fdkey/mcp (TypeScript MCP middleware), @fdkey/http (TypeScript HTTPS-API middleware), fdkey on PyPI (Python / FastMCP), and fdkey on crates.io (Rust verification primitives). I deliberately open-source everything on the integrator side because the moat is the puzzle bank and the cross-deployment distribution map — not the wrapper code. If you build agent-facing servers, I want your contributions.
Star the repo
Track releases, file issues, and read the SDK source. github.com/fdkey/sdks
File an issue
Found a bug, want a feature, or have a question about integration patterns? Open an issue and we read every one.
Report or request →Send a PR
Especially welcome: new SDK languages (Go, Elixir, Java), framework adapters (Koa, Hapi, aiohttp, Tower), better error messages, and docs corrections.
Contribute →MIT licensed
Use the SDK in commercial products, fork it, modify it, embed it. Attribution appreciated, never required.
Read the license →Same primitive. Inverted target.
- Targets
- Humans
- Passes
- ✓ Humans
- Blocks
- ✗ Bots, automation
- Mechanism
- Behavior + risk score
- Surface
- HTML widget
- Output
- Yes / no
- Targets
- AI agents
- Passes
- ✓ Capable LLMs
- Blocks
- ✗ Humans, scripts, weak models
- Mechanism
- Semantic puzzles · LLM-distribution scoring
- Surface
- MCP middleware · JWT receipt
- Output
- Capability score on every verified caller
Same architectural primitive: a server-side challenge with a verifier-only scoring function. We just flipped which side of the LLM divide gets the green light.
Same service for everyone. Just pick a limit.
Every plan ships the full FDKEY service — same SDK, same puzzle bank, same JWT receipts, same SLAs. The only thing that changes between plans is how many verifications fit. Verifications, not API calls — one long-lived MCP session running hundreds of tools costs one verification.
Free
- Full FDKEY service
- All 6 puzzle types · production bank
- JWT receipts · JWKS rotation
- Multi-region routing · MIT SDK
Project
- Free for normal scaling
- If you need a dedicated VPS for your traffic, just cover the server cost — no markup
- Same full service, bigger monthly limit
- Send a note about your use case
- Cooperate on the SDK
The questions everyone asks first.
Wait — your customers are AI agents?
The integrator is a human dev shipping an MCP server. The caller is an AI agent. Anyone exposing high-stakes tools (banking, mail, infra, deploy) needs to know whether the caller is a model that can reason, vs a script faking the protocol, vs a human poking around. FDKEY answers that at the protocol layer, not the application layer.
Why not just check if it's an LLM via some HTTP signal?
There isn't one. Bearer tokens, User-Agents, IPs — all spoofable, none model-aware. The only reliable signal is "did the caller produce the kind of output a capable LLM produces on this puzzle?" That's the FDKEY question.
Can a script pre-cache answers?
No. Puzzle questions are generated continuously offline against an infinite question space; runtime answers are scored statistically against LLM-class distributions, not against a fixed key. Even if you saw last week's questions, this week's are different — and the scoring is statistical, not lookup.
What about jailbroken or fine-tuned weak models?
The score catches it. A weak model produces weak distributions on the harder puzzle types regardless of jailbreak — the score lands too low to admit. Frontier models pass cleanly; mid-capability models get a middle score, and you decide where to draw the line in your own gating logic.
Does this work for anything other than MCP servers?
Yes. MCP server middleware and HTTPS API gating (HTTP 402 + challenge) ship today. An HTML "Continue as AI agent" widget for forms is on the roadmap. Same scoring backend across all surfaces.
What does FDKEY see about my users?
Nothing. We never receive prompts, tool arguments, tool results, or end-user identity. Only puzzle attempts, latency, and integrator metadata (which client, which SDK version) cross the boundary. By design we cannot deanonymize your users.
What happens if FDKEY goes down?
The SDK fails open by default — your endpoints keep serving traffic, just without the FDKEY verification context. FDKEY is verification, not gating; an outage on my side shouldn't brick your workflow. Flip onVpsError: 'block' if you'd rather drop unverified callers during an outage. Multi-region routing means a single VPS outage doesn't take you down either way.
What's the latency hit?
Verification is per-session, not per-call — a long-lived MCP connection pays the cost once and runs hundreds of tools afterwards. The agent has up to 45 seconds to solve the puzzles; the network roundtrip itself is dwarfed by that. Once the connection is verified, every subsequent tool call goes through with no FDKEY-side latency at all.
How is FDKEY different from a regular MCP server API key?
An API key authenticates the integrator (the human deploying the MCP server). FDKEY authenticates the caller — the AI agent making the tool call. A leaked API key gives a script identical access to a frontier model; FDKEY can tell them apart at the protocol layer and gate accordingly. The two are complementary: keep your API key for the integrator, add FDKEY for the agent.
Does FDKEY work for HTTPS APIs, not just MCP servers?
Yes. The HTTPS API SDK returns HTTP 402 with the challenge embedded in the response body. The caller solves the puzzles and posts the answers back to your server (not to FDKEY directly — your server holds the API key). The SDK forwards to FDKEY server-to-server, verifies the issued JWT offline, and marks the agent's session verified — using a normal session cookie. The agent never holds the JWT; it just keeps a session id like any other web client. Same scoring backend as the MCP middleware. If you have a REST or GraphQL API you want to expose to AI agents but not to humans or scripts, the same primitives apply.
Is FDKEY a reCAPTCHA alternative for AI agent traffic?
Sort of — for the inverse use case. reCAPTCHA verifies that a caller is human; FDKEY verifies that a caller is an AI agent. If your product wants to admit only LLM-driven agents (an MCP server with sensitive tools, an API for AI workflow automation, a tool marketplace gated to agent integrators), FDKEY is the closest analogue.
Can I self-host FDKEY?
No. The whole reason the puzzle gate works is that the answer-distribution map sharpens with every challenge attempt across every integrator — that's the moat. A self-hosted instance would only see its own traffic, the bank wouldn't sharpen, and exposing the scoring service privately would also expose the answer keys for any operator with DB access. So FDKEY is shared-service only, by design.
Is the SDK code open source?
Yes — all of it, MIT licensed. Four SDKs live at github.com/fdkey/sdks: @fdkey/mcp (npm), @fdkey/http (npm), fdkey (PyPI), fdkey (crates.io). The wrapper is open because the moat is the puzzle bank and the cross-deployment distribution map, not the integration code. Forks are welcome.