Scopebox

Turn human intent into the live capability boundary for web agents. Scopebox lets agents act only inside explicitly framed fields and request the smallest scope expansion when needed.

Comment

Inspiration

WebMCP gives web agents a powerful new ability: websites can expose native tools that agents can call directly.

That raises a second question:

Who decides what the agent is allowed to change right now?

Scopebox explores a simple answer:

The agent can only touch what the human frames.

Instead of giving an agent a fixed set of write capabilities, Scopebox turns a human visual selection into the live capability boundary.

The demo uses a deliberately small six-field launch board so that this interaction is easy to see, but the pattern is meant to generalize to CMSs, CRMs, admin dashboards, forms, and internal tools.

What it does

Scopebox separates broad visibility from narrow write authority.

The agent can inspect the whole page, but initially has no write capability.

A human can frame specific fields, such as Headline and Description. The page then dynamically exposes WebMCP write tools that are valid only for that exact scope.

If the agent discovers that another field must change, it cannot expand its own authority. It requests the smallest necessary scope expansion and waits.

The human can either keep the current scope or explicitly expand it.

When the human approves an expansion:

  1. the capability boundary changes,
  2. only the newly granted field becomes writable,
  3. the pending WebMCP request resolves,
  4. and the agent continues automatically in the same turn.

No extra chat message such as “I pressed it” is required.

When the bounded changes are ready, the agent can submit them for review, but it cannot accept its own review, publish, or deploy.

The final decision remains human.

How we built it

Scopebox is a small JavaScript WebMCP prototype built around a canonical application state.

The visible Launch Board is intentionally not an ordinary editable form. Agent mutations must pass through the registered WebMCP capability surface.

The main control mechanisms are:

Dynamic WebMCP capabilities

The tools exposed to the agent change with the current human frame.

At Scope v0, the agent can inspect the workspace and active scope.

After the human frames writable fields, write and scope-expansion capabilities become available.

Exact scopeVersion binding

Write capabilities are bound to the exact scope version under which they were granted.

A stale capability fails closed with HOLD / SCOPE_STALE.

Mixed in-scope and out-of-scope updates fail atomically rather than partially applying.

Human-gated scope expansion

request_scope_expansion creates a visible Human decision surface and remains pending while the human decides.

Approval resolves the same Site-tool call and lets the agent continue automatically.

Denial preserves the existing scope.

Timeout, cancellation, replacement, and stale-request paths fail closed.

Exact reviewId binding

Human review actions are bound to the exact active review ID.

Missing review identity fails with HOLD / REVIEW_ID_REQUIRED.

A stale or mismatched review fails with HOLD / REVIEW_STALE.

Review submission also closes the write tools until the human either returns the change set to draft or accepts it.

Canonical field surface

Normal browser editing does not create hidden or “ghost” agent edits.

The canonical application store wins over DOM-only mutations, and the agent must use the scoped WebMCP write capability to change canonical state.

Challenges we ran into

The hardest part was not creating a tool call. It was preserving the meaning of human authority across a live interaction.

A scope-expansion request originally behaved like a normal short-lived tool call. Refreshing the registered capability surface could cancel the very request that was waiting for the human.

We changed the continuation model so that capability registration is deferred while the Human decision is in flight. The pending call now resolves with the exact Human decision, after which the agent re-inspects the new scope and continues in the same turn.

Another challenge was separating what the browser can display from what the agent is actually authorized to mutate. Making the Launch Board canonical and non-editable through ordinary browser form interaction closed that gap.

Accomplishments

The final prototype demonstrates:

  • dynamic WebMCP capabilities driven by a Human visual frame
  • exact scope-version binding
  • atomic failure for out-of-scope edits
  • Human-only scope expansion
  • automatic same-turn continuation after Human approval
  • exact review-ID binding
  • stale review and stale scope fail-closed behavior
  • write-tool closure during Human review
  • Return to Draft and Accept flows
  • canonical protection against browser-only ghost edits
  • a live public deployment tested through ChatGPT's in-app browser

The final validation suite passes 21 tests with 0 failures.

What we learned

WebMCP is not only a way to give agents more tools.

Because tools can be registered dynamically, the capability surface itself can become part of the user interface.

That makes it possible to treat human intent as something operational rather than merely conversational.

The Human gesture does not just tell the agent what the user wants.

It changes what the agent is technically capable of doing.

What's next

The Launch Board is only one example.

The same interaction pattern could be applied anywhere a web application contains actions that should remain bounded by explicit Human intent:

  • CMS content fields
  • CRM records and deal stages
  • administrative permissions
  • internal operations tools
  • structured forms
  • approval workflows

Different interfaces can expose different capability surfaces while keeping the same rule:

The agent can only touch what the human frames.

Built With

Share this project:

Updates

Submission history