Same key. Two layers.

What does Web Bot Auth specify, and why did Google Cloud Fraud Defense pick it up?

Web Bot Auth, draft-meunier-web-bot-auth-architecture-05, defines how a bot or agent signs an outbound HTTP request so an origin can verify it without a CAPTCHA round trip. The signing primitive is RFC 9421 HTTP Message Signatures. The required algorithms are Ed25519 and RSA-PSS with SHA-512. HMAC is prohibited because non-repudiation matters for downstream evidence.

Three headers ride along on every signed request. A Signature header carrying the signature itself, a Signature-Input header naming the signed components, and an optional Signature-Agent header pointing at the issuer's key directory. Google Cloud Fraud Defense reads those three headers, looks up the key, and either trusts the request or sends it through the rest of the bot defense pipeline.

How are AgentLair credentials compatible with Web Bot Auth today?

AgentLair has shipped Ed25519 keys for every registered agent since launch. The thumbprint on each agent key is the same SHA-256 thumbprint Web Bot Auth expects in its keyid parameter. The key directory Web Bot Auth wants exists at /.well-known/jwks.json, the same JWKS endpoint that powers Agent Authentication Tokens.

The signing surface is the addition. As of today, @agentlair/openai-agents 0.2.0 and @agentlair/langchain 0.3.0 ship signRequest() and computeJwkThumbprint() helpers that produce RFC 9421 signatures the AgentLair worker verifies on the L3 audit endpoint. 58 + 56 SDK tests pass. The signature roundtrip is real.

The compatibility table, claim by claim

Eighty percent of the compatibility surface is the same Ed25519 keypair AgentLair already issues. The remaining twenty percent is what Web Bot Auth leaves out on purpose.

What does Web Bot Auth not say?

Web Bot Auth says nothing about who controls the key. Nothing about what the agent committed to before the request fired. Nothing about whether a human principal is on the other end of the credential, or whether that principal has any skin in the game. The draft is deliberately scoped to the signing event. That scoping is correct for an IETF wire protocol.

It is also the gap a Fraud Defense origin still has to close on its own. An origin that accepts a Web Bot Auth signature has confirmed the request was signed by a known key. Nothing more.

How AgentLair adds the commitment chain on the same key

An AgentLair agent key signs three artifacts during a session, all anchored to the same Ed25519 keypair. The Behavioral Commitment Credential at session start, declaring the scope the agent has agreed to: spend cap, merchant whitelist, time window, principal identity. The L3 audit chain entries posted as the agent works, each with a hash linking it to the previous entry. The Web Bot Auth signature on every outbound HTTP request, verifiable by any origin with the key directory.

One key, three artifacts, one accountable principal. The Fraud Defense origin reads the signature. The disputes counterparty reads the audit chain. The compliance examiner reads the BCC. None of them have to trust the operator's logs to do their job.

Where Web Bot Auth, SPIFFE, and AgentLair sit in the same stack

Google Cloud Fraud Defense names two standards in the same announcement, which is rare. SPIFFE handles workload identity inside infrastructure. The SVID document confirms the process running the agent is the workload it claims to be. Web Bot Auth handles agent identity on the wire. The signed HTTP request confirms the agent in front of the origin holds a valid key. AgentLair handles the accountability layer above both.

The credential confirms a named human principal accepted a defined scope before the agent acted, and the audit chain confirms the agent stayed inside that scope. Three standards, three jobs. Composable, not competing. AgentLair has no opinion on whether the workload runs on Cloud Run, Lambda, or a developer's laptop.

A worked example: a signed request that arrives at a Fraud Defense origin

A retail agent built on the OpenAI Agents SDK is delegated to buy a 95-USD leather bag, capped to one merchant, valid for 30 minutes. At session start, the SDK calls AgentLair to issue a BCC pinning that scope, then opens an L3 audit session. When the agent calls the merchant's checkout endpoint, signRequest() produces a Web Bot Auth signature using the same Ed25519 key the BCC was signed with.

The merchant's edge runs Google Cloud Fraud Defense. Fraud Defense pulls the keyid out of Signature-Input, fetches the JWK from agentlair.dev, verifies the signature, and lets the request through. The merchant reads a normal request body. Behind the scenes, the audit chain logs the call. If the buyer disputes the charge thirty days later, the merchant produces three artifacts the issuer can verify without phoning AgentLair. The BCC for scope. The audit chain for the action. The signed request itself, anchored to the same key. Same shape as the dispute resolution flow, with the wire-layer signature pulled in.

What this looks like for a team building today

Pull @agentlair/openai-agents 0.2.0 or @agentlair/langchain 0.3.0. Wire signRequest() into your agent's HTTP transport. Issue a BCC at session start with the scope you want to commit to. Post audit events as your tools fire.

The same Ed25519 keypair that gets your agent past Google Cloud Fraud Defense is the keypair that anchors the commitment chain. No new crypto. No second authority. One signing identity for the wire and the chain. The wire layer is being standardized this year. The chain layer is what the dispute team and the compliance team end up reading next.