As AI agents take on more of the internet, an action alone won’t tell you whether a person approved it.
Enthade helps services require human sign-off for a specific action. In the service’s iPhone app, review the request and authorize it with Face ID or Touch ID. The app sends a receipt—evidence its backend can check.
Experimental v0.1 External audit pending
To: Alex · Message: “Let’s meet at 3 pm on Friday.”
AI can prepare it. The receipt covers your authorization.
An agent can research, draft, and plan. The service chooses which actions need your approval: sending a message, publishing a post, or granting a specific permission. Its app shows the exact request; its backend requires and checks the receipt before proceeding.
Biometric approval adds friction in exchange for stronger evidence of human sign-off. Keep it at the actions that need that assurance. The receipt covers the selected action, not the quality of the agent’s work or every later step.
Sending, publishing, voting, or granting permission: a service chooses its approval points. AI can help with the work leading up to them.
Let an agent research, draft, and prepare a request. Before the selected final action, the app asks you to review and approve it. The service checks the receipt before proceeding.
To: Alex · Message: “Let’s meet at 3 pm on Friday.”
This receipt covers the final action. It does not authorize every later action or certify the agent’s earlier work.
Walk through this actionPotential applications, not announced customer deployments. Enthade Forum is the first-party experimental reference app.
Review the request. Approve on your phone. The service checks the receipt. Follow the final step of an agent’s workflow.
Interactive illustration · no biometric check or real proofThe app shows exactly what will happen before you authorize it. A one-time request from the service keeps the approval tied to this submission.
To: Alex · Message: “Let’s meet at 3 pm on Friday.”
A protected action has no passcode fallback. If the required biometric authorization is unavailable, the action cannot satisfy that policy.
Why this mattersThree different questions. Three distinct layers. A receipt should state which evidence was actually evaluated.
Was this exact action
cryptographically authorized?
A qualifying key signed a record tied to this exact action. The trusted app and platform require biometric approval; a verifier checks the cryptographic evidence.
Cryptographic foundation
Did the app and device
meet the required trust profile?
Platform evidence is checked against a published profile. The service chooses which environments and evidence qualify under its policy.
Platform trust evidence
Does the interaction add evidence
that someone is physically
there?
An additional, adaptive layer can assess interaction signals. It provides confidence under a versioned policy, rather than cryptographic certainty.
Probabilistic assessmentThese layers do not establish authorship, legal identity, unique personhood, truth, or whether someone read and understood the content.
The protocol is designed around minimal disclosure: give the service the evidence it needs to assess an action.
Read the privacy modelFace ID or Touch ID controls access to the key locally. Enthade does not receive your face, fingerprint, or raw biometric data.
A service can check a receipt with an open verifier and published issuer keys, without calling Enthade servers or relying on a secret verification algorithm.
The current design gives each service’s app separate credentials and issuer keys. A receipt hides the underlying phone key; it does not provide a shared identity across services.
A service can still link actions within its own context. Privacy depends on implementation, operational separation, and the service’s own data practices.
Enthade is the umbrella project. The protocol is its foundation; the apps and services build on top.
The open rules for creating and verifying action-bound evidence.
Frozen v0.1 specificationPlatform libraries and verifier implementations for builders.
iOS + Node proof of conceptA reference community app for human-attended ideas and votes.
Internal test appThe hosted verification service envisioned for teams that want managed infrastructure.
Planned serviceAdditional adaptive assessments of physical interaction and automation.
PlannedPublic transparency through verifiable commitments and checkpoints.
PlannedEnthade is experimental and pre-audit. The current work demonstrates the flow on iOS with local services. External cryptographic review, production validation, and Android support remain ahead.
Implementation statusA few things to understand before
putting Enthade to work.
Yes. An agent can research, draft, plan, and take the steps an app allows it to take autonomously. The service chooses which actions need human authorization. Its app shows the request and asks for biometric approval; its backend requires and checks the receipt before proceeding.
Yes. A service can make a specific permission grant a protected action. The receipt covers the scope that was authorized. The service must enforce that scope and any limits. It does not mean a person separately approved every later action the agent takes.
No. Enthade gives a service a way to require authorization evidence for a chosen action. An action without that receipt is missing the required evidence; it is not automatically classified as AI. A receipt also makes no claim about who prepared the content.
No. Enthade concerns the authorization of an action. AI-assisted writing is compatible with the project. A signed contribution can still be inaccurate, copied, or AI-generated.
A CAPTCHA asks someone to complete a challenge. Enthade binds authorization evidence to a specific action, receiving service, challenge, and policy. The verifier assesses that evidence; Enthade does not claim to eliminate every form of automation.
No. Enthade does not establish a person’s name, legal identity, or uniqueness. A credential is not a unique human. Polls and services still need their own account, eligibility, and duplicate-vote rules.
The protected action cannot satisfy the policy. Reading, drafting, or recovery can remain available, but a password or passcode cannot substitute for the required authorization. Recovery can enroll a new qualifying key; it cannot sign the protected action itself.
No. Biometric processing happens on the device. The verifier checks cryptographic evidence and trusts the service’s app and platform to enforce the biometric gate. It does not observe your face, fingerprint, or biometric check.
The design binds evidence to the exact action, receiving service, policy, challenge, and expiry. Changing the protected content changes its hash. The receiving backend must also enforce challenge consumption and replay rules.
With fresh biometric approval required for each protected post or comment, the service blocks publication without that approval. It also rejects spent receipts and approvals for different content or a different service. A script cannot publish thousands of posts using one sign-off: each accepted submission needs its own.
The current implementations are experimental prototypes and internal test apps. External audit and production validation are pending. The developer guide explains the design and the current implementation boundaries.
Choose the actions that deserve a deliberate human approval. Keep the rest of the workflow moving.
Read the developer guideἐνθάδε · “here, in this place”
Stop unattended
mass posting.
Require fresh biometric sign-off for every accepted post or comment. The social network rejects missing, reused, or mismatched approvals. A script cannot turn one approval into a burst of different posts.
A thousand posts.
A thousand approvals.
Every accepted post needs its own approval. That puts human time into the cost of mass spam. AI can still help you write; you authorize publication.