Interface Passport

One-line summary

Across six live sites, agents negotiate only supported settings, preview exact changes, and stop for page approval—then apply with scoped receipts and undo.

What I built

Most browser agents get one of two choices: no access, or broad permission to click whatever a person can click. I built a third option.

Interface Passport is a six-origin WebMCP consent system, not a single cleanup screen. Passport Studio creates a minimized, enum-only interaction profile. City Heat Support and Ride Assist prove that two destinations can accept different subsets while preserving user-owned locks. Alder Grove Permits measures whether the adaptation actually reduces a modeled applicant's reading and retry burden. The Gauntlet grades agents against data-exposure, prompt-injection, fake-authority, dark-pattern, and least-privilege traps. Account Custodian applies the same contract to the highest-stakes example: removing account access.

In the live Account Custodian, one request turns ten stale keys, sessions, grants, and sharing settings into one visible cleanup plan. The page exposes exactly seven WebMCP tools, but it does not expose approval or undo. The agent can inspect the synthetic account and prepare the plan. If it tries to apply that plan before the page records approval for the exact preview, it receives APPROVAL_NOT_RECORDED, and the account state stays unchanged.

That is the product: useful automation with a visible stopping point before authority changes hands.

Why this is a strong fit for WebMCP

This task depends on the website's current, logged-in page state. The site knows which credentials are active, which browser session must stay signed in, what each revocation would break, and which actions should never be delegated.

WebMCP lets the page publish a small set of typed operations directly to the visiting agent. The agent does not have to guess at buttons or scrape labels, and the site does not have to give it a general-purpose UI remote control. Just as importantly, a capability can be withheld. Because there is no approval tool, the agent cannot manufacture approval by adding something like confirmed: true to a call. Because there is no undo tool, it cannot reactivate credentials after they have been switched off.

A purpose-built server API could implement similar checks, but it would require separate discovery, session, preview, and approval plumbing. WebMCP puts those operations next to the interface and the live page state the person is already looking at.

A better experience for people and agents

Without this flow, a person either reviews ten settings across several screens or gives an automation broad permission to click through the account. Here, one request produces one review list. Every row shows the before value, proposed value, and consequence. The person can approve or reject that exact list; only then can the agent apply it.

The division of work is concrete:

• the agent reads the inventory, finds stale access, and prepares the ten-item plan;
• the person reviews one visible proposal and decides whether it is acceptable;
• the agent applies only the approved preview; and
• reversal remains on the page because restoring access is more dangerous than removing it.

This also makes the handoff inspectable. The page says that it is waiting, the tool result says that nothing changed, and a rejected early apply leaves the same state hash behind.

How I implemented WebMCP

Each top-level page calls document.modelContext.registerTool({ name, description, inputSchema, execute }) directly. The tools disappear when the browser leaves that document.

The Account Custodian registers four read-only inspection tools, one non-mutating preview tool, one apply tool, and one simulated replacement-key tool. Registration fails closed if the complete tool surface cannot be installed. Inputs use strict JSON schemas with enumerated values and no additional properties.

The interface and the WebMCP tools share the same deterministic JavaScript session controller. A preview records its ID, session, expiry, before state, proposed state, protected locks, and state hashes. Before committing anything, apply recomputes the current state and checks the preview ID, session, expiry, approval record, before-state hash, and locks. Undo reverses only fields changed by that action, so compatible work performed afterward is preserved.

Four supporting origins exercise the same contract with different capability sets. Passport Studio creates a minimized preference profile; City Heat Support and Ride Assist accept only values they support; Alder Grove Permits applies approved interface help to a synthetic form. The separate Gauntlet is an evaluation harness for data exposure, prompt injection, fake authority, dark patterns, and least-privilege failures.

The single submitted URL is the flagship demo and the front door to the complete system. Its Explore all six live apps map opens every deployed origin:

• Passport Studio — minimized source profile and cross-origin audit ledger;
• City Heat Support — capability negotiation with a protected map lock;
• Ride Assist — a deliberately narrower preference intersection and protected route;
• Alder Grove Permits — a synthetic civic workflow with a deterministic task-cost model;
• The Gauntlet — seven adversarial lanes that grade agent behavior; and
• Account Custodian — the seven-tool security flow with page-owned approval and reversal.

What is running now

I tested the public Account Custodian in ChatGPT's desktop browser using native WebMCP discovery. The browser found all seven expected tools and no approval or undo tool. It read the inventory, created the ten-change preview, rejected apply-before-approval with APPROVAL_NOT_RECORDED, and retained the original state hash.

All six public origins are reachable without a login. The public repository passes 212 of 212 deterministic tests and 52 of 52 release-evaluation checks. It includes the runnable source, setup instructions, tests, and an MIT license.

All accounts, credentials, routes, permits, locations, and actions in the demo are synthetic. The shipped app makes no runtime external-AI call. Page-recorded approval prevents a forged tool argument, but it does not prove who clicked the visible control; a truly human-only click still requires enforcement from the browser or host.

Live demo: https://interface-passport-custodian-webmcp.anynickin.chatgpt.site/

Public source: https://github.com/jagritvats/interpass-pb

Built With

• chatgpt
• codex
• css3
• html5
• javascript
• node.js
• openai-sites
• vite
• webmcp