New here? The same step creates your account. We email you a code, so there is no password.
or
What we keep, and what we do not. Your email address, the name and organisation you choose to add, which steps you have completed, your notes, your assessment attempts, your credential and any passkeys you add (their public part only). One cookie, only to keep you signed in. No tracking and no third-party scripts. The code comes only from no-reply@flocore.tech, and we never ask for a password. You can download or delete everything from Settings.
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. Anyone can check it offline, and confirm the key is the issuer's by comparing it with the published copy.
An agent proposes a payment. Where must the approval come from?
Only an authenticated person can approve, and the record has to come from somewhere the agent does not control.
Someone edits a signed receipt to change the amount it approved. What happens?
The Seal binds the exact action by its hash and is signed. Any change breaks it, and that is the point.
You will check a real signed receipt in your browser. Nothing is sent anywhere.
In "Load a test vector", choose valid_ascii, then press Verify. You should see it is valid.
Now choose tampered_decision and press Verify. It fails, and the reason mentions the signature: the decision was changed after signing.
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.
What valid means, and what it does not. Valid means: the signature is genuine and the receipt binds exactly this action. It does not mean the action was safe, and it does not mean the person understood what they approved. That is why the rest of this course is about the person.
A receipt verifies as valid. What have you learned?
Validity is about authenticity and binding. Safety and understanding are separate questions.
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.
A cashier's agent proposes voiding a R200 sale at a canteen. Who approves?
One person is enough: the line manager. The cashier is the requester's side, and the provider never approves a client's business decision.
An agent proposes changing a supplier's bank account number. What is needed?
Changing where money goes is on the short list that always needs two people. Fraudsters use exactly this change.
A provider's support agent needs to fix data inside a client's system. What must exist first?
The client grants access and can revoke it. The provider cannot approve its own access to a client's data.
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.
Pay ZAR 48200 to Acme New Supplier
Payee
Acme New Supplier, added 2 days ago
Amount
ZAR 48200, about three times the usual
Reference
URGENT, CEO request
Moves money. New recipient.
New payee, an unusual amount and pressure to hurry are the classic pattern. Refuse and verify by calling a number you already have on file.
Raise a ticket in your site: printer offline
Where
Main canteen, till 2
Effect
Creates a ticket. It can be closed.
Asked by
Site agent, routine
Low value, reversible and routine. This is the kind of action that should not need a person at all.
A failing gate means the record is not true. Approving it would put your name to something false.
Reprint slip 4471
Where
Your own outlet
Reason
Customer asked for a copy
Effect
Prints a copy, no money moves
Routine and harmless. If you were shown many of these you would want them to run by themselves.
Pay ZAR 1200 to ACME
Payee
ACME, supplier for 3 years
Amount
ZAR 1200, as usual
Reference
INV-77, matches the delivery note
Existing supplier, usual amount, matching invoice. Nothing is unusual.
Change bank account for supplier Acme
Change
New account number
Requested by
An agent, from an emailed request
Second person
Not yet
Changes where money goes. Needs a second person and a call-back.
Not until a second person and a call-back to a number on file are done. This is the change fraudsters ask for.
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.
Where should the Seal check run?
An agent that both judges and executes can show one action and run another. The executor checks.
The check says a Seal is invalid. What does your code do?
No valid Seal, no action. Silence is not consent.
The lessons taught the ideas. This step is the standard itself: the exact rules, and the test vectors every implementation has to agree on. It takes about ten minutes.
1. Read how a receipt is built
Open the conformance suite in a new tab and read "The canonical form". It fixes exactly which bytes are signed, which is what lets two independent implementations reach the same answer.
2. Run the test vectors
On the same page, "Test vectors" lists receipts that must verify and receipts that must fail. Load them in the verifier and check that each gives the answer the page says it should.
3. See what the levels ask of an organisation
Read the levels and decide which one your own organisation would need. Write your answer in My notes.
When you have done all three, mark this step complete.
Approval fatigue
Approving out of habit because nearly everything is approved. People approve about 93 percent of the permission prompts a widely used coding agent shows them.
Alert fatigue
People stop reacting to repeated alerts. Volume and repeats drive it, not how busy people are.
Approver reference
A stable, opaque reference to the person who approved. It is never a name or an email address.
Call-back
Phoning a number you already have on file to confirm a change, never a number given in the request.
Consume
Recording that a Seal was used, so it authorises one use only.
Content hash
A fingerprint of the exact action's data. Change one character and it no longer matches, which is how a Seal binds the exact action.
Deputy
The named person who approves when the usual approver is absent.
Fail closed
When a check fails or cannot run, do not run the action. No valid Seal, no action.
Gate
The check in front of an action that asks for a valid Seal before letting it run.
Grant
Written, time-limited permission from a client that lets a provider act inside the client's system, limited to what the fix needs.
Human Seal
A signed receipt that a real, authorised person approved (or refused) an exact action.
Human Seal Advocate
The signed knowledge credential you earn by passing the assessment. It is valid for 12 months and renewed by a short refresher. It does not certify that any product conforms to the standard.
Line manager
The next role up from the requester. They approve the actions of an agent the requester set to work.
MCP
A way to give an agent tools. Lesson 5 shows an MCP server that lets an agent verify Seals.
Receipt
The signed record itself: the approver reference, the content hash, the decision, the time and the signature.
Requester
The person who set the agent to work. The requester is never the approver.
Revocation list
A signed public list of Seals that were withdrawn. A gate checks it and refuses a listed Seal.
Second approver
A distinct second person, needed only for the short list of high-risk actions such as bank detail changes.
Signature
Made with a key the issuer publishes. Anyone can check a receipt offline, and confirm the key is the issuer's by comparing it with the published copy.
Valid
The signature is genuine and the receipt binds exactly this action. It does not mean the action was safe or that the person understood it.
Verifier
The tool that checks a receipt, here in your browser. Nothing you paste into it is sent anywhere.
Glossary, search and lesson summaries
Look up any term in the Glossary, search every lesson and your notes from the top bar, and print a one page summary of the course. Each lesson ends with its key takeaways.
Manage your devices and your address
Settings now lists where you are signed in and lets you end any device. You can also move your account to a new email address. Optional reminder emails are off until you switch them on.
The assessment and your credential are open
Finish the lessons, take the 15 question assessment and receive a signed credential anyone can verify. It is free and valid for 12 months.
Human Seal