1. What Torii Lens is

Torii Lens is a Chrome extension that gives Torii customers visibility into the AI tools their employees actually use — Cursor, OpenAI, Anthropic Claude, Lovable, and a growing list of others.

Available on the Chrome Web Store: https://chromewebstore.google.com/detail/torii-ai-lens/jfkmfmipjamnfbiipbobdekchjpbjjjb

For each supported AI product, Torii Lens extracts the data your IT, security, and finance teams need:

• Workspace and team configuration (org name, plan, seats)
• Members and roles (who has access, with what permissions)
• Usage and billing (per-seat usage, spend, credits, limits)
• API keys and tokens (issuance, owner, last-used, scopes)
• Security posture (SSO/MFA status, sharing controls, retention settings)

The extracted data flows into the Torii platform, where it sits alongside the rest of your SaaS inventory — discoverable, searchable, governable.

2. Why an extension instead of an API integration?

Torii's standard integration model is server-to-server, using documented administrative APIs published by the SaaS vendor. This model depends on the vendor exposing the relevant administrative surface — members, usage, billing, API keys, security settings — through a stable, authenticated API.

The current generation of AI products does not yet meet this prerequisite. Administrative data that is fully visible to the customer within the vendor's own web console is, in most cases, not available through a corresponding public API. The data is authorized to the customer; it is simply not addressable programmatically.

A browser extension closes this gap without compromising the access model. Operating within the customer's authenticated session, the extension reads the same administrative views the customer is already entitled to see, structures the data, and delivers it to the customer's Torii tenant. No new trust relationship is established with the vendor, and no privilege is exercised beyond what the signed-in user already holds.

3. Security model

3.1 The single most important property

No credentials, tokens, cookies, or session IDs from the AI vendors ever leave the user's browser.

The extension reads the auth material that the page itself already holds (a Firebase JWT in IndexedDB, an Auth0 access token in localStorage, a Cursor session cookie) and uses it inside the browser to call the vendor's own backend APIs — exactly the same APIs the dashboard's JavaScript would call if the user were clicking around.

The auth material is used in-memory, in-page, for the duration of one extraction. It is never:

• Sent to Torii servers
• Persisted to extension storage
• Logged
• Included in ZIP exports
• Exposed to other websites

3.2 What does get sent to Torii

Only the extracted business data — and only if the customer chooses the “Torii backend” storage mode. The payloads look like:

{
  "data": {
    "members": [{ "email": "...", "role": "admin", "lastActive": "..." }]
  }
}

…posted to the customer's own Torii tenant (api.toriihq.com) over HTTPS, authenticated with the same Torii session cookie the customer uses to log into app.toriihq.com. The Torii session lives entirely on *.toriihq.com cookies — there is no cross-domain credential sharing.

3.3 What the extension does not do

• It does not read passwords. It cannot see what the user types into a login form.
• It does not bypass MFA, SSO, or IdP policy. It runs as the logged-in user, with that user's exact privileges.
• It does not exfiltrate cookies or tokens. The auth material stays in the browser.
• It does not run on arbitrary websites. Permissions are scoped to a fixed allowlist of supported AI products (see §4.2).
• It does not inject third-party code. All extraction logic ships inside the extension; nothing is downloaded at runtime, nothing is eval'd.
• It does not modify data. Every extraction is read-only — GET requests against the vendor's API. The extension never POSTs or DELETEs on the user's behalf.

3.4 Code provenance and review

• The extension is built from a single, version-controlled source tree.
• Manifest V3 (no remote code execution; CSP-enforced).
• All extraction logic is named functions referenced by ID in JSON config — there is no string-eval, no remote script loading, no dynamic code path.
• The extension is signed and distributed through the Chrome Web Store (production) or as an enterprise-managed extension for customers who require central deployment via Google Workspace / Intune.

4. Permissions — what we ask for and why

Chrome groups permissions into two categories: API permissions (what extension APIs we can call) and host permissions (which websites we can talk to). We minimize both.

4.1 API permissions

4.2 Host permissions — built-in defaults

Out of the box, the extension is pre-authorized to read from / call only the following hosts:

Torii's own hosts (where extracted data is sent):

• https://app.toriihq.com/*
• https://api.toriihq.com/*

Supported AI products (where data is extracted from):

• https://lovable.dev/* and https://*.lovable.dev/* — Lovable
• https://platform.openai.com/* and https://api.openai.com/* — OpenAI admin
• https://cursor.com/* — Cursor
• https://platform.claude.com/* — Anthropic Claude Console

These are the hosts the extension can access without any further user action. Chrome enforces this list at the browser level.

4.3 Adding new AI products without a new extension release

A key design goal is that Torii can add support for a new AI product without shipping a new version of the extension to every customer. Extraction logic ships as JSON configuration that can be updated centrally; the extension itself doesn't need to change.

To make this possible, the extension declares https://*/* as an optional host permission. “Optional” is the critical word:

• Chrome does not grant this permission at install time.
• Chrome will not allow the extension to reach a new host until the user explicitly approves it from the Torii Lens side panel.
• Approval is per-host, prompted by Chrome's native consent dialog, and revocable at any time from chrome://extensions.
• IT can also block this entirely via Chrome enterprise policy (ExtensionSettings → runtime_blocked_hosts) if the customer prefers a fixed allowlist.

So §4.2 and §4.3 are not in conflict — they describe two different layers:

The end state is the same as the built-in case: the extension can only ever talk to a finite, user-approved set of hosts. The difference is whether the approval is “baked in at install time” (§4.2) or “granted by the user later, with a Chrome consent prompt” (§4.3).

4.4 What we explicitly avoid

• No tabs permission. We don't read URLs of tabs the user hasn't opted into.
• No webRequest / webRequestBlocking. We don't intercept network traffic.
• No history, bookmarks, geolocation, clipboardRead.
• No <all_urls> content scripts. Content scripts run only on the host allowlist above.

5. Data flow at a glance

  ┌───────────────────────────────────────────────────────────┐
  │                    User's Chrome browser                     │
  │                                                              │
  │   ┌───────────┐   reads in-page   ┌────────────────────┐  │
  │   │ Torii Lens │ ───────────────►  │ Vendor admin page    │  │
  │   │ (sidepanel)│   auth material   │ (cursor.com, etc.)   │  │
  │   └─────┬──────┘                   └──────────┬───────────┘  │
  │         │                                     │ vendor API   │
  │         │                                     ▼              │
  │         │                          ┌─────────────────────┐  │
  │         │ extracted data only      │ Vendor backend       │  │
  │         │ (no credentials)         └─────────────────────┘  │
  │         ▼                                                    │
  └────────┬────────────────────────────────────────────────┘
            │ HTTPS, Torii session cookie
            ▼
       ┌─────────────────┐
       │ Torii tenant    │
       │ api.toriihq.com │
       └─────────────────┘

The left arrow (auth material) stays inside the browser. Only the bottom arrow (extracted business data) leaves the browser, and only to the customer's own Torii tenant.

6. Contact

For security questions, deployment guidance, or to request a SOC 2 / data-flow diagram package: contact your Torii account team or security@toriihq.com.