Accept accountable agents

This page is for a business whose HTTP service, paid or not, should accept software agents only when an accountable principal stands behind them. Your service becomes the verifier of record: it runs the MintID verifier under its own origin and its own request key, checks a presentation from each agent, and keeps its own ledger. The protocol charges nothing to verify; operators price their own services.

Most of the pieces below are being built. This page names them so you can plan, and says what runs today.

The words on this page

• Bounded agent: software that acts for a person within a scope, a cap

and an expiry that person set when the agent was minted.

• Human-backed agent credential: what a bounded agent presents; it

proves an identity-verified person answers for the agent, without revealing who.

• Accountable principal: the person who answers for the agent.
• Relying party: a service that decides whether to accept an agent.
• Verifier of record: the relying party in its role on the network. The

decision is yours: challenges are bound to your registered exact origin, so nobody can decide for you.

The verifier kit

The kit lives in the Apache-2.0 tools repository and runs on your machine. Status: Being built; the name is provisional.

• **zadq verifier-kit init** produces, locally: the request-signing key (it

never leaves your machine), the domain-control evidence file you publish at your origin, the self-registration transaction signed by your operator key (ZadQ never holds it), the configuration of the verifier service, a policy preset per scope bundle, and the OAuth bridge configuration (a draft) for ordinary APIs beside the x402 middleware.

• **zadq verifier-kit check <origin>** replays the conformance set against

your 402 response and your challenge route.

The verifier itself is the MintID verifier SDK in service mode, beside your service. The kit configures it; it does not replace it.

The kit and the SDK are free. ZadQ pays a referral share per person your door sends who keeps a paid plan — the amounts are on the plans page.

The policy your service asks for

Your verifier sends a challenge with a policy. The agent proves:

• human-backed at the grade you set or above;
• scope includes your counterparty form and category;
• a per-transaction limit at least the cap you want proven;
• the pairwise pseudonym (always asked) and unexpired.

A presentation lives ten seconds and is bound to your exact origin, your verifier id, your request key, the nonce, the policy and the chain height. It proves the predicates at the moment it is made; it is not a proof of how recently the principal was verified.

The enrolment pattern

1. Your customer signs in to your service and chooses Connect an agent.

Your verifier issues a ten-second challenge with your policy.

1. The agent presents. On accept, you store

{customer_id, pseudonym, name, cap, approval_rule}. The pseudonym is stable for this agent at your service and meaningless anywhere else.

1. Every later request carries a fresh presentation: the x402 middleware on

paid routes, or the OAuth bridge (a draft) on ordinary APIs, which turns an accepted presentation into a short-lived session credential.

1. Your service checks the decision, looks up the pseudonym, applies your

ledger and the cap, and applies the approval rule: auto, or ask the customer.

1. When the principal revokes the agent, from the holder or at the issuer,

the next presentation fails with a closed reason and you mark the profile inactive. On the single-node production chain the published bound between a revocation and the first refusal is 245 seconds.

The ledger, the cap and the approval rule are yours. The pseudonym can be personal data at your service: keep it under your own data-protection rules.

What your service learns, and never learns

The reference application

**relying-party-enrolment, in the tools repository; status: Being built; the name is provisional. A small relying party your developers run in an hour: a customer sign-in stub, the Connect an agent** screen (name, cap, approval rule), the profile table keyed by the pseudonym, the per-agent ledger and cap, the ask-the-customer approval, an x402 paid route and an ordinary route behind the OAuth bridge (a draft), and a revoked agent failing with a closed reason. Its README walks the pattern above.

Admission to production

Before your service accepts agents in production, its origin is admitted under MintID's published admission policy. ZadQ collects what the policy asks (your origin, the evidence file, the responsible person's identity verification and your acceptance of the verifier obligations) and files the request; you follow it on the dashboard.

Running it

You run the verifier yourself with the kit, or, in a managed deployment being prepared, ZadQ runs it under your origin and you can rotate its key and export its logs at any time.

Every route you do not gate keeps working as it does today: the gate is your own policy, applied by your verifier.

Further reading

• MintID's integrator page, Accept accountable agents (not published yet: the link is added here when it is).
• The offer for businesses: Accept accountable agents

on the main site.

The platform

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.