Give your agent a passport.
To every bot gate, your agent is just automation. AgentDraft gives it a signed identity that travels: human-backed receipts, a signed A2A card, Web Bot Auth request signatures, and an MCP client identity — all from one Ed25519 key.
Team+ · Ed25519 · RFC 9421 · A2A 1.0 · MCP CIMD
Updated
The wall
A legitimate agent submits a contact form from a cloud container. It solves the proof-of-work, sends a clean message, and still gets blocked — because the gate sees automation, not the human on whose behalf the agent is acting.
The fix is not to weaken the gate. It is to let the gate ask a better question: who is this agent, and who stands behind it? AgentDraft answers that with a key the site can verify without calling AgentDraft.
Same content. Same client. One Ed25519 signature.
Four proofs, one key
The same key hierarchy answers four different questions. Each proof is independently verifiable; none requires a live AgentDraft call.
A human approved this exact payload.
A Team+ approval or consent confirmation mints an Ed25519 receipt bound to evidence_sha256, the reviewer, the agent, and one audience. Verify it offline against the public JWKS.
approval_receipt · evidence_sha256Receipt contract →This agent is acting for that human.
POST /v1/identity/exchange trades the agent's key for a shorter-lived token narrowed to one audience and a subset of scopes. The human is sub; the agent is the RFC 8693 act claim.
sub = human · act.sub = agentExchange contract →This agent is discoverable and signed.
The A2A 1.0 card is JCS-canonicalized and carries a detached Ed25519 JWS. A caller can verify the provider before it sends a task, then use SendMessage / GetTask.
/.well-known/agent-card.jsonA2A spec →This request came from this agent.
Each agent publishes a per-agent RFC 9421 directory. Sign an outbound request with the one-time key; a verifier fetches the directory named in Signature-Agent. The same key backs the MCP Client ID Metadata Document.
Signature-Agent · private_key_jwtSigning guide →How it works
Mint one key
Dashboard → Agents → Signing. The private JWK is shown once and never stored. The public half appears in the agent's directory immediately.
Sign the request
sign_request() signs the method, authority, path, Signature-Agent, and Content-Digest. Send the four headers; no AgentDraft call is on the request path.
Let the gate verify
The verifier fetches the per-agent directory over TLS, checks the Ed25519 signature, and then runs its own content classifier. Identity does not buy a spam pass.
from agentdraft import agent_signature_fields, sign_request
headers = sign_request(
method="POST",
url="https://forms.example.com/contact",
private_jwk=private_jwk, # shown once in the dashboard
agent_id="agt_01...",
body=body,
)
# Send the four headers with the request. If the site uses SiftFy,
# forward them to siteverify as agent_signature:
agent_signature = agent_signature_fields(
headers, method="POST", authority="forms.example.com", path="/contact"
)What it does not do
Skip a bot block on an action whose policy opts in, while the site still runs its denylist, reputation, velocity, and content classifier.
Buy a clean spam score, bypass a denylist, or hide the content. The live signed response kept bot.score 90 and returned spam_probability 0.0166.
The live evidence
Captured 2026-10-25 · throwaway enforce site · origin agentdraft.io · the test site was deleted after the run
Included on Team+
The identity layer is not a separate SKU.
Team ($25/mo) and above include signed approval and consent receipts, scoped delegation tokens, per-agent Web Bot Auth keys, and MCP CIMD. Free and Individual keep the standard JSON status and the public A2A card.
- One Ed25519 hierarchy; no second key store
- Private JWK returned once, never stored
- Public JWKS and A2A card on every tier
Questions
What is Web Bot Auth?
Web Bot Auth is an IETF profile built on RFC 9421 HTTP Message Signatures. A bot publishes a public key directory and signs its outbound requests with the matching private key. A website can then verify which operator sent the request instead of guessing from a User-Agent string.
What is MCP Client ID Metadata?
CIMD replaces dynamic client registration for MCP OAuth clients. The client_id is an HTTPS URL that serves a metadata document. AgentDraft publishes one per agent at /v1/agents/{id}/oauth-client.json, with private_key_jwt and the agent's signing directory as jwks_uri.
Does a signed agent bypass spam filtering?
No. A verified agent can skip the bot block only when the site's action policy opts in. Denylist, reputation, velocity, and the content classifier still run. In the live run the signed request was allowed with verified_agent_clean while the classifier still returned spam_probability 0.0166.
Which tier includes agent identity?
Signed receipts, delegation tokens, Web Bot Auth signing keys, and MCP CIMD are on Team and above. The public JWKS and the signed A2A 1.0 card are available to every tier. SiftFy gates its verified-agent policy on its Pro plan.
Where is the private key stored?
It is not. AgentDraft generates the Ed25519 key pair, returns the private JWK once, and stores only the public half. Rotating the signing key replaces the public key immediately and invalidates the old kid.