Many teams run a short security review before rolling the Toolio Overlay out internally. This article answers the questions IT and security reviewers ask most often, in enough detail to complete that review. For installation and day-to-day use, see Getting Started with the Toolio Overlay and Using the Toolio Overlay.

In short: the overlay reads the product identifiers already visible on your storefront page, matches them to your own Toolio account, and draws a panel on top. It has no access to cookies, browsing history, or anything a shopper enters, and it never changes what shoppers see.

The overlay is a Manifest V3 Chromium extension and declares four browser permissions.

At install, the only websites the extension can reach are Toolio's own (https://*.toolio.com). It also declares a broad optional site permission, which is not granted at install. Access to a storefront is granted one domain at a time, by you, through Chrome's own permission prompt. It is a broad optional permission rather than a fixed list because the set of customer storefront domains changes over time.

The extension does not request the cookies permission, the history permission, the tabs permission, or webRequest. It has no ability to read your cookies or your browsing history. It also contains no remote code: everything it runs ships inside the reviewed package, and nothing is downloaded and executed at runtime.

On a granted storefront, the overlay reads the information it needs to work out which product you are looking at. That means structured product data on the page, product handles in links, the page title and main image tags, headings, image alt text, and color swatch labels. All of it is public catalog information already visible to any visitor, and the reading happens locally in your browser.

It does not read cookies. It does not read session storage. Its only use of local storage is one key it writes itself, which records whether you left the panel open. It does not read form fields, cart contents, checkout pages, or account pages, and it does not read anything a shopper types.

The overlay never modifies your storefront, its content, or its data, and it is not visible to shoppers or to anyone other than you.

There are two outbound flows and nothing else.

Planning data requests go to your own Toolio tenant, authorized with your own sign-in. The request carries the product identifier being looked up so Toolio can return that product's metrics. This is the same API, the same authorization, and the same data your team already reaches through the Toolio web app.

Usage analytics record how the overlay itself is used, so we can understand and improve it. These events are deliberately bounded: only a fixed list of event names is allowed, and each event may carry only a fixed list of properties. Anything else is discarded before the event is sent. The events record which panel, chip, or filter was used, the storefront hostname, your Toolio tenant, the extension version, and your Toolio user identity.

The analytics events deliberately do not carry page URLs, product names or handles, your browser's user agent, your IP address, or anything a shopper typed or selected. There is no separate crash or error reporting service; errors surface only in your own browser console.

Sign-in uses single sign-on, the same credentials and the same identity provider you already use for Toolio. There is no API key, shared secret, or connection string to enter or store.

The overlay uses the OAuth authorization code flow with PKCE, so the session belongs to you as an individual user rather than to the extension. You see exactly the data your Toolio account already has access to, and no more.

Sign-in tokens are held in extension storage that is explicitly restricted to the extension itself. A script running on a storefront page cannot read them, so a compromised or malicious retailer page cannot take your Toolio session.

Access is controlled centrally, in the same place you already control Toolio access.

Every request for data is authorized on Toolio's side, so disabling a user in Toolio and in your identity provider stops the overlay from returning data for that person. Access tokens are short lived, with the lifetime set by your identity provider, and renewing one requires going back to the authorization server, so a deprovisioned user cannot obtain a new one.

Removing the extension, either by the user or through browser policy, clears everything it has stored locally, tokens included.

Every change is a pull request into the extension's repository, reviewed and merged by Toolio engineering. Automated tests run on every change, including tests whose specific job is to enforce the analytics limits described above, so a change that widened what the extension collects would fail those checks.

Release packages are produced by a scripted build rather than assembled by hand. The build validates the extension manifest and aborts outright if any Toolio API key is found in the package.

Distribution is through the Chrome Web Store, so Google reviews every submission before it goes out. Because the extension declares a broad optional site permission, it receives Chrome's in-depth review on first publication and on each update. Google signs the published package, and publishing rights are restricted to Toolio's developer account. Chrome then updates installed copies automatically.

If you would rather not have people install the overlay individually, your IT team can deploy it centrally with standard browser policy. The extension can be force-installed by its Chrome Web Store ID, pinned to a specific version, and removed centrally later.

Many teams prefer this for a first rollout, because it keeps the installed version under your control and gives you a single place to remove the extension for everyone.

Toolio holds SOC 2 Type 2 certification. The systems the overlay talks to, the Toolio API and the tenant infrastructure serving your data, are within that scope. The overlay introduces no new data store and no new processing environment: it reads your existing Toolio data through the existing API.

If your review requires our current SOC 2 report or our most recent penetration test report, contact your Toolio representative. Both are available under NDA.

No. It reads the product catalog information already rendered on the page, not shopper sessions. It has no access to cookies, carts, checkout, or account pages, and it cannot read what a shopper types.

No. The overlay draws its panel on top of the page in your browser only. It does not modify the storefront, its markup, or its data, and shoppers are unaffected because it runs only in the browser of a signed-in Toolio user.

Only the ones you explicitly grant, one domain at a time, through Chrome's permission prompt. It cannot run on a site you have not granted, and it does not browse or monitor other sites you visit.

The overlay uses the same data, the same API, and the same analytics processor as the Toolio web app, so it does not introduce a new category of data or a new processor. If you would like this confirmed in writing against your existing agreement, contact your Toolio representative.

Yes. Access follows your existing Toolio permissions. Installing the extension grants nothing on its own: a user sees data only after signing in with their Toolio account, and only the data that account already has access to.