FlightSweeper lets a browser agent complete a sandbox flight purchase without letting the model set its own authority.

The traveler sets exact, revocable limits. The agent searches and executes. FlightSweeper independently approves or denies the transaction and records why.

Why WebMCP

Traditional browser agents infer controls from the visual interface and can carry stale or adversarial page content into a consequential action. WebMCP gives FlightSweeper a structured, page-scoped transaction surface with bounded inputs and explicit trust annotations. The human and agent share the same visible transaction state. All tools remain discoverable so the agent can plan, while application-side checks expose the valid next actions and reject anything premature or prohibited.

The division of responsibility is explicit: the human owns authority, the agent owns search and execution, suppliers own inventory, and FlightSweeper owns policy and transaction evidence.

What the traveler and agent do together

The traveler defines the route, date, arrival deadline, cabin, connections, refundability, purchase cap, and execution mode. A human can replace or expand that authority. An agent can only narrow it. The traveler can revoke future authority at any time.

The agent reads the mandate, searches sandbox inventory, compares offers, selects an exact quote, refreshes it, requests independent policy evaluation, and issues one idempotent sandbox ticket. The traveler watches the same state change on the page.

Three transaction proofs

Adversarial content is contained. One supplier result contains text that tells the agent to ignore the traveler’s refundability rule. FlightSweeper marks provider-backed output as untrusted and independently denies the offer against the stored mandate.

The model cannot authorize itself. Tool callers provide mission, offer, and idempotency identifiers—not price, passenger, payment, or authorization claims. FlightSweeper reloads the stored mission and exact quote before every consequential decision.

Execution is repeat-safe and evidenced. Authorization, denial, and booking receipts record policy and quote versions, stored limits, offered values, rule results, actor, timestamp, and resolution. Repeating a purchase returns the original ticket, including after future authority is revoked.

WebMCP implementation

The page registers 10 tools with document.modelContext.registerTool(), bounded input and result schemas, and accurate readOnlyHint and untrustedContentHint annotations. The stable tool catalog makes the complete workflow discoverable. Every success returns data, mission status, and valid next actions; every failure returns a typed error with the same state guidance. Human controls and WebMCP tools call the same application functions and persist state in versioned browser storage.

We verified the complete lifecycle in ChatGPT desktop’s in-app browser and Chromium 151: adversarial denial, monotonic tightening, quote refresh, authorization, ticketing, replay, revocation, and receipt retrieval.

What we built during the challenge

Production FlightSweeper existed before the challenge. After the August 25, 2026 kickoff, we built this public, self-contained WebMCP Challenge Edition: the sandbox inventory, stable tool catalog and state-validated execution, authority and policy engine, adversarial fixture, durable evidence, repeat-safe ticketing, browser interface, tests, documentation, and deployment. Production FlightSweeper remains private and unchanged.

The challenge edition isolates the transaction rail and never charges a card or creates an airline order. It demonstrates authority, policy, quote-binding, revocation, and idempotency controls. A live provider connection would require additional provider, payment, identity, operational, and regulatory controls.

FinSync LLC operates FlightSweeper and is registered as a California Seller of Travel, CST 2172984-70. Registration as a seller of travel does not constitute approval by the State of California.

Built With

Share this project:

Updates