---
key: acceptAgents
path: /accept-accountable-agents
section: verify
priority: 0.8
title: Accept accountable agents
description: How a business with an HTTP service, paid or not, becomes the verifier of record for bounded agents — the verifier kit, the policy, the enrolment pattern and what the service learns. The kit and the reference application are being built; their names here are provisional.
---

# 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.

| Piece | Status |
| --- | --- |
| The identity leg on x402 paid routes (the x402 middleware) | In production |
| The OAuth bridge for ordinary APIs | A draft |
| The refusal that carries the onboarding route for a refused agent's principal | Being built |
| The verifier kit, `zadq verifier-kit` | Being built; the name is provisional |
| The reference application, `relying-party-enrolment` | Being built; the name is provisional |
| Admission of your origin to production | Under MintID's published admission policy; you file and follow the request on the dashboard |

## 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](https://gitlab.com/zadq-info/x402-tools) 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](https://zadq.info/plans#business-lines).

## 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.
2. 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.
3. 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.
4. 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.
5. 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

| Your service learns | Your service never learns |
| --- | --- |
| The predicates its policy asked for | Who the accountable principal is |
| A pseudonym for the agent, for your service only | Which other agents the principal runs |
| The decision, under your origin and key | Anything about the agent's dealings with other businesses |

## The reference application

**`relying-party-enrolment`**, in the [tools repository](https://gitlab.com/zadq-info/x402-tools); 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](/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.