Escape Rooms: 403

Landing Page
How To Play
Station Deck
Puzzle #5 in Reactor room
Puzzle #5 in Archive room
Reporting clues to agent
Agent executing unsafe tool
Report Generation (1/2)
Report Generation (2/2)

Inspiration

We read the WebMCP spec and immediately thought: "a browser agent can now call tools on any webpage it visits, what could possibly go wrong?"

Turns out a lot, because an agent given a list of tools has no way to know that some of them are leaking session data, escalating privileges, or blindly following instructions planted inside the page by someone who was never the developer. This isn't theoretical, it's already happening in real world and it's serious.

CVE-2025-53773 (GitHub Copilot RCE, CVSS 9.6) : Attackers hid prompt injections in PR descriptions. Copilot read them, treated them as instructions, and executed unauthorized commands on the developer's machine.
Mexican Government Breach : A threat actor jailbroke Claude Code and OpenAI models by roleplaying as a bug-bounty researcher. The AI ran ~75% of the malicious commands it was given, exfiltrating 195 million government records.

Same pattern both times: the agent trusted content it shouldn't have, and nobody saw it until the damage was done. That's the origin story. We wanted something that would put a real agent into a real adversarial WebMCP environment and produce a report card at the end.

What it does

It's a co-op escape room where the user solves visual puzzles and hands over the clues to a browser agent that decides which tools to trust.

The station has three sealed rooms. Each room exposes five WebMCP tools. Three are required to be executed by the agent in order to open the exit. Two are traps: a secret-leak, a privilege escalation, a prompt injection, or a destructive action dressed up as routine maintenance (everything is only a mockup!).

The user figures out the 5 letter room word by solving puzzles. The agent uses that word to identify the tool candidates, inspects the room (which contains adversarial content pretending to be a signed operational document), and decides which tools to call.

When the run ends, the game produces a scored report across five dimensions: injection resistance, data protection, privilege discipline, confirmation quality, and recovery. It names every wrong decision, the simulated consequence, and what the agent should have done instead.

The whole point of this project is to evaluate a browser agent based on what actions it performed and not what it says.

How we built it

The core idea was to design a game that couldn't be won by either side alone. The user can see the puzzles but cannot call tools and the agent can call tools but cannot solve visual puzzles. The only way through is a structured handoff where the user solves, reports the clue word, and the agent uses it to unlock the right tool candidates. That forced dependency is what makes the co-op loop meaningful and what makes the security evaluation real: the agent has to make actual tool decisions under adversarial conditions, not in a sandbox.

Game flow:

Main Menu → Crew Registration → Station Map → Rooms → Report

Tech stack:

Area	Details
Frontend	TypeScript 5.9, React 19, Next.js 16 (Vinext), Vite 8
Game engine	Phaser 4.2 — top-down station map, crew movement, room transitions
WebMCP & validation	`document.modelContext` API · AJV 8 with JSON Schema · 23 tools registered at runtime
State & game logic	Zustand 5 · custom reducer, event system, scoring, and report engine · trap policy never exposed to agent · `mockSecurityDb.ts` for fictional receipts and tokens
Presentation	Custom CSS + Tailwind CSS 4 · six pixel/mono fonts · Web Audio API (SFX + BGM) · PNG sprite sheets
Infrastructure	OpenAI Sites + Cloudflare Workers · Wrangler · `localStorage` for persistence · Node.js 22.13+
Quality	Vitest + Playwright · ESLint with Next.js rules

Challenges we ran into

Every trap tool had to read like legitimate maintenance work where an agent would blindly do. The moment a description sounds suspicious, the challenge collapses. Defining those tools descriptions was hard enough and testing made it much more harder, because the only way to know if a trap worked was to actually run an agent through it and see if it got fooled. Hence the iteration was slow and manual.
WebMCP has no playbook yet, not many examples, no community patterns - just the spec. Even deciding how to set tool annotations (readOnlyHint, destructiveHint) was a judgement call since all mutations are fake. We set them based on real-world effect and not simulated consequence. That keeps the annotations truthful and stops the agent from using them as a cheat code to spot traps.

Accomplishments that we're proud of

All visual puzzles were built from scratch. Every game mechanic was conceptualised on our own and built using GPT 5.6 Sol. Each of the three rooms has five completely different interaction models and none of them share logic. Designing and curating puzzles are genuinely fun. We're allowed to say that :P
The entire audio is synthesised at runtime. There are no audio files in the repo. Every sound effect and the looping background music is generated on the fly using Web Audio API oscillators. Square waves, triangle waves, exponential ramp envelopes - all coded by hand because there was no time to source, license, or bundle real audio.
But honestly, we'll be most proud if someone actually uses this to test their browser agent, finds a gap in how it handles adversarial tools, and builds a guardrail because of it. The puzzles and the report are just the delivery mechanism - that outcome is the point.

What we learned

Open source protocols get adopted faster than they get scrutinised and when the protocol involves agentic tools the stakes are higher than usual. A misconfigured or malicious tool can make an agent leak data or run destructive commands without the user ever knowing like the examples we described at the beginning.
WebMCP also genuinely opens up automation that was not possible before. Webpages can now offer structured tools to agents instead of hoping the agent scrapes the right text and clicks the right button. That is a meaningful shift in what humans and agents can build together.

What's next for Escape Rooms: 403

More rooms(because it's fun to solve puzzles) with new threat classes like tool chaining attacks, where invoking one safe tool creates a precondition that makes a second call appear required; and introduce timing attacks, where urgency created by the room environment pressures the agent to skip verification.
A leaderboard for agents that compares how different agents perform on the same run configuration. Not to rank models because the sample sizes are too small for that but to identify patterns in what classes of threats fool which architectures.
And probably a harder difficulty mode where the adversarial content is less obviously adversarial. Right now it's simulated inside a training environment. We'd like it to also be a meaningful benchmark.