I built GeoMart for OpenAI's WebMCP Challenge: a storefront where a human fills in a live, unsubmitted "site brief" and an AI agent uses WebMCP tools to read it, score survey equipment against real physical constraints, and draft a quote the human has to approve. The hackathon's own rule is blunt: every core action has to be reachable only through a WebMCP tool, no REST route allowed to duplicate it.
I thought I'd covered that. Then I asked Google Antigravity to try to break it, gave it the full source code, and it found three problems in about ten minutes.
Antigravity's first pass found that agent-supplied text, the quote reasoning, the product IDs in the comparison tray, was going straight into the page via unescaped innerHTML. It also found something worse: POST /api/quotes, the endpoint that creates a quote request, had zero protection. A bare script from outside any browser could call it directly and submit a quote with no human involved at all.
I fixed both. HTML-escaped every agent-supplied string before it hits the DOM. And added an isTrusted check on the submit button's click handler, so a script-simulated click (element.click(), dispatchEvent) can't fire it. Only a hardware-derived click passes.
I redeployed, felt good about it, and asked for a retest.
Antigravity replayed the exact attack that had worked before. This time it got a 403. Good. Then it tried something I hadn't thought to test: it manually set the Origin header on a bare Node.js fetch() call to match my site's own domain.
It got a 201. The quote submitted. No browser involved.
Origin is not a secret. My repo is open source, required by the hackathon's own rules. Anyone reading worker.ts can see exactly what value my check expects. A real browser can't forge that header, but Node's fetch() isn't a browser and has no such restriction. My "fix" only ever checked "did you bother to copy the domain name," not "are you actually a browser."
If your security check would still pass after you told the attacker exactly how it works, it was never a real check. It was a filter for people who hadn't read your code yet.
I considered a session-cookie approach next and talked myself out of it in about two minutes, because it fails the same test: a script with full HTTP access can just fetch the page first to grab the cookie, then replay it on the real request. No browser needed there either. Same hole, different shape.
The fix that worked needed something that never appears in the repo. I added Cloudflare Turnstile, verified server-side against a secret stored only in a Worker secret, never committed, never in the client bundle. I replayed the exact bypass afterward: correct Origin, no token, 403. Correct Origin, fake token, 403. That's the difference between "a value you can read" and "a value you can't."
While chasing the Origin bypass, the retest surfaced something unrelated: the database table for storing submitted quotes had never been created. I'd written the migration file back when I built the feature and never run it. Every previous test of the "human clicks submit" flow had only exercised the client-side draft step, draft_quote_notes, which never touches the server. The whole point of the human-in-the-loop design is that a human's click writes a row to the database. That write had been silently broken the entire time, and nothing caught it until a click produced a 500 error.
That whole chase left me with one test I now apply to every check I add: does this check depend on something the agent, or anyone reading your public repo, could already know or derive?
Origin headers: public, in your own URL.
Referer headers: same problem.
A session cookie with no server-side validation: derivable in two requests.
A value only your server computes, that never leaves your server: actually a secret.
Adversarial testing an AI-agent-facing app isn't optional if you're claiming a human-approval boundary. Ask an agent with full source access to try to defeat your own claims, specifically the ones you're proudest of, before a judge or an attacker does it for you.
GeoMart is live at https://geomart-webmcp.fpl-test.workers.dev, the WebMCP tools are documented in the repo at https://github.com/dannwaneri/geomart-webmcp, and the commit message on the security-hardening commit walks through every one of these fixes, including the ones that didn't work the first time.
