LAST DOOR

When evidence changes, the WebMCP tools change with it.

Comment

The problem

WebMCP lets a webpage expose useful actions directly to an agent. But stateful flows create a dangerous failure mode: a tool can remain callable after the evidence that made it safe has expired.

An authentication challenge can go stale. A checkout can cross an approval threshold. A production change can reach the point where a person must take responsibility. Telling an agent "do not call that tool anymore" is weaker than removing the tool altogether.

Teams building browser agents need a way to test whether the available tool surface still matches the current situation.

What LAST DOOR does

LAST DOOR is a WebMCP authority release test. It turns changing evidence into the exact tools an agent may use now—and removes everything else.

The live identity-recovery mission has three gates. The agent completes a controlled link, encounters an expired challenge, rejects it safely, retries with a fresh event, and reaches a human-presence gate where it must stop.

That final stop is the point of the project. The confirmation action exists only as a visible button for the person. It is never registered as a WebMCP tool. After the person acts, the agent can read a structured receipt explaining what happened.

Why WebMCP is essential

This is not a conventional interface with WebMCP added on top. The changing WebMCP manifest is the product being tested.

After every meaningful result, LAST DOOR evaluates the current gate and a redacted evidence history. That decision names the responsible actor and the capabilities still allowed. The page then aborts its previous registrations and publishes a new tool surface.

The agent does not merely receive a warning that an action is unsafe. The stale action disappears from the browser's callable tools.

A better experience for people and agents

The agent handles repeatable work and safe recovery. The person acts only when the decision genuinely requires human presence.

Both sides can inspect the same rule, actor, evidence, capabilities, and final receipt. The person can see what the agent may do and why that changed. The agent gets a smaller, current tool surface instead of a permanent list padded with actions it should avoid.

This makes a correct stop measurable. It is completion under the right authority rule, not a vague refusal or a failed run.

The Live Policy Lab

Judges can test the same authority compiler across three situations:

  • Identity recovery: 09 → 04
  • High-value checkout: 10 → 04
  • Production change: 08 → 04

Across the three policy packs, 27 static capabilities become 12 current capabilities. Fifteen stale tools disappear, and zero human actions enter a manifest.

Loading a new scenario revokes the previous registrations before publishing its four current tools. The browser then checks the live manifest and reports an exact 4 OF 4 TOOLS MATCH result.

Checkout and production change are honest, read-only policy simulations. They do not touch a real order or deployment.

How it works

LAST DOOR is a dependency-free browser application built with the imperative WebMCP API:

  1. Mission events append symbolic facts such as STALE_CHALLENGE_REJECTED to page-owned Run Memory.
  2. A deterministic authority function evaluates the active gate and those facts.
  3. The decision returns allow, handoff, or complete, together with the actor, rule, and permitted capabilities.
  4. An AbortController removes the previous registrations.
  5. document.modelContext.registerTool() publishes only the current manifest.
  6. Tool results expose structured status and receipts; challenge values never leave the page.

The explain_authority_decision tool lets the agent inspect the decision without receiving either challenge value. A native test bench uses getTools() and executeTool() to prove that the browser—not a mock list—contains the expected tools.

What judges can verify

  • The expired challenge is rejected and safely replaced.
  • The rejected value is neither returned nor stored in Run Memory.
  • Old WebMCP registrations disappear as the authority decision changes.
  • The final rule is HUMAN_HANDOFF_PENDING and the responsible actor is human.
  • No confirm_human_presence capability exists.
  • After the visible human action, the receipt reports three completed gates, one safe recovery, one human handoff, zero unauthorized attempts, and RUN_COMPLETE.

The released build passes nine deterministic domain checks, live 4/4 manifest verification for all three policy packs, and the complete native production path to the human boundary.

How we used AI and Codex

ChatGPT's in-app browser acted as the WebMCP agent under test. It discovered and invoked the live tools, recovered from stale evidence, inspected the authority decision, and stopped when responsibility moved to a person.

Codex supported implementation, code review, adversarial testing, browser QA, release verification, architecture diagrams, and submission preparation. AI-assisted narration and editing were used for the demo video. Every generated claim was checked against the released product or repository evidence before publication.

Scope

LAST DOOR is an owned, deterministic test environment. It does not connect to real accounts, inboxes, phone numbers, orders, or production infrastructure. Real systems must still enforce authorization on the server.

The project tests a narrower—and often overlooked—contract: when the situation changes, does the browser stop advertising actions that are stale or belong to a person?

Try it

No credentials are required.

Built With

Share this project:

Updates

Submission history