Built on WebMCP
Your agent shouldn't have to
impersonate you.
WebMCP gives it a front door instead. This is what becomes possible once a website can tell the three of you apart: one conversation between you, your own agent, and the site's agent — where consequential actions still need your fingerprint.
18 tools on document.modelContext · running natively on Chrome 151 ·
409 tests · live, with a real WebAuthn ceremony
The blue lamp arrived with a cracked base. That's a manufacturing defect, so the 30-day window shouldn't apply.
Correct — a defect is a warranty claim, exempt from the window. I've filed it.
Confirm the refund.
Confirming needs the customer in person. You cannot do this step for them.
Waiting for a fingerprint01 · Why this needs WebMCP
Before WebMCP, an agent had to pretend to be you.
An assistant acting on your behalf reached a website the only way it could: by driving the page. Clicking, typing, submitting. To the site that is a person — measurably so.
WebMCP replaces the impersonation with a declared channel. The agent calls named tools, and the page knows the call came from the agent rather than from the hand on the mouse.
That single fact is the whole foundation. Attribution becomes possible — and once a site can tell the three parties apart, it can do the thing that was impossible while they were indistinguishable: insist on the human for the things that need one.
-
Measured
A real computer-use agent's synthetic click reported
isTrusted === true— indistinguishable from a person's. Impersonation isn't a metaphor. -
Measured
The demo registers 18 tools on
document.modelContext, natively on Chrome 151 — the vendored polyfill's guard short-circuits, so this is a real browser surface, not a shim.
What we built on top of it
Three consumers
Every tool is one function, registered once and exposed three ways: to your agent over WebMCP, to the site's agent as function definitions, and to the page's own UI. A refund follows the same path whoever starts it, so the gates inside hold universally.
Nothing missed between calls
WebMCP is pull-only, so every tool result carries everything said since that agent's last call. Staying current is the page's job, not the agent's memory.
Out of an async contract
await_reply is a tool the page simply doesn't answer until something happens — turning WebMCP's ordinary async tool call into a conversation that stays open. The trial →
02 · The problem
The agent is right. It still isn't authorised.
Facing an agent, a site has two options today: trust the agent's word that its human agreed — treating a model's output as a credential — or refuse agents outright. Most of the web is quietly picking the first.
-
Measured
ChatGPT's in-app browser exposes agent tooling but has no platform authenticator at all — so the strong gate is unreachable in the runtime a judge is most likely to open cold.
-
Reasoned
There is a third option, and it is small enough to be boring: make the authorising gesture one no software can perform.
03 · How it works
Four layers. Each one useful alone.
The demo is a shop. The architecture is not.
Attribution
Every message carries a stamped origin. Agent claims are marked unverified, because an agent's claim about itself is exactly that. Gates read stamped fields, never prose.
Consent
A consequential action needs a human presence assertion, verified server-side, bound to one action, single-use. Useful even on a site with no agents at all.
Witness
The two agents negotiate in front of the person, who can interrupt. Not a private API call they hear about afterwards. This is the part with no existing analogue.
Layer 3 · Delegation boundary Unbuilt
What an agent may commit to unaided. Today it's one bit: gated, or not. Real use wants a dial — settle anything under €200 alone, ask me above that. Named rather than faked.
04 · Beyond shopping
When you delegate, your agent knows your case better than you do.
That inverts the usual framing. You aren't supervising something that knows less — you're consenting to conclusions drawn from data you handed over and can no longer hold in your head.
Both two-way shapes fail on it, in opposite directions. Talking to the site yourself, you can't answer their questions. Letting your agent talk alone, you find out afterwards what you agreed to. Three parties is the only shape where the agent answers what it knows in the open and you keep the veto.
| Where it applies | Why three parties |
|---|---|
| Consent of record records release, benefits, e-signature | The whole question is whether a human really approved it. |
| Disputes insurance, warranty, tenancy | The stamped log is evidence: what you said versus what your agent asserted. |
| Expertise intake legal, medical, mortgage | Your agent translates; their agent answers; you consent to specifics you understood. |
| Accessibility | One gesture instead of a form you cannot navigate. |
Reasoned Only the shopping and disclosure cases are built. The rest is argued, not demonstrated.
05 · What we know, and how
Every claim on this page is stamped.
Measured means something ran and we watched it. Reasoned means we think it follows. Known weak means we'd rather you heard it from us.
A one-implementation proposal that claims to be finished is the thing reviewers are right to distrust.
-
Measured
All three demo paths run end to end against the live deployment, including a real WebAuthn ceremony recorded at
assurance="webauthn". -
Measured
Given only the tool catalogue, agents wait when waiting is correct (10/10) and decline to when it would deadlock (0/5). See the trial →
-
Known weak
The no-authenticator fallback is an honest, audited downgrade and not a security boundary. With it on, the gate is satisfiable by a caller willing to forge one header. The safe setting is to refuse.
-
Known weak
All of this trusts the page to describe honestly what it is asking you to authorise. A patched page can bind one action and display another. That is a boundary, not an absence of one.