Every proof-of-humanity system built so far has the same architecture: a platform verifies a user. Tinder checks your photo. Discord makes you solve a CAPTCHA. World ID scans your iris. The platform collects the proof, stamps your profile "verified," and that's it.

The agent trusts the platform. The platform trusts the verification provider. The user trusts everyone involved won't leak their data or go down. It's transitive trust all the way down.

I'm calling this P2U -- Platform-to-User verification. And it's about to become dangerously insufficient.

When an AI agent executes a financial transaction, moderates content, or processes a request on your behalf, it has no idea whether a human is actually on the other end. It has a session token. Maybe an OAuth flow. Maybe a cookie that says you logged in three hours ago.

None of that proves a living human is present right now, at the moment the agent is about to act. A session token doesn't have a pulse. An OAuth flow doesn't prove humanness -- it proves account access. Another agent can hold both.

This isn't a theoretical problem. The EU AI Act (Article 14, enforcement date August 2, 2026) requires high-risk AI systems to implement meaningful human oversight. The word "meaningful" is doing heavy lifting there. A login cookie from this morning is not meaningful oversight of a decision happening right now.

A2H Proof -- Agent-to-Human Proof -- inverts the verification direction.

Instead of a platform checking a user at signup, the agent itself challenges the human at the decision boundary. The exact moment it's about to act. The human responds with a cryptographic proof generated on their own device. The agent verifies it in a sandboxed, auditable environment. No platform intermediary. No transitive trust.

The distinction:

P2U (Platform-to-User): Platform checks user at signup. Agent trusts platform's word. Trust is indirect and stale.

A2H (Agent-to-Human): Agent checks human at the point of action. Trust is direct, cryptographic, fresh, and auditable.

A2H doesn't replace P2U. Platforms should still verify users at onboarding. But when an AI agent is about to do something consequential -- approve a transaction, publish content, escalate a support case, execute a trade -- it should be able to independently confirm a human is in the loop. Not trust that someone else checked last Tuesday.

The flow is straightforward:

1. Agent hits a decision that requires human oversight

2. Agent generates a verification challenge (could be a QR code in a terminal, a push notification, a deep link)

3. Human responds with a cryptographic proof of humanness generated on their own device

4. Agent verifies the proof in a sandboxed, capability-bounded runtime

5. Verified? Proceed. Not verified? Block, escalate, or retry.

The proof layer can be anything that provides verifiable uniqueness and humanness. World ID's Groth16 ZKPs are the most mature option today. Civic, Gitcoin Passport, and future decentralized identity protocols could serve the same role. The A2H pattern is provider-agnostic -- what matters is that the agent is the relying party, not the platform.

If your verification logic runs inside your application runtime, you have a trust problem. Who's to say the verification wasn't spoofed? A compromised application could simply return {"verified": true} for every check and nobody would know.

A2H only works if the verification runs in an isolated, auditable environment. That means:

• The verification binary is reproducibly built and SHA-verified. Any auditor can confirm the exact logic that ran.

• The runtime is sandboxed with minimal capabilities. The verifier gets one outbound network grant (to check the proof) and nothing else. No filesystem, no environment variables, no secrets.

• The proof artifacts (ZKP result, nullifier, timestamp) are logged as evidence. Not just "human approved" but a cryptographic receipt that can be independently verified.

This is the architecture we're building with WasmBox -- WASI-based sandboxed tool execution where every binary is capability-bounded and SHA-verified. A2H Proof is one of the use cases this kind of runtime was designed for.

Regulatory compliance. Article 14 of the EU AI Act requires human oversight for high-risk AI. A2H provides cryptographic proof of human presence at the decision boundary -- not a process document claiming a human was involved, but a verifiable receipt.

Agent-to-agent escalation. In multi-agent systems, how does an agent know that the "human supervisor" it's escalating to is actually human? A2H at the escalation boundary closes this gap.

High-value transactions. AI trading agents, payment processors, and approval workflows can gate execution behind A2H. Not "does this session have permission" but "is a human here right now authorizing this."

Content authenticity. A moderation agent can tag content as human-originated with cryptographic backing. Not a platform badge -- a ZKP that proves a unique human posted this, verifiable by anyone.

Sybil resistance. Any service where one-human-one-account matters (voting, airdrops, waitlists) can enforce it at the agent layer rather than the platform layer.

We're entering a period where the majority of internet traffic will be agent-generated. Most API calls, most content, most transactions will originate from AI systems acting on behalf of humans -- or acting autonomously. The ability to distinguish "a human is here" from "a bot says a human is here" becomes a foundational primitive.

P2U verification was built for a world where humans operated computers directly. A2H is the verification model for a world where agents operate on behalf of humans, and the agents themselves need to know when a human is genuinely present.

The proof-of-humanity protocols exist. The sandboxed runtimes exist. The regulatory pressure exists. What's been missing is the pattern that connects them -- a name for the verification direction that actually matters in an agentic world.

That's A2H. Agent-to-Human Proof. The agent asks. The human proves. The math checks out.