Become a Human Seal advocate

The five lessons

1. Why a human, and what a Seal is
2. Verify a Seal yourself
3. Who approves what in a company
4. Why people stop checking, and what stops it
5. Put a gate in front of an agent in ten minutes

After the lessons comes the assessment and the signed Human Seal Advocate credential, a receipt anyone can verify. Take the lessons now; the assessment follows.

Lesson 1. Why a human, and what a Seal is

AI agents no longer only answer questions. They pay suppliers, change records, send messages and delete data. When an action changes the real world, someone has to be able to say who allowed it.

A model's own refusals cannot be that control. They can be removed automatically, and an agent's own log cannot be the evidence, because the agent controls it. The control has to sit outside the model, and the proof has to be checkable by anyone. Read the case for the sources.

A Human Seal is a signed receipt that says:

• Who approved: a stable reference to a signed-in person, never a name or an email.
• Which exact action: a hash of the action's data. Change one character and the Seal no longer matches.
• What they decided (approved or refused) and when.
• A signature made with a key the issuer publishes, so anyone can verify it offline, without trusting the issuer.

Lesson 2. Verify a Seal yourself

You will check a real signed receipt in your browser. Nothing is sent anywhere.

1. Open the verifier in a new tab.
2. In "Load a test vector", choose valid_ascii, then press Verify. You should see it is valid.
3. Now choose tampered_decision and press Verify. It fails, and the reason mentions the signature: the decision was changed after signing.
4. Load valid_ascii again. In the action box, change the amount from 1200 to 12000 and verify. The receipt is genuine but it does not bind this action, so it fails.

Lesson 3. Who approves what in a company

In a real company the person who approves is not the owner of the platform. It is the person responsible for that kind of decision. The rules that work in practice:

• The requester is never the approver. The person who set an agent to work is not the one who checks its work: the line manager, meaning the next role up, does.
• Whose data decides. An action is approved at the lowest layer that owns the data, money and people it affects. Head office owns limits, supplier and bank details and prices. A site works inside those limits.
• Two people, only for a short list. Bank or payee detail changes, payroll, access and role changes, irreversible actions above a limit, anything above the top value band, and conflicts of interest.
• A provider is not the client. A software provider approves only its own work. Inside a client it acts under a written, time-limited grant from the client, and never approves the client's business decisions.
• Absent approver: a named deputy. An unlisted action goes to the owner, and never to nobody.

Lesson 4. Why people stop checking, and what stops it

A human in the loop only works if the human actually checks. The research is blunt:

• People approve about 93 percent of the permission prompts a widely used coding agent shows them, and its makers call the result approval fatigue.
• Clinical drug alerts are overridden in 49 to 96 percent of cases. Repeats and volume drive it, not how busy people are.
• With an automated aid, people missed 41 percent of critical events, against about 3 percent without one. Practice and instructions did not cure it.
• What helped in controlled studies: deciding first before seeing the machine's answer, or a short forced wait, raised correct answers when the machine was wrong from 8 to 27 percent.

What keeps reviewers honest, without extra work

• Fewer approvals. Only the consequential few reach a person. Routine, reversible actions run inside limits and can be undone.
• Show what will happen, in the platform's words. Not the agent's description of itself.
• Show what is unusual. A new payee, three times the usual amount.
• Test attention now and then with clearly disclosed practice items, and measure how long people look at right and wrong items.

Try it: six requests

Each card is written the way a good approval screen should show it. Decide, then read why.

Lesson 5. Put a gate in front of an agent in ten minutes

The rule: the component that runs the action checks the Seal, on the exact data it is about to run. An agent never checks its own action.

Path 1. Check a Seal before you execute

curl -O https://humanseal.world/sdk/hs-gate.js
curl -O https://humanseal.world/assets/hs-verify.js
# Node 20 or later, both files in one folder
const { checkSeal } = require('./hs-gate.js');
const r = await checkSeal({ receipt, action, actionType: 'pay', approver: expectedApprover, tenant: 'your-tenant' });
if (!r.allow) throw new Error(r.reasons.join('; '));   // fail closed

Path 2. Give your agent the verifier as a tool

The MCP server exposes humanseal_verify and humanseal_check_seal. Download it from the developers page and add it to your MCP client.

Path 3. Honour single use and revocation

Call the consume step so a Seal authorises one use, and check the signed revocation list. The developers page lists the endpoints.

You have finished the lessons

Next comes the assessment and your signed Advocate credential. In the meantime, join as a founding member or verify another receipt.