Inspiration

Agents should be able to do useful housekeeping tasks on your browser without acting like they own the mortgage, and without requiring the user's banking credentials to do it (unless of course, you give it explicit permission!). An agent can be helpful without being given a giant blob of access, but only if the boundary stays visible; doA2Ai explores a practical version of that idea: give an agent the tools needed for the current task, keep consequential decisions with the person, and verify that the result still matches what the person authorized. The goal is not less agent capability; it is more precise capability and user support through agency.

Why WebMCP

WebMCP gives the model an easy way to expose structured tools for the task that exists. Instead of making an agent reverse-engineer buttons and visual state, the browser can present a page-scoped capability surface that can be inspected and constrained - like a www dot paint by number for agents. doA2Ai adds an authority boundary around that surface; the extension identifies the current HTTPS origin and tool definitions, applies local policy, and keeps human-only values and decisions out of the agent's authority. The capability surface and the review path change as the task changes, and the user is given the option to allow or deny certain permissions.

What people and agents can do together

The agent can inspect the current target's available WebMCP tools and prepare a bounded request. The person keeps the parts that are actually theirs: policy, human-only values, exact review, and the final decision. The result is an explicit set of outcomes: - an allowed action within delegated authority; - an exact action held for human review; or - a policy-blocked action that is not executed. Receipts record the proposal, decision, execution status, and verification state. If the candidate changes between authorization and execution, doA2Ai blocks the action and requires reauthorization instead of treating the change as close enough.

How it was built

The installable Chrome extension owns rules, task state, decisions, connection state, and receipt history locally. A deployable HTTPS service and read-only control center provide proof-of-possession device pairing, replay-resistant signed requests, short-lived device and task-scoped connection credentials, and terminal receipt-digest binding.

The service is a broker and control center, not an agent and not a WebMCP target. The real target remains a separate HTTPS page.

The public repository contains the extension, service source, product contract, and owner/judge runbook: https://github.com/kaileahmarin/doA2Ai I used ChatGPT through Chrome for WebMCP protocol invocation and Gemini for additional testing. The project was built and tested with OpenAI Codex.

Testing and limitations

The intended judge path uses Chrome with WebMCP enabled, the official WebMCP Coffee Store target, and a compatible browser-integrated agent. The runbook covers an allowed path, an exact human-review path, a blocked path, and receipt verification using harmless test data.

This is a V1 hackathon candidate, not a production authorization service. Mediation is cooperative: a client that bypasses the protected tool path can still call an ordinary page-owned WebMCP tool. OAuth protected-resource discovery, production tenant isolation, account recovery, and independent attestation of arbitrary page-owned effects are intentionally outside this slice.

What we learned

The hardest part was deciding exactly how to invoke user input when the candidate changes. Capability, authority, and outcome have to stay aligned. Human-only values cannot quietly leak into agent schemas or receipts. Authorization has to bind to an exact proposal, and uncertainty has to remain visible instead of being silently retried. That is the core idea behind doA2Ai: agents can do more without being given everything, while people keep authority over consequential actions.

Built With

Share this project:

Updates