HumanKey

Inspiration

Browser agents are powerful, but consequential workflows still force them to infer meaning from pixels, DOM labels, and prose. HumanKey explores a stronger model: the page itself declares exactly what an agent may do, and consequential authority appears only after a visible human decision.

What it does

HumanKey is a WebMCP control plane for proof-carrying delegation. A human defines a mission envelope with a goal, spending ceiling, required evidence, and an approval threshold. The agent can read the mission, inspect verified evidence, stage a reversible action, evaluate deterministic policy, request approval, verify a receipt, and export an audit bundle.

The key interaction is dynamic capability exposure. The demo starts with seven discoverable WebMCP tools. A synthetic $1,840 supplier release passes evidence and policy checks but exceeds a $1,000 human-approval threshold, so the commit capability does not exist. When the human visibly clicks Approve, commit_approved_action is registered and Chrome discovers an eighth tool. After the agent commits the synthetic action, the capability unregisters itself and the surface returns to seven tools.

The committed action emits a SHA-256 receipt over the canonical mission/action record. verify_action_receipt independently recomputes the hash and confirms the receipt. Every state transition is attributed to the human, the agent, or the deterministic policy engine. No real payment API is connected; all demo data is synthetic.

How I built it

HumanKey uses both declarative and imperative WebMCP. The reversible staging step is an annotated HTML form exposed as stage_release_action, while mission, evidence, policy, approval-request, receipt-verification, and audit-export operations are imperative tools registered through document.modelContext.registerTool(). The approval-gated commit tool is registered only after human approval and removed using an AbortController after its in-flight execution resolves.

The experience was validated against Chrome's native document.modelContext.getTools() and executeTool() APIs. Native QA produced the expected 7 -> 8 -> 7 lifecycle and an exact SHA-256 receipt verification result of valid: true. The app is a static HTTPS site hosted on GitHub Pages with a public MIT-licensed repository.

Challenges I ran into

The hardest part was making authority a real browser capability boundary rather than a hidden boolean. The commit tool must not exist before approval, must become discoverable immediately after approval, and must unregister safely without cancelling its own in-flight execution. Native Chrome QA exposed that lifecycle edge case and the implementation was corrected accordingly.

Accomplishments that I'm proud of

The agent cannot self-approve because the consequential tool literally does not exist before the human decision.
Human-visible UI and agent-visible capability state stay synchronized.
The final synthetic action produces a verifiable SHA-256 receipt and an auditable provenance trail.
The demo works against native Chrome WebMCP rather than only a mock implementation.

What I learned

WebMCP can do more than make forms easier for agents. It can make authorization itself part of the website's structured capability surface. That creates a reusable pattern for procurement, finance operations, deployment gates, compliance workflows, and any task where automation is valuable but final authority should remain human.

What's next for HumanKey

The next step is to generalize the mission/evidence/approval/receipt pattern into reusable components that sites can adopt for high-consequence agent workflows, with richer evidence adapters, signed receipts, and policy modules while preserving the same visible human checkpoint model.

Live app: https://b11-health.github.io/webmcp-challenge-2026/

Source: https://github.com/B11-Health/webmcp-challenge-2026

Demo: https://youtu.be/2lLuM4TvtN4