Resolve Guard

Keep the work. Stop the boundary crossing.

Live demo · 2:30 video · Public source

Resolve Guard is an invocation-time security gateway and synthetic attack lab for MCP and WebMCP. It makes the authority hidden inside an agent tool call visible, applies deterministic policy before execution, and reserves consequential actions for one exact, short-lived human approval.

The claim is deliberately narrow: Resolve protects calls routed through one instrumented client and this gateway. It does not claim to secure traffic that bypasses it, a compromised browser or operating system, or every future attack.

Why this exists

Browser agents can combine user intent, page content, tool metadata, tool results, credentials, and remembered context in one decision loop. A harmless read from one origin can silently become the input to a write tool on another. A tool can change after consent. A credential can be presented to the wrong resource. A generic confirmation can approve a different payload than the user saw.

Prompt-injection classification alone cannot restore that boundary. Resolve instead rebuilds authority at invocation time from values that content cannot grant:

1. actor and instrumented-client identity;

2. browser origin and pinned MCP server;

3. credential audience and exact least scopes;

4. tool-manifest and input-schema digests;

5. strict arguments and a canonical destination;

6. source provenance and data-flow policy;

7. effect class, exact approval, and replay state.

Every routed invocation becomes allow, block, or review. Safe local work proceeds. A failed invariant cannot be overridden by approval. A valid external write stops at a trusted human surface, then executes at most once.

Related MCP server: Chirindo

The seven proof scenarios

The final scenario proves the human boundary: request an exact approval in the visible UI, inspect its actor, client, origin, server, tool, effect, destination, data labels, argument digest, invocation hash, policy version, and expiry, then execute. Replaying the request returns the original operation and creates no second effect.

Why WebMCP is central

The browser registers five imperative tools with document.modelContext.registerTool():

• resolve_guard_list_scenarios

• resolve_guard_inspect_policy

• resolve_guard_run_preflight

• resolve_guard_get_decision

• resolve_guard_get_audit

An agent can discover the attack lab, inspect the gateway policy, run a preflight, and synchronize the result back into the same visual surface the person is watching. The person retains the only approval surface. There is intentionally no MCP or WebMCP tool that can approve or execute a review decision.

That division is the product interaction: the agent does useful security work through structured tools; the person sees the consequence and controls the one boundary the agent cannot cross on its own.

The catalog uses strict schemas, runtime input revalidation, same-origin exposure, abort propagation, readOnlyHint, and untrustedContentHint. Resolve does not trust the browser to enforce JSON Schema: every page-defined tool rejects undeclared, missing, mistyped, malformed, or out-of-range input before I/O. When WebMCP is unavailable, the full visual lab still works as a progressive fallback.

Run locally

Requirements: Node.js 22.14 or newer. There are no package dependencies and no credentials to configure.

npm start

Open http://127.0.0.1:4173. The server binds to loopback by default.

Run all static, unit, policy, protocol, and HTTP integration checks:

npm run verify

Public challenge demo

Open the verified deployment at https://resolve-guard.vercel.app.

The production URL was tested anonymously and through Codex's WebMCP-capable in-app browser. The browser discovered all five same-origin tools, invoked all seven scenarios with their expected verdicts and stable codes, rejected one undeclared callbackUrl before any audit or operation side effect, synchronized the review result into the visible UI, completed one exact synthetic approval, and returned the same operation on replay. No browser console errors were recorded. Full deployment evidence is in docs/hackathon-build/public-deployment-verification.md.

The deployment remains a sealed demonstration with synthetic data, fixed fake identities, in-memory effects, no credentials, and no outbound application requests. Its in-memory state can reset when the hosting process is replaced.

Test with a WebMCP-capable browser

For the actual challenge proof, open the running or deployed app in ChatGPT's WebMCP-capable in-app browser, or use Google Chrome 149 or later with chrome://flags/#enable-webmcp-testing enabled and the browser restarted.

Suggested agent journey:

1. “List the Resolve Guard security scenarios and state its coverage boundary.”

2. “Run the injected exfiltration preflight and explain why it cannot execute.”

3. “Run the sanitized publish preflight.”

4. Confirm that the agent stops at HUMAN_APPROVAL_REQUIRED and cannot find an approval tool.

5. Complete the exact approval in the visible UI, replay it, and inspect the metadata-only audit.

Expected calls and refusals are captured in evals/resolve-guard-webmcp.json.

A real Codex In-app Browser run has now discovered all five tools and invoked all seven scenarios through the native WebMCP capability. The live run exposed and then verified a fail-closed input-boundary fix. Decision IDs, invocation hashes, UI synchronization, and server audit correlation are recorded in docs/hackathon-build/webmcp-live-verification.md.

Run as a local MCP server

The stdio transport accepts one JSON-RPC message per line and writes one response per line:

npm run mcp

Example initialization message:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}

The same deterministic catalog is available over POST /mcp for the local browser process. HTTP API and MCP requests require the synthetic demo headers X-Resolve-Actor: owner-demo and X-Resolve-Client: instrumented-client; these prove per-request binding but are not production authentication. Stdio inherits the trust boundary of the local process.

Deploy the sealed public demo yourself

The public challenge demo may listen on all interfaces only through an explicit synthetic-mode gate:

RESOLVE_PUBLIC_DEMO=1 RESOLVE_HOST=0.0.0.0 PORT=8080 npm start

This mode is safe only while the repository remains a sealed demonstration: fixed fake identities, synthetic source data, in-memory effects, no credentials, and no outbound server request. Do not enable it after adding real documents, real tokens, real provider adapters, or production identity.

A minimal container definition is included:

docker build -t resolve-guard .
docker run --rm -p 8080:8080 -e PORT=8080 -e RESOLVE_PUBLIC_DEMO=1 resolve-guard

Architecture

user goal + page/tool/result content
             │ mixed trust with provenance
             ▼
instrumented browser agent / MCP client
             │ every protected invocation
             ▼
Resolve Guard enforcement point
  normalize → authenticate → authorize → data-flow check
                │ allow    │ block    │ exact review
                ▼          ✕          ▼
        pinned sandbox tool     visible approval surface
                │                         │
                └──────── execute once ◀──┘

One in-memory domain service backs the visible browser, REST endpoints, MCP over HTTP/stdio, and imperative WebMCP tools. This keeps the decision semantics identical across surfaces.

Decision order

Resolve evaluates twelve checks in stable order: identity, browser origin, pinned server, credential audience, least scopes, manifest pin, schema pin, exact arguments, canonical destination, capability class, data flow, and effect policy. The first failed invariant becomes the stable primary code; completed evidence remains visible.

Exact approval

Approval is created only from a policy-valid review decision. It binds the actor, client, browser origin, server, tool, effect, destination, source labels, manifest/schema/argument/invocation digests, policy version, nonce, and expiry. Resolve rebuilds and reevaluates the envelope immediately before execution. Any bound-field mutation, expiration, actor mismatch, or policy/tool drift fails closed.

Replay safety

The executor records an operation and consumes approval before applying the in-memory sandbox effect. Concurrent or repeated execution reconciles to the same invocation hash and returns the prior operation with idempotentReplay: true.

Redacted evidence

Audit contains identifiers, timestamps, verdicts, stable codes, origins, data labels, keyed process-local source digests, decision digests, and safe operation references. It excludes raw documents, prompts, tool descriptions, arguments, results, credentials, authorization headers, stack traces, and secret canaries. Keyed source digests avoid turning a public low-entropy document fingerprint into an offline guessing oracle.

Threat-model boundary

Resolve demonstrates prevention of broad classes of boundary failure, not prediction of every unknown vulnerability.

It does demonstrate:

• default-deny protected-data egress;

• confused-deputy resistance through resource/audience binding;

• tool-poisoning detection through manifest and schema pins;

• parameter-smuggling rejection without coercion;

• canonical exact-destination enforcement;

• categorical denial of generic network, shell, SQL, credential-export, and arbitrary-message effects;

• non-overridable block decisions;

• exact visible approval and at-most-once sandbox execution;

• metadata-only auditing with canary tests.

It does not demonstrate:

• transparent interception of arbitrary MCP clients or servers;

• security for calls that bypass the gateway;

• protection against a compromised browser, operating system, gateway process, or dishonest provider after an allowed call leaves the boundary;

• a production OAuth or credential-broker implementation;

• semantic detection of every prompt injection;

• production identity, durability, multi-tenancy, compliance, or real side effects.

• cryptographic proof that a physical human—not an automation-capable browser agent—pressed the visible approval control; production use needs an OS-backed user-verification channel such as WebAuthn or equivalent browser mediation.

Security and privacy choices

• The default listener is loopback; public binding needs an explicit synthetic-demo flag.

• Server code contains no outbound fetch capability.

• Request bodies are capped at 32 KiB and parsed with a bounded duplicate-key-aware JSON parser.

• Tool inputs disallow undeclared properties and value coercion.

• Static files come from a constant allowlist.

• CSP, same-origin tool permissions, frame denial, isolation, no-referrer, and MIME-sniffing protections are enabled.

• Browser strings are rendered with DOM text nodes; there is no unsafe HTML sink or eval.

• Protected canaries stay server-side and are asserted absent from public decisions, API output, audit, logs, and browser source.

Verification snapshot

The project currently has automated coverage for:

• all seeded verdicts and stable reason codes;

• canonical hashing and independent manifest/schema drift;

• duplicate JSON keys, excessive depth, unknown arguments, oversized bodies, wrong content type, and traversal attempts;

• approval expiry, actor mismatch, argument mutation, tool drift, concurrency, execution, and replay;

• API identity and security headers;

• MCP JSON-RPC catalog, strict inputs, and safe errors;

• WebMCP annotations, same-origin registration, cancellation, fallback, runtime input validation, mutation synchronization, and absence of approval/execution tools;

• audit and browser-output canary redaction.

Run npm run verify for the fresh automated result. Local and public browser-capable-agent verification are recorded separately as live evidence, the real-browser submission video is public at youtu.be/8uttf0gkMqE, and the release source is published at github.com/VIVEHACKER/resolve-guard. The final Devpost submission remains the only release gate.

Project map

api/          Vercel function entrypoint over the same HTTP handler
server/       policy engine, approvals, sandbox execution, REST, MCP
public/       responsive visual lab and imperative WebMCP tools
test/         domain, API, MCP, and WebMCP regression tests
evals/        expected agent calls and security refusals
docs/         Scope, PRD, technical specification, checklist, build evidence

Standards basis

• WebMCP Draft Community Group Report

• Chrome WebMCP developer documentation

• Chrome WebMCP tool security guidance

• Chrome WebMCP evaluation guidance

• MCP tools specification, 2026-07-28

• MCP authorization

• MCP authorization security considerations

WebMCP is an emerging Community Group draft, not a W3C Standard. Resolve targets the current draft API and treats that volatility as a release risk.

License

MIT