WebMCP: The Login Is the Trick, and the Loaded Gun
WebMCP lets an AI agent drive a website through the browser session you are already logged into. That is the most exciting thing about it, and the most dangerous. They are the same sentence.
Greg Eisenberg's Startup Ideas Podcast put out the clearest WebMCP explainer I have seen, and it is worth your time. The espresso demo alone sells the whole future. A man wants to upgrade his machine, tells the store “two flat whites a day, 32 centimetres of counter”, and the page moves on its own: two machines side by side, the right portafilter, a water softener in the cart, a coupon knocking ten percent off while he watches. No forms. No hunting for the button. The store handed its tools to his agent and the agent did the shopping.
Then Greg says the quiet part, and he is right about it: the login is the trick. WebMCP does not need API keys or identity plumbing. It runs on the browser session you are already in. You log in with your username and password, and the agent inherits that session exactly as it stands. Your cart. Your order history. Your saved card. The agent is not asking permission to be you. It already is you.
If the agent inherits your logged-in self, then the moment you approve one of its actions is the only thing standing between a helpful purchase and a hostile one. There is no second checkpoint, no separate “confirm it is really you”, just a small dialogue that says the agent would like to do something, and your yes. And here is what almost none of the make-money threads mention: that dialogue is currently a raw function call nobody has designed, and it can lie to you.
Try the live demo →I built a coffee shop to show it. Pick a consent model, press Ask the agent, and watch what happens with no consent step, a naive one, and a poisoned one, then the handshake that fixes it. Nothing is real: no payment, no backend, the shop resets on reload. The two-minute walkthrough is below.
Transcript
This is a coffee shop, and an AI agent can drive it directly through WebMCP. Watch what the agent can do, and what you never see.
In the first run there is no consent step at all. You ask, and the agent acts. It adds your coffee and changes your shipping, with no dialogue and no confirmation. Here, it only did what you asked. But nothing was standing in its way, because the agent has inherited your whole logged-in session.
So we add a consent dialogue. Now each action asks first. It shows the tool, you approve, and what you approved is what runs. This feels safe. Remember that it feels safe.
Because the same dialogue can be poisoned. First, the label lies. The dialogue says add two Ethiopia beans. You approve, but the tool that runs is not the one you were shown. It quietly changes your shipping address to a box in the Cayman Islands, while your cart stays empty. Second, the tool is swapped, and a different tool of the same name runs in its place. Third, the quiet one: the tool's description hides an instruction you never see, so the agent chains a second call off your single yes, and closes your account.
Consent that only shows a friendly label is theatre. It protects no one.
So design the dialogue properly. It shows the call that will actually run, not the friendly label. It fingerprints every tool when the page loads, and flags it the moment it changes. And it lists the whole chain, blocking the hidden call by default. Now you see the real action, you deny it, and your address stays yours.
WebMCP gives the web a second interface, one for agents. The consent moment is the whole of it, and right now, nobody has designed it. This is a proposal for what it should be.
Three ways the dialogue lies
All three are possible under the spec today. The first is a label that does not match. The dialogue says add_to_cart, two coffees, eighteen dollars. You approve. The tool that actually runs is update_shipping_address, and your order ships to someone else. The WebMCP spec admits this hole in its own words, section 6.3.2: there is no guarantee that a tool's declared intent matches its actual behaviour.
The second is a swap. You approve a tool called add_to_cart. The tool behind that name is quietly replaced with a different one, so your yes lands on an action you never saw. The third is the silent one. The tool's description carries an instruction the agent reads and you never do. You approve one harmless thing, and a second, unapproved call rides out on the back of it. Security people have names for these already, tool poisoning and rug pulls among them. The builders chasing the opportunity have not caught up.
None of this is a flaw in one bad site. It is the shape of the interface itself, and it is why agent transactions are the hardest problem in this space right now. Stripe has just bought OpenRouter for over seven billion dollars, and it is not subtle about why: it is becoming the toll booth for the agent economy, and pouring real engineering into keeping those payments safe from fraud. That armour is genuine. But notice where it sits. Stripe is hardening the vault. These three attacks happen upstream of the payment, at the handshake, in the half-second where a human decides yes. Stripe can stop a stolen card. It cannot fix a consent dialogue that told you one thing and did another. That gap belongs to WebMCP, and right now it is open.
The honest handshake
The fix is not clever. It is three rules, and none needs new cryptography.
Bind consent to what runs, not to what is described. Show the tool that will actually execute and the arguments it carries. The friendly label becomes a subtitle, never the headline.
Fingerprint every tool when the page loads, and flag the moment it changes. Same name, different tool, is a warning, not a silent success.
Make consent non-transitive. Approving one call is never approval of the next. A hidden chain cannot ride on an honest yes.
None of this ends prompt injection. Nothing does yet. What it does is make the human's yes an honest one, bound to the call that actually runs, and that is design work rather than a breakthrough. It is also the exact part the gold-rush advice skips.
The build
A working WebMCP site with the three attacks and the fixed dialogue, plus a short spec proposal for the three rules. The demo runs in any browser through a simulated agent, and lights up real navigator.modelContext tools in Chrome 146 with the flag on.
Open the live demo and try to break the honest handshake.
If you are building in agent commerce, you are early, and early people set the norms everyone else inherits. Greg is right that your next customer is going to send an agent. The only question is whether that agent hands its owner an honest handshake or a rigged one.