Skip to main content
The whole premise of the product is that prompts contain sensitive data. Relaying that data to a dashboard or a SIEM would simply move the leak. So the system is built to be useful without ever holding prompt text. Use this page when your security or privacy team asks what the tool actually sees.

​
The rule

Prompt bodies never leave the endpoint. Not the original text, not the redacted text, not the matched values. What leaves is a one-way SHA-256 hash plus structured metadata.
This is enforced in three places:
  1. The wire format has no field for prompt text.
  2. The backend applies a prompt_hash check constraint on the violation table, so raw prompt text is rejected at the database layer rather than stored.
  3. The SIEM forwarder ships structured fields and the hash only — never the body, the response, or extracted secrets.

​
What is transmitted

Identity is attached via the Entra ID SSO claim rather than being derived from the prompt.

​
What is never transmitted

  • The prompt as typed
  • The prompt after redaction
  • Any matched value — no email address, card number, or identifier
  • The AI tool’s response

​
Storage at rest, per client

  • Tokens — encrypted and held in chrome.storage.local; the background service worker owns the full token lifecycle including refresh and validation.
  • History — suggestion history is served from the API rather than cached wholesale on the device.
  • Hardening — strict Content Security Policy, input sanitisation, XSS protections, and token validation on every use.

​
Authentication

All three clients authenticate through Auth0, and the admin console additionally supports Microsoft Entra ID SSO.
  • Browser: OAuth2 authorization-code flow with PKCE via chrome.identity.launchWebAuthFlow.
  • macOS: Auth0 with automatic token refresh; every network service retries once through a refresh path on a 401 or 403.
  • Windows: Auth0 OIDC through an embedded WebView2 browser, with a prompt-shields://callback custom URI scheme for the redirect.
See Identity and access for tenant mapping and provisioning rules.

​
Telemetry and analytics

The clients can emit product analytics through PostHog, Firebase, and Google Analytics. These are configured per environment and can be disabled — on the Windows agent, analytics is an explicit enable/disable setting in appsettings.*.json.
Analytics covers product usage events, not prompt content. If your organisation prohibits third-party analytics on managed endpoints, ask for a build with the analytics providers disabled before you roll out.

​
Outbound integrations

​
Questions your privacy review will ask

The endpoint clients read the focused text field, and the browser extension only does so on the AI sites in its permission list. Analysis of a given prompt is triggered by the user, and the result is a suggestion the user must accept.
No. The console never receives prompt text, so there is nothing to read. An admin sees that a category was detected, in which application, at what time, and whether the user accepted the fix.
No keystroke stream is recorded or transmitted. Text is read from the focused field in memory for analysis and is not persisted as typed.
Without MDM enrolment there is no device_id to attach, so events are attributed to the signed-in user only. Coverage on unmanaged devices depends on the user installing the client.