Research preview · Local enforcement

A policy between your agent and its tools.

Keep reviewed MCP tools available. Reject unapproved changes. Control where a supported browser can connect.

Explore a staging pilot See a request go through

Runs locally. No external analysis service. Tool payload logging off by default.

Read the technical brief

One route. Explicit decisions.

Illustrative flow. Browser egress requires the Chromium adapter.

Tested integrations

CodexPaper MCPPlaywright MCPRead the compatibility notes

Follow the decision

Useful tools in.
Unapproved requests out.

Choose a scenario to see where the policy applies. These examples illustrate the controls; they do not execute MCP calls.

Policy inspectorIllustration

Requested actionbrowser_navigate

{ "url": "https://example.com" }

✓ Reviewed tool contract

✓ Explicit call policy

✓ Supported browser route

Allowed by policy

The tool is approved and the destination matches the reviewed HTTPS origin.

Small surface. Specific controls.

Know what you are allowing.

Deterministic checks on the configured route. A narrow boundary you can inspect and test.

Keep tools on the list.

Explicitly allow the tool names your workflow needs. Requests for tools outside that policy are denied.

Tool allowlists

Pin what you reviewed.

Review and approve the tool catalog. An observed definition change blocks calls until a new approval is made.

Contract pinning

Put destinations in scope.

Check configured URL arguments. The optional Chromium adapter also blocks off-list browser TCP destinations.

Origin controls

Evidence before promises

We tested the bypass.
Then tested the fix.

Direct URL validation alone did not stop redirects or requests from page scripts. We reproduced the gap, added browser destination enforcement, and reran the same local receiver tests.

82automated tests passed in the October 20, 2026 regression run.

Read the technical brief

Controlled tests with fake data

Browser destination tests before and after the Chromium adapter
Attempt	URL checks only	With adapter
302 / 307 redirect	Reached receiver	Blocked
Page-script fetch	Reached receiver	Blocked
Image request	Reached receiver	Blocked
Allowed same-origin fetch	Allowed	Allowed

Zero off-list receiver hits in the hardened fixture. This is test evidence, not a claim of universal attack prevention.

The boundary matters

A control you can reason about.
Not a blanket security promise.

MCPGuard controls traffic routed through it. It does not isolate arbitrary server processes, make unchanged malicious code trustworthy, or prevent an allowed server from forwarding data.

Browser egress is specific to the tested Chromium setup. Other protocols and OS-level confinement need separate controls. Client approvals still matter.

What data does MCPGuard see?

Tool definitions, arguments and results pass through local memory. Payload logging is off by default and no external analysis service is required. Reviewed catalog snapshots intentionally persist tool metadata. Browser-generated outputs, such as screenshots, are separate from proxy logs.

Is this ready for production?

This is a research preview. Initial evaluations are scoped to supported staging workflows, with explicit acceptance criteria and rollback. Independent review and customer adoption are still being established.

Work with the maintainer

Bring one workflow.
Leave with evidence.

Explore a guided, 14-day staging pilot for your team's MCP setup. We agree the supported configuration, acceptance criteria, price and support scope before kickoff.

Review tools and destinations for one supported setup
Verify allowed work and synthetic attack cases
Get documented results, limitations and rollback

Start with your setup.

Tell us your MCP client, browser workflow and the data flow you want to control. Please leave out secrets and customer data.

viveky259259@gmail.com