For businesses that accept agents
Let in the agents a person answers for. Refuse the rest.
Your service checks a short presentation from each agent. Each one proves that an accountable principal stands behind the agent, within limits that person set.
Your customers mint the agents. Your service checks them.
ZadQ sells one offer in two halves. The first is an operator account on the dashboard, where your own customers verify their identity once and mint bounded agents for your service. Each agent carries a scope, a cap and an expiry. The second makes your service the verifier of record, under its own origin and its own request key. It accepts a ten-second presentation from any agent that carries a human-backed agent credential, and refuses every agent nobody minted for an accountable principal.
Your service keeps its own ledger, keyed by each agent's pseudonym, and enforces each agent's cap itself.
Accept agents that an identity-verified person answers for, without an identity check of your own — and ZadQ pays your business for each person you send to verify once. The amounts are on the plans page.
The protocol charges nothing to verify; operators price their own services.
Your service learns what it asked for, and nothing about the person.
What your service learns
- The predicates your policy asked for: human-backed at the grade you set or above, the scope you require, the per-transaction limit, unexpired.
- A pseudonym for the agent, stable at your service and meaningless anywhere else.
What it never learns
- Who the accountable principal is.
- Which other agents that principal runs.
- Anything about the agent's dealings with other businesses.
Your customer connects an agent once. Every request proves it again.
- Your customer signs in to your service and chooses Connect an agent. Your verifier issues a ten-second challenge that carries your policy.
- The agent presents. On accept, you store the customer, the pseudonym, a name for the agent, its cap and its approval rule.
- Every later request carries a fresh presentation, through the x402 middleware on paid routes or the OAuth bridge (a draft) on ordinary APIs.
- Your service checks the decision, looks up the pseudonym, and applies your ledger, your cap and the approval rule: automatic, or ask the customer.
- When the principal revokes the agent, its next presentation fails with a closed reason, and you mark the profile inactive.
Between a revocation and the first refusal, the published bound is 245 seconds.
Run the verifier yourself, or have us run it.
The verifier kit runs on your machine. It generates your request key there, and the key never leaves it.
In a managed deployment, being prepared, we run your verifier under your origin, and you can rotate its key and export its logs at any time.
The services that already turn away agents nobody answers for.
Paid APIs and metered data
Give accountable agents terms you would never give a script.
You already price access. Accept the agents an accountable person answers for, and give them a quota, credit or routes you keep closed to everyone else.
Your service checks a proof bound to it and learns the grade, the mandate and a pseudonym for the quota, never a name. The identity rides in the 402 response you already send.
Status: the x402 identity leg is in production.
Developer and orchestration platforms
One verification for every agent your users run.
Your users verify once, and every agent they run carries a bounded mandate any site can check. Their names never reach the sites, and you run no identity checks yourself.
It sits beside the tenant identity you already have: that names the process, this names who answers for it.
Status: the refusal that carries the onboarding route is being built.
Reference and community content
Serve a person's assistant at a person's pace.
Add a tier for agents an accountable person answers for. A pseudonym per agent lets you rate-limit each one at a person's pace, and every agent rests on a real identity verification of its principal.
Bulk users stay on your licence.
Status: ordinary routes use the OAuth bridge, which is a draft.
Start with the kit, then ask for admission to production.
- Generate your configuration with the verifier kit: the request key, the domain-control evidence for your origin, your registration and your verifier's settings. The kit is being built in the tools repository.
- Your service's responsible person completes the same identity verification the dashboard runs for every account.
- We file your admission request to production under the network's published admission policy, and you follow it on your dashboard.
The network's integrator page, Accept accountable agents, is not published yet. Its link appears here when it is.
Where the credential comes from
ZadQ is built on the MintID identity network and operated by the CONECTIA group, the network's first implementer, on the same published terms as any issuer: the same admission, the same bond on the network, the same status rules, verifiable by anyone on the network's public record. We disclose this relationship wherever it is relevant.