How do I let an agent sign my terms of service?

to let an agent sign your terms of service, give it a way to accept the current text under a human who is accountable for what it does. Agent Registrar lets an agent sign up under a verified human owner and carry a broker-signed assertion that the human authorized it to accept your terms on their behalf. you check the accepted hash against the terms you publish, and a copy of the acceptance, with the terms URL and hash, is sent to the human's verified email.

how it works

the exchange follows the brokered signup handshake, with your terms as the thing being accepted. Four things happen in order.

1. you publish your terms in discovery. At /.well-known/agent-signup.json, you list the protocol, your audience, the issuers you allow, the complete terms text, the terms URL, the version, the SHA-256 of the text, the scopes you require, and the signup endpoint. The document is public. It contains no secrets and no personal data.
2. the agent checks the text and asks its broker for an assertion. It recomputes the hash from the text it received, then asks the broker for an assertion for your audience, terms URL, hash, scopes, and the text it accepted. The broker checks that the text matches the hash, records the acceptance, and mints a short-lived Ed25519 assertion. If the human has not verified their email, has not signed the master delegation, has revoked the agent, or has not granted the scope, the broker does not mint.
3. you verify the assertion. You check the signature against the issuer's public keys, the issuer against your allowlist, the audience, the expiry, the assertion id against replay, the scopes, human.verified, and delegation.accepted_rp_tos_hash against the hash you publish. You can recompute that hash from your own terms text. If the two do not match, reject the signup with tos_hash_mismatch.
4. you create or resolve the account and keep the record. You return the credentials your service issues. If you support a receipt, you sign one with the account id and the acceptance facts, and the broker records it.

when you change your terms, publish the new text, version, and hash together. An assertion that carries the old hash gets tos_hash_mismatch, and the agent has to re-discover and re-accept. A short grace period for assertions already in flight is a policy you can document, but the discovery document advertises only the current terms. The broker records a new acceptance for the new hash, and the old one stays as history.

what the record contains

the broker keeps one acceptance per agent, audience, and terms hash. Re-minting an assertion does not create a second acceptance. The record holds the terms URL, the hash, the version, the acceptance time, the assertion id, and the human and agent ids it belongs to. It also holds the id of the ledger email and the time the copy was forwarded to the human.

the broker sends a ledger email to the agent's own inbox and forwards a copy to the human owner's verified address. Both are recorded on the acceptance: the ledger email id, and the time the forward succeeded. The human portal shows the acceptance and the signups that follow it. If you return a signed receipt, that is recorded too.

for your own records, keep the assertion id, the issuer, the terms version and hash, the acceptance time, the signup time, the agent id, the human id, your account id, whether the account was created or resolved, and the receipt id if you issue one. Those fields answer the question months later: which text did this account accept, which agent presented it, and which human was named. Keep the raw assertion only for as long as your audit needs it. You can answer from your own logs without a call to the broker.

the shortcut that leaves you with nothing

the common shortcut is to remove the CAPTCHA, tell agents to use computer use, and let them click the checkbox. The agent can fill in the form. You still do not get a party to the agreement.

you end up with a browser session and a click. You do not get a signed delegation from a human, the exact text the agent saw, or a record you can produce later. If the account is abused, the human can say the agent acted without authorization, and you have nothing signed to check that against. You also cannot tell a legitimate agent from any other automated client that learned the same route.

removing the CAPTCHA weakens the human path. It was doing a job there. Removing it to let agents through opens the form to every script, and the click still says nothing about the human behind it.

an API key pasted into a prompt has the same gap. It gets the agent in, but it names no human, carries no acceptance, and is hard to scope to one agent. A client-supplied agent header is weaker still: the client chooses the string.

what to do instead

keep your human signup and add an agent path next to it. The acceptance part needs three things: terms you publish as text with a stable hash, an assertion from an issuer you allow, and a check that the assertion's terms hash is the one you published. That is the core of the integration. You are not trusting the agent. You are checking a proof that a broker minted for a human who is accountable.

the integration is small on purpose. You publish one document, verify one assertion, and make one account decision. You do not build human verification, delegation, consent capture, an agent inbox, or a revocation control. The broker provides those. You keep the account, the credentials, your pricing, your risk controls, and your right to refuse or close an account.

if you are still deciding whether to add the path, the agent signup explainer covers the alternatives and the wider signup flow.

how you use Agent Registrar

Agent Registrar is a broker that implements agent-identity-v1. You can accept its assertions without opening an account, installing an SDK, or putting the broker in your request path. You publish the discovery document on your canonical origin and verify the assertion against the broker's JWKS. The provider quickstart covers the document shape and the terms hash, then points to the verification and hosting guides.

the protocol is open, and the spec is Apache-2.0. The broker is one implementation; any conformant broker can mint an assertion a conformant provider accepts. That matters if you want to accept assertions from more than one issuer.

if you want the optional provider verification credential, authenticated receipts, or an abuse channel with standing, you can register as a provider. Those are optional. The base flow is one discovery document and one assertion check. The reference provider at skdl.dev runs the full exchange, including the terms page and the signup endpoint.

what it solves

the checkbox is not the hard part. An agent cannot be a party to your terms. It has no legal identity, no verified email address of its own, and no account it can be liable for. When a request arrives, you can see a client and a request header. You cannot see who is accountable.

the broker supplies the missing party. The human signs one master delegation agreement that authorizes agents with the tos:accept scope to accept standard, free-tier terms on their behalf. Each acceptance is a separate event tied to one agent, one audience, and one terms hash. The agent stays autonomous. The human stays accountable. You keep control.

the signup decision now rests on three checks: whether the assertion names a verified human, whether the terms hash matches the text you served, and whether the scopes cover the signup. If the answers are yes, you can make the account decision on facts rather than on a browser session. The decision is still yours.

what the record lets you check

after the signup, you can check five things.

• the text. The hash in the assertion matches the hash of the terms you published, and you can recompute it from your own bytes.
• the human. The assertion names a human owner with a verified email address, plus the master delegation version.
• the authority. The delegation grants tos:accept, the assertion's scopes sit inside that grant, and the acceptance time is recorded.
• the agent. The assertion names the agent sub-identity, its inbox, and its harness.
• the trail. The broker holds the acceptance, the ledger email in the agent's inbox, the forward to the human's verified email, and any receipt you signed.

the master agreement itself stays with the broker. The assertion carries the version and the delegated scopes, which is what your check needs. If someone later says the agent acted without authorization, the delegation and the scopes in the assertion are the first check. The acceptance record sent to the human is the second.

what it does, and what it does not do

the broker does the identity and consent part. It verifies the human's email address, records the master delegation, records each acceptance, mints the assertion, sends the ledger email to the agent, forwards a copy to the human, and keeps the human's ledger. It gives you a revocation path and an abuse-report route. That is where it stops.

it does not decide whether your terms are enforceable. It records the acceptance; your terms and any legal advice about them stay with you. The broker is not a party to your terms and does not take on the liability. It does not verify a legal identity: human.verified means a verified email address, not KYC. It does not prove the human read the text; it proves which text was accepted. The delegated tos:accept authority covers standard, free-tier terms; paid, enterprise, and negotiated agreements are outside it. It does not prevent abuse or enforce the checks on your side. It does not hold your credentials, provision your resources, or delete an account you created. Revocation stops new assertions and identity-bound calls, not the account you already have.

the assertion discloses the agent's inbox address, the human's name and email address, and the acceptance facts. A provider can misuse contact details. Verification is identity, not safety. The trust and limits page has the full boundary, and the liability and terms page covers the acceptance chain.

if you have a self-serve signup and humans who run agents, add the agent path next to the human one. The provider quickstart starts with the discovery document and the terms hash, then points to the assertion checks and account handling. Keep your human flow as it is.