Tool Pin
Pins the tools a web page offers to AI agents and tells you when one of them hides an instruction, changes after you trusted it, or is shared with another site.
ToolPin
Pins the tools a web page offers to AI agents and tells you when one of them hides an instruction, changes after you trusted it, or is shared with another site.
Date: 2026-11-09 Form factor: Browser extension (Manifest V3) Browser surface: content script (page and isolated worlds), toolbar popup, toolbar badge via service worker Status: Prototype
What it is
Chrome's WebMCP lets a page register tools, such as checkout or apply_coupon, that a browsing agent can call for you. ToolPin records each tool definition as the page registers it, checks the description and schema for planted instructions, and stores a hash so it can tell you if a tool you already looked at has quietly changed. The badge shows how many tools on the current page need attention.
Why it has to be an extension
The tool definitions only exist inside the page's JavaScript, in calls to document.modelContext.registerTool (older builds use navigator.modelContext). Seeing them means running a script in the page's own world at document_start, before the page registers anything, and wrapping those calls. A website cannot do that to another website. The pins also have to live outside any one origin, so a page cannot rewrite its own history.
Who it serves
Security engineers and AppSec reviewers who are being asked whether staff can let an agentic browser loose on internal and SaaS sites, and who currently have no way to see what tools those sites are handing the agent. It also fits individual power users who run a browsing agent and want a second opinion before it clicks through a checkout.
Why it could be profitable
Honest version: this is an unproven market that depends on WebMCP adoption. Chrome's own security page for WebMCP names indirect prompt injection as the main risk and says model safety cannot be guaranteed, and the Cloud Security Alliance's April 26, 2026 note reports hidden instructions in web pages being used against browsing agents in the wild. Nobody I found ships a tool-definition auditor for WebMCP specifically; the closest products pin and scan MCP servers rather than in-page tools.
The model I would try is open-core: free local pinning and checks, then a paid team tier that syncs an allow-list of approved tool hashes per domain, pushes it through managed-browser policy, and exports findings to a SIEM. That tier needs a backend, which this prototype does not have. The risk is that the Chrome team ships its own tool inspector in DevTools and takes the free tier away.
How to load it in Chrome
- Open
chrome://extensionsand turn on Developer mode. - Click Load unpacked and select this folder's
extension/directory. - Visit an HTTPS page that registers WebMCP tools. The WebMCP API is still in flux, so if no site you use registers any, open the demo page below instead. The popup reads "No agent tools registered" on pages without any.
How to try the demo
- Open
index.htmlin any modern browser. It runs fromfile://because the sample data is inlined;sample-data.jsonis the same data as a standalone file. - The popup is already open. Four of six tools on the fictional shop are flagged, and the badge says 4.
- Press Pin current tools and watch the "changed since pin" finding on
get_order_statusclear while the planted instructions stay flagged.
The demo runs the real page-hook.js and analyze.js. It simulates the content script's bridge, the badge, the in-page pill, and the browser's WebMCP API (a small shim stands in for document.modelContext).
Permissions, and why each one
| Permission | Why it's needed |
|---|---|
storage |
Saves your pins (storage.local) and the per-tab report the popup reads (storage.session). |
Content script on https://*/* |
Any site can register agent tools, so the hook has to be present before the page runs. It only copies tool definitions and sends no data off the device. No host_permissions and no tabs permission are requested. |
What's in this prototype
- A MAIN-world hook that wraps
registerToolandprovideContextondocumentandnavigator. - Seven checks: instruction-like phrases, invisible Unicode, free-text parameters that could carry data out, changed since pin, same name re-registered with different content, registered mid-session, and exposure to another origin. A low-severity note flags consequential tools with no
consequentialHint. - Popup with per-tool findings, pin, and copy-report.
- Badge count and a small in-page pill when something is flagged.
- Demo with six invented tools on a fictional shop at
example.com. - Stubbed or missing: any backend, policy sync, and a real model-based reviewer. The phrase list is a plain regex list, so it will miss paraphrased injections.
Roadmap
- Block a flagged tool from reaching the agent, if the WebMCP API allows interception.
- Per-domain allow-lists exported as JSON for managed-browser policy.
- A diff view showing exactly which words changed in a tool description.
- Scan MCP server tool lists that a page or side panel displays.
- Findings export to a SIEM, for the paid tier.
Sources
- https://developer.chrome.com/docs/ai/webmcp/secure-tools — Chrome's WebMCP security guidance:
exposedTo, annotation hints, indirect prompt injection as the main risk (published June 9, 2026, updated September 1, 2026). - https://labs.cloudsecurityalliance.org/research/csa-research-note-indirect-prompt-injection-in-the-wild-2026/ — April 26, 2026 note on hidden instructions in web pages targeting AI agents, and the hiding techniques seen.
- https://owasp.org/www-community/attacks/MCP_Tool_Poisoning — OWASP's description of tool poisoning and why one-time review at connect time is the root cause.
Requirements
ToolPin — Requirements
Goals
- Show a reviewer, in under ten seconds, which agent tools a page has registered and which ones look hostile.
- Detect a tool definition that changed after the user pinned it.
- Keep every definition and pin on the device. No network calls.
- Ask for no more than
storageplus one content-script match pattern.
Primary user
A security engineer or AppSec reviewer evaluating agentic-browser use on SaaS and internal sites. They open a page an agent will act on, open the popup, and decide whether its tools are safe to leave enabled.
Functional requirements
- FR1: A MAIN-world script at
document_startwrapsregisterToolandprovideContextondocument.modelContextandnavigator.modelContextwithout altering their behavior. - FR2: Each captured tool records name, description, input schema, annotations,
exposedTo, registration method, and milliseconds since page start. Function bodies are never captured. - FR3: The content script flags instruction-like phrases in the description and any schema property description.
- FR4: Invisible Unicode (zero-width and tag characters) in a description or schema is flagged high.
- FR5: Free-text parameters named like notes, context, or history are flagged medium.
- FR6: A tool whose hash differs from its pin is shown as
changedwith a high finding. - FR7: A tool re-registered under the same name with different content is flagged as shadowed.
- FR8: A tool registered more than 5 seconds after page start is flagged as late.
- FR9: A
exposedToentry that is*, non-HTTPS, or another origin is flagged. - FR10: A tool whose name or description implies a consequential action and has neither
readOnlyHintnorconsequentialHintgets a low note. - FR11: The toolbar badge shows the count of tools with a medium or high finding, red if any is high.
- FR12: "Pin current tools" stores a name-to-hash map per origin; pinned tools show
pinnedon later visits. - FR13: "Copy report" copies the findings as JSON.
- FR14: The popup works unchanged in the demo harness, where state arrives from page events instead of
chrome.*.
User stories
- As a security reviewer, I want to see every tool a page offers an agent, so that I know what the agent can do there.
- As a security reviewer, I want hidden or instruction-like text flagged with an excerpt, so that I can judge it without reading the schema.
- As a power user, I want to pin a tool set I have checked, so that I notice when a site changes it later.
- As an IAM analyst, I want to see which tools are exposed to other origins, so that I can spot third-party reach into the user's session.
- As a team lead, I want a copyable JSON report, so that I can attach findings to a ticket.
- As a user on a clean site, I want no badge and no noise, so that I keep the extension installed.
Extension surfaces
- Content script (MAIN world) — wraps the WebMCP registration calls.
- Content script (isolated world) — analyzes, compares to pins, reports, shows a small pill.
- Service worker — stores the per-tab report and sets the badge.
- Toolbar popup — findings list, pin, copy report.
chrome.storage.local/chrome.storage.session— pins and per-tab reports.
Non-functional requirements
- No network requests; no remote code; no
eval. - The page hook must never throw into page code or change a tool's behavior.
- Popup is 380px wide and usable by keyboard.
- Analysis of a page with 50 tools completes in under 50 ms.
- Only
storageis requested; notabsand no host permissions beyond the content-script match.
Out of scope (for the prototype)
- Blocking or editing tools before the agent sees them.
- Server-side sync, team policy, SIEM export.
- Model-based classification of descriptions.
- Scanning MCP servers outside the page.
Open questions
- Will the final WebMCP API keep
registerToolondocument.modelContext, and can an extension intercept it reliably in every frame? - Does
https://*/*raise Chrome Web Store review friction, and would an opt-in per-site model be better? - What false-positive rate on real tool descriptions is tolerable before users switch it off?
