A tool that protects your data and keeps it yours.
Tracehold checks what your team sends to AI, so the first question is what we do with that data. The detection engine runs in the browser. The console receives event metadata and a masked sample of the value. Production is hosted in the EU. This page says what is sent, what is stored, and who can see it.
Built to protect your data and stay out of your way
Four facts, each explained below.
The extension's engine checks the prompt and attached files in the browser, before they are sent.
Event metadata (type of data, severity, destination, action) plus a masked sample of the value. Keeping the content of findings is off by default.
Each organisation's rows are kept apart by policies inside PostgreSQL, not only by the application.
Production runs on EU infrastructure. The providers involved are listed on the subprocessors page.
What reaches Tracehold, and when
Four levels. Only the first is always on, and its values are masked.
Event metadata (always on)
The type of data found, severity, destination and action, plus a masked sample of the matched value (values of up to 12 characters are masked completely; longer values show only the first 8 and the last 4 characters). Endpoint agents also send an excerpt of the text with the sensitive values masked.
Text for the LLM classifier (off by default)
The prompt text, in transit to the classifier. Tracehold does not store it. Governance plan, beta, switched on per organisation.
Content of findings (off by default)
The text around a finding, kept so an administrator can tell a real leak from a false alarm. It is encrypted and deleted after 90 days. Your organisation turns it on.
Free extension (no content)
Apart from the reports you choose to send, never the text of your prompts: detection happens in your browser and it needs no account. It makes a few pseudonymous requests (usage statistics and scan events without content), as its privacy notice describes.
What actually travels and what stays put
The detection engine in the browser decides what happens to each prompt, according to your policy.
Allow
Clean prompts pass straight through, unmodified.
Observe
Flagged content is logged for visibility, without interrupting anyone.
Redact
The sensitive part is hidden or stripped out, so the rest can still go through.
Block
The whole thing is blocked, and the person gets a clear heads-up.
What is encrypted, and how
Specific mechanisms, not a blanket promise.
Content of findings
If your organisation keeps it, it is encrypted with AES-256-GCM and deleted after 90 days.
Integration and authenticator secrets
Stored secrets for LDAP, single sign-on and SIEM are encrypted at rest with a key that is separate from the one that signs sessions. SIEM tokens and webhook secrets are never returned once saved. The secrets behind two-step sign-in (TOTP) are encrypted with AES-256-GCM.
In transit
The console and the API are served over HTTPS with automatically renewed certificates.
In production the server refuses to start if its signing secret is missing or weak, or if the key for stored secrets is not independent.
Every organisation's data is kept apart inside the database
The application filters by organisation, and PostgreSQL enforces it again with Row-Level Security.
Policies inside PostgreSQL
Tables that hold an organisation's data, such as detections, incidents, users and policies, carry a Row-Level Security policy that only lets a request see and write rows of its own organisation. When the application reads or writes an organisation's data for a signed-in user, it switches to a limited database role, so the policies apply to it.
Groups of organisations
A parent organisation can read its subsidiaries' data in read-only mode. Changes stay in the organisation that owns them. Multi-tenant spaces are part of the Governance plan.
Defence in depth
The application keeps each organisation's queries apart, and the database enforces it again, so a missing filter in the code does not expose another organisation's rows.
Who can sign in, and who can see what
Single sign-on, a second factor and throttled sign-in protect the console, and the detection rules the extension downloads are signed.
OIDC and LDAP/AD, plus a second factor
For OIDC, Tracehold checks the identity token's signature against your provider's keys, along with issuer, audience, expiry and nonce, and ties the email to your organisation's domain. Console sign-in supports an authenticator app (TOTP), an email code and backup codes. After 8 failed attempts in 15 minutes, sign-in pauses for that IP address and email; the account is never locked.
Read-only keys
Customer API keys have three read-only scopes: events, statistics and policies. They open the same private space as a normal sign-in, nothing wider.
Detection rule integrity
The detection rules the extension downloads are signed with Ed25519 and travel over HTTPS to authenticated clients. The extension verifies the signature against a public key built into it and the integrity of the rules (SHA-256) before applying them and rejects a rule set older than the last one it saw. If a check fails, it keeps the rules it already has.
Revealing takes a permission
Seeing the original content behind a detection takes a specific permission. Administrators have it; managers and users only if you grant it. Every reveal is written to the activity log with who, when and what; the log is kept for 30 days by default.
The questions buyers ask about trust
Do you store our prompts or our data?
Who can see the original content behind a detection?
How do you keep one customer’s data apart from another’s?
How are the detection rules delivered and checked?
Where is our data hosted?
How do people sign in to the console?
Send us your security questions
We'd rather answer the hard questions up front. Walk through how your data is protected with our team, then start in observe-only mode and see what Tracehold would catch.