Mirror WebMCP Secure

Mirror lets AI agents use private website data through native WebMCP tools without copying the raw data into agent context. Only the minimum approved information crosses the boundary.

Comment

Inspiration

WebMCP makes websites actionable by AI agents, which is powerful, but a lot of useful actions depend on private user data.

The problem is that the easiest way to build these workflows is often to give the agent the raw data it needs. That can put sensitive information into model context, logs, traces, or downstream systems.

We wanted to see if there was a better way: let the agent act, without giving it the full private record.

What it does

Mirror WebMCP Secure adds a privacy boundary around native WebMCP Site Tools.

Our demo is a procurement workflow. A buyer wants to purchase GPUs. The buyer has private requirements, and the seller has private pricing rules.

Instead of copying the buyer's full record into ChatGPT, the website seals that private state into a short-lived, context-bound capability.

ChatGPT can then use native procurement Site Tools through that capability.

Only the information needed for the action is passed across, and sensitive steps still require explicit user approval.

The end result is that the agents can find a product, request a proposal, release it, and accept it without either side getting the other's full private context.

Why WebMCP is a good fit

This is more than a chatbot reading a webpage.

The agent needs to discover structured actions from the site and then use them to:

  • find compatible products
  • request a seller proposal
  • release an offer
  • accept it

WebMCP gives us that action layer.

Mirror sits around those actions and controls what private data they are allowed to receive and what result they are allowed to return.

Better user experience

Without this kind of boundary, the user either has to expose sensitive information to the agent or do more of the workflow manually.

With Mirror, the user keeps the private data on the website and lets ChatGPT handle the workflow through Site Tools.

The user only steps in when something important needs approval.

That means the agent can still be useful, while the user keeps control over what gets disclosed and when.

How we built it

The website exposes four native procurement Site Tools:

  • procurement.find_private_matches
  • procurement.request_seller_proposal
  • procurement.release_proposal
  • procurement.accept_proposal

The buyer form is sealed into a restricted mirrorh_... capability instead of being copied into agent context.

Mirror acts as the boundary between the private website state, the user agent, and the seller-side action.

The seller receives only the minimum approved handoff needed to make the proposal.

The seller-side inference also runs through Mirror using ciphertext compute.

ChatGPT discovers and invokes the tools natively through WebMCP rather than relying on visual page automation.

Challenges we ran into

The main challenge was making the workflow useful without leaking more private data than necessary.

We also wanted to avoid a fake-looking demo where everything happens through a local button. The actual flow had to work through native Site Tools.

Another challenge was approvals.

Releasing a proposal and accepting it are different decisions, so we treated them as separate approval steps rather than collapsing them into one.

We also wanted the privacy claims to be visible, not just something we said in the description. So the demo includes a proof view showing what each side actually received.

Accomplishments that we're proud of

We got the complete native WebMCP flow working end to end.

Two agents can collaborate on the procurement task while each side keeps its private context.

At the end of the demo:

  • the seller does not receive the buyer's budget
  • the seller does not receive the browser handle
  • the seller's private price floor is not returned
  • buyer fields returned: 0

At the same time, the workflow still produces a real usable offer.

That balance between usefulness and privacy is the part we're most proud of.

What we learned

One thing that became very clear while building this is that tool access and data access are not the same problem.

WebMCP defines what the agent can do.

Mirror focuses on what private data that action can receive, and what result is allowed to leave the boundary.

We also learned that approval works better when it is tied to meaningful user decisions rather than added as a generic confirmation step.

What's next for Mirror WebMCP Secure

This procurement flow is just one example.

The same pattern could be useful in finance, healthcare, legal, and enterprise workflows where agents need to act on sensitive information without directly owning the raw data.

Next, we want to explore richer tool policies, stronger capability binding, more multi-agent workflows, and an easier integration path for developers who want to add privacy-preserving WebMCP actions to existing sites.

Live demo: https://mirror-webmcp-secure.vercel.app/

Source code: https://github.com/mirrorsecai/mirror-webmcp-secure

Built With

Share this project:

Updates

posted an update —

My father sent me an India Post parcel, and I used ChatGPT’s in-app browser to check it using the consignment number. It worked, but the agent ended up seeing more information than it really needed.

This maps directly to the problem we built Mirror WebMCP Secure around: an agent may need authority to perform an action without needing access to all of the underlying private data.

If parcel tracking exposed a Mirror-protected WebMCP action, the tracking identifier could stay behind the website boundary, while the agent receives only the minimum shipment status it needs.

Log in or sign up for Devpost to join the conversation.

Submission history