VerifiedProxyProve which company sent an AI agent — and what it asked for.
Commissioned Agent Records is a proposed open standard built on Web Bot Auth. It lets any platform confirm, with certainty, that a named company commissioned an agent and that the agent made this exact request — backed by an independent, tamper-evident record.
- Built on Web Bot Auth
- Free to implement
- Any company can run an operator
Animated demo. Sam at Halden & Co asks the company’s purchasing assistant to order £4,200 of paper. The agent signs the request, VerifiedProxy records a salted hash of it before it leaves, and Supplies Co checks the agent’s identity, Halden’s commission and the record, then accepts order SUP-88213. Sam then asks for £12,000 of desks. VerifiedProxy refuses to record it because it is over Halden’s £10,000 per-order limit, so the request is never sent.
Why it’s needed
Identity alone can’t tell you who is accountable.
AI agents now place orders, book travel and pull financial data on behalf of companies. Web Bot Auth — being standardised at the IETF — lets an agent prove which key signed a request. A platform needs to know more than that.
Which key signed this request?
An HTTP message signature, checked against the agent’s published key.
Answered today by Web Bot AuthWhich company commissioned this agent, and for what?
Who is accountable, what the agent may do, where, and up to how much.
Added by the commissionDid it really make this request — and did anyone independent see it?
Evidence of the exact request that holds up in a dispute.
Added by the recordThe idea
Three layers, each building on the one below.
Identity already exists. The commission and the record are what this standard adds — and the layers are separable, so a platform benefits from whichever it checks.
How it works
How one request is verified.
Before any request, the company publishes a commission on its own domain naming the agent’s key, its scope, an expiry date and the operator that holds its records.
Swipe to see the whole diagram →
- Signed request. The agent signs with Web Bot Auth and puts a pointer to its commission inside the signed headers, so it can’t be swapped.
- Record. Before the request leaves, an independent operator records a salted hash of it — never its path or body.
- Send. The request reaches the platform carrying the agent’s signature.
- Identity check. Exactly as for any Web Bot Auth agent.
- Commission check. Fetched from the company’s own domain, signed with its key, naming this agent, within scope.
- Record check. One call to the operator named in the company’s DNS, returning a proof the platform verifies itself.
What the spec defines
Four small parts, built from standards you already use.
HTTP Message Signatures, JWS, DNS and a Certificate Transparency-style Merkle log. All free to implement; none requires VerifiedProxy.
The commission
A small JSON document, signed with the company’s domain key and served from its own domain. Remove it and it’s withdrawn.
{
"commissioner": "halden.example",
"agent_keys": ["kq3V…9xA"],
"scope": {
"sites": ["supplies.example"],
"actions": ["create_order"],
"limit": { "currency": "GBP",
"per_order": 10000, "per_day": 25000 }
},
"valid_until": "2026-12-31T23:59:59Z",
"record_operators": ["verifiedproxy.com"],
"record_level": 2
}Discovery
One DNS record says which operators may vouch for the company and where its signing keys live. An operator that isn’t listed can’t impersonate it.
_agent-commission.halden.example. TXT
"v=ACR1; ops=verifiedproxy.com;
keys=https://halden.example/
.well-known/acr-keys.json"The record
Written before the request leaves, into an append-only Merkle log with signed tree heads and independent timestamps. Three levels, chosen per commission:
| Level | Recorded |
|---|---|
| 1 · Destination | Agent, site and time |
| 2 · Commitment | A salted hash of the signed request — the default. Proves the exact request; the operator never receives its path or body. |
| 3 · Full content | The full request, encrypted to the company’s own key |
Verification
One API call returns verified, unknown, out of scope or revoked — plus an inclusion proof the platform checks against the public log.
POST /acr/v1/verify
{ "commission", "key_id", "nonce", "request_hash" }
→ { "status": "verified", "scope": …,
"proof": …, "tree_head": … }Trust model
Nobody has to be trusted blindly — including us.
The design assumes any party might misbehave, and makes each kind of misbehaviour impossible or detectable.
The company’s domain is the anchor
A commission only counts if it’s served from the company’s domain and signed with a key its DNS points to. Forged commissions and fake operators fail.
The operator is a witness, not an authority
Signed tree heads, inclusion proofs, consistency proofs, RFC 3161 timestamps and independent monitors make altering or backdating a record detectable.
Keys and requests can’t be reused
Short-lived keys, a nonce and expiry on every signature, replay detection and real-time revocation — revoke a commission and the next request is refused.
Privacy by default
The operator sees the site, time and declared action — never the path or body, and a per-request salt stops it testing guesses. One commission per platform, with IDs nobody can guess, keeps trading partners private.
Skipping the record only hurts the agent
A signed request with no record verifies as unknown. There’s no advantage in going around it.
Limits that add up
Per-order limits plus daily and lifetime caps the operator enforces across every order, atomically — so fifty orders just under the limit don’t slip through.
Open by design
One protocol. Many independent operators.
Like DMARC for email: an open standard published in DNS, with a market of operators around it. Companies choose their operator; platforms discover it automatically.
Swipe to see the whole diagram →
- Platforms never sign up with an operator. They read the company’s DNS record and call the operator it names. A new operator works with every platform from day one.
- Companies choose — and can switch. List one operator or several; moving is a DNS change.
- Anyone can run one. The operator’s job is fully specified. Self-operated records are allowed, and marked as such.
- Platforms set their own bar. For example, accepting only certified operators.
The question a platform asks isn’t “do they use VerifiedProxy?” It’s “which company is accountable, and is there an independent witness?”
Adopting it
Value at every stage of adoption.
Platforms already verifying Web Bot Auth get identity with no new work. Companies get an audit trail even before any platform checks. Every platform that checks records makes commissioned agents more welcome everywhere.
Companies running agents
- Publish a domain key and one DNS record
- Sign a commission per agent
- Choose an operator
Platforms
- Verify Web Bot Auth as you may already do
- Check the commission and scope
- One call for the record, and check the proof
Agent builders
- Add
Agent-Commissionto signed headers - Declare actions with
Agent-Intent - Record before sending
Operators
- Implement the record and verify APIs
- Run an RFC 9162 log
- Join the certified-operator programme
AI providers
Agents run in a provider’s cloud work too.
A commission vouches for everyone who can sign with its keys, so a key shared by all of a provider’s customers can’t be commissioned. Instead the provider gives each customer its own key, marked with the company it acts for (acr_principal), and writes the records itself. The identity layer shows the provider; the commission shows the company accountable.
VerifiedProxy
We’re building the first operator.
VerifiedProxy wrote this draft and runs the first implementation of it. The standard is free; operating it well is our business.
Our implementation covers all three record levels with a Certificate Transparency-style log; a local proxy that signs every request, records it first and blocks anything out of scope — opening HTTPS on the agent’s own machine, so we never decrypt traffic; an SDK for agents that call platforms directly; a reference verifier for platforms; and a governance console with instant revocation.
We aim to win on what an open market rewards: neutrality — we’re neither the AI provider nor the platform — and evidence-grade records. Once other operators exist, we intend to hand the certification programme to a neutral foundation.
Status
Draft 0 — and we want your input.
This is an early draft, published to start a conversation. We intend to bring it to the IETF Web Bot Auth working group, and we want it shaped by the people who would use it before then.
Where it’s going
- Draft 0 publishedSpecification and working implementation, open for comment.
- Community feedbackPlatforms, companies running agents, agent providers and would-be operators.
- IETF Web Bot Auth working groupBrought to the group as an Internet-Draft.
- Open reference implementationsVerifier and agent SDK published for anyone to use.
- More operators, certificationA second operator, then a certified-operator programme handed to a neutral foundation.
Open questions
- The name. “Commissioned Agent Records” and its headers are working names.
- One-key provider delegation. A single provider key plus a signed customer-account header, as an alternative to a key per customer.
- People, not just companies. Agent providers commissioning on a user’s behalf, with a different pseudonymous ID per platform.
- Declared actions. Whether
Agent-Intentbelongs here, and whether actions need a shared vocabulary. - Key directories. Self-signatures for multi-tenant hosts, and rotating short-lived keys.
- Monitoring. Tree-head gossip and how platforms report inconsistencies.
- Certification. What certified operators must meet, and who runs the programme.
Help shape the standard.
Read the draft, try it against your platform or agents, and tell us what breaks, what’s missing and what you’d change. We especially want to hear from platforms, agent providers and anyone who would run an operator.
25 pages · how it works, the trust model and the full Draft 0 specification