LEGAL · PRIVACY POLICY
Privacy Policy
What we process, why, and your rights.
Effective date: 9 June 2026. Last updated: 2 October 2026. This update adds Amazon Web Services as a sub-processor for the AWS credential and CI/CD secret decoys, and explains what the key decoys process (Sections 1 and 3). The update of 26 September 2026 added the Vantuz Browser Decoy extension for Chrome and Edge (Sections 1, 1A and 2) and uses one word, "decoy", for everything we plant to catch intruders.
Vantuz Ltd ("Vantuz", "we") operates the Vantuz deception and detection platform at vantuz.co and app.vantuz.co. This policy explains what personal data we process, why, and your rights. We are a UK-registered company (Vantuz Ltd, company no. 17270048, 71-75 Shelton Street, Covent Garden, London WC2H 9JQ) and act as a data controller for the processing described here, and as a data processor on our customers' behalf for security telemetry within their workspaces (see our DPA).
1. Data we process
Account data (to provide the service, under contract): your email, name, workspace name, plan, and authentication data managed by our identity provider. Integration credentials you connect are encrypted at rest and never shown back to your browser. When you accept our Terms of Service we keep a record of the acceptance: your account and workspace, the version and a fingerprint of its text, the time, and the IP address and browser it was accepted from, so that we can show what was agreed.
Security telemetry (to detect and respond to intrusions, under legitimate interests): when one of your decoys is accessed or used, we process the source IP address, user agent, timestamp and request metadata, plus enrichment derived from the IP (approximate geolocation, network/ASN, reputation) and incident metadata (risk score, MITRE technique, an AI-generated narrative). We strip sensitive headers (such as Authorization) before storage. For the Vantuz Browser Decoy extension, Section 1A sets out exactly what it keeps, what it sends and what it never touches.
Key decoys. An AWS credential decoy and a CI/CD secret decoy are a real AWS access key that is not allowed to do anything, held in an AWS account that Vantuz runs only for decoys. When someone uses that key, AWS records the call (the source IP address, the user agent, the time and the action that was tried) and passes the record to us; AWS keeps its own log of those calls for 90 days. An OpenAI key decoy and an Anthropic key decoy are a key together with an API address on your own tracking domain, which leads to our edge worker. When a tool uses that configuration we process the source IP address, the user agent, the name and version of the tool, and the name of the model it asked for. We do not keep the key that was presented, only a one-way fingerprint of it, and we read nothing else from the request.
Exposure data (Exposure Sonar, on your instruction; we act as your processor): the domains you prove are yours, the internet-facing hosts under them, the weaknesses we find and the evidence that proves them. Evidence is redacted before it is stored, encrypted with a key unique to your workspace, and deleted after 30 days. It can incidentally contain personal data you published by accident (for example, a name inside a configuration file that was publicly readable); we never keep the contents of documents, databases or archives we find exposed, only the fact that they are exposed. We also record who authorised the checks, their role, the terms version and the IP address they used.
Data about your people, if you enable it (on your instruction; we act as your processor): if you connect your own Microsoft 365 or Google Workspace, read-only, we read account identifiers, admin roles, whether two-step verification is set up, whether older sign-in methods are allowed, and when accounts last signed in, to find accounts that are exposed or no longer used. If breach-exposure checks are enabled, we check whether email addresses at your domain appear in known third-party breaches — never the password, and never a hash of it. We never read email content, files, chat or calendars. These checks do not run until you confirm that you have told your staff; we give you wording to use.
Usage data: basic logs needed to operate, secure and debug the service.
We do not sell personal data. We do not use it for advertising.
1A. The Vantuz Browser Decoy extension
Vantuz Browser Decoy is a browser extension for Google Chrome and Microsoft Edge. It has a single purpose: it keeps one decoy login session in the browser, so that the organisation that installed it is alerted if anyone copies that session and uses it. The session is synthetic. Vantuz creates it, it gives access to nothing, and it exists only on a decoy domain that Vantuz controls. This section is written for the people whose browsers run the extension, and for anyone reviewing it.
Who controls it. The extension only works for a customer's Vantuz workspace. A browser is connected in one of two ways: with a single-use activation code, valid for 24 hours, that an owner or admin of the workspace creates in Vantuz; or through a policy that the organisation's IT team pushes to the browsers it manages (for example through Google Admin or Microsoft Intune). Before using a code, the person connecting the browser confirms that their organisation has authorised them to do so. The customer decides which browsers carry a decoy and receives its alerts. We process the data described here on the customer's behalf, as its processor, under our DPA, and under that DPA the customer is responsible for having a lawful basis to deploy the extension and for telling the people who use those browsers. If your employer installed it, your employer is the right first contact for questions (see Section 5). You can also write to privacy@vantuz.co.
What it keeps on the device. In the extension's own storage, which websites cannot read:
- a random installation ID that the extension creates for this browser profile;
- the details from the activation code, or from your organisation's policy, that link it to the workspace;
- a renewal credential that Vantuz issues when the browser is connected;
- its status: whether it is connected, the ID of its decoy, and when it last renewed.
The decoy session cookie itself sits in the browser's normal cookie store, set only on the decoy domain. Vantuz generates its value, it opens nothing, and it is the only cookie the extension ever sets. Nothing is saved to browser sync, and the extension does not run in private or incognito windows. Like anything stored in a browser, this data can be read by a person or program with full access to the computer; that kind of theft is exactly what the decoy is there to catch.
What it sends, and when. The extension talks to a single Vantuz address, always over an encrypted (HTTPS) connection. It never visits the decoy domain itself.
- When the browser is connected: the workspace deployment ID, the installation ID and the activation key. Vantuz replies with the decoy cookie and a renewal credential.
- About every 6 hours, when the browser starts, shortly after a failed attempt, or when someone presses the check button in its panel: the deployment ID, the installation ID and the renewal credential, so that Vantuz can renew the decoy. We record when each installation last renewed.
These requests carry no cookies and nothing about your browsing. Like any request on the internet, they reach us with the device's IP address and the browser's user agent (its name and version). We use these only to run and secure the service. We do not store them with the installation record; they can appear in our own operational logs.
What it never touches.
- Other cookies. The browser limits the extension's cookie access to the decoy domain and the Vantuz address, so it cannot read the cookies of any other site. Even there, it does not read or list cookies: it only sets and removes its own decoy cookie.
- Your browsing. It has no access to your history, your tabs, the pages you visit or what you type, and it does not run inside web pages.
- Analytics, advertising and remote code. It contains no analytics, advertising or tracking, and it runs no code from the internet: everything it runs ships inside the extension.
When the decoy session is used. If anyone presents the decoy session to the decoy domain (for example, malware that copied the browser's cookies, or a person replaying them from another computer), the decoy domain answers with an ordinary "not found" page and grants access to nothing. Our edge server then sends Vantuz the decoy's ID, a one-way fingerprint of the cookie (never the cookie itself; we use it only to confirm the match and do not store it), the decoy domain it was sent to, the time, the source IP address, the user agent, the approximate country, network and data centre that our edge provider reports for the request, and a request reference. Nothing else from the request is forwarded. If the decoy is still active, Vantuz opens an incident in the customer's workspace and notes which installation the decoy came from, so the customer knows which browser to check. We enrich and score the incident like any other decoy alert (see Security telemetry in Section 1) and alert the workspace by email. We process this data to detect and respond to intrusions, on the customer's instruction. An alert shows that the decoy session was used. It does not prove which real sessions were taken, and opening the decoy address on purpose, in a browser that holds the decoy, also triggers it.
How long we keep it.
- Data from the decoy session being used is kept like any other decoy signal: up to 12 months (Section 4).
- The IP address and user agent of connection and renewal requests are kept only as part of our operational logs: up to 24 months (Section 4).
- The installation record (its random ID, the deployment it belongs to and when it last renewed) is kept for the life of the customer's workspace and deleted with it (Section 6).
- On the device, the extension's data stays until it is removed from the browser.
Removing it.
- Revoking the decoy in Vantuz disarms it on our servers straight away: using the old session no longer opens an incident. The extension then removes its decoy cookie at its next check.
- Removing the connection from the extension's own panel deletes its saved data and its decoy cookie from that browser, but does not revoke the decoy in Vantuz. On browsers the organisation manages, its IT team removes the extension through its policy.
- Uninstalling the extension deletes its saved data, but the browser can keep the decoy cookie until it expires (at most about six months) or until the browser's site data is cleared. Until the decoy is revoked in Vantuz, that cookie can still trigger an alert, so a workspace owner or admin should revoke it when a browser is retired.
Chrome Web Store Limited Use. The use of information received through the Vantuz Browser Decoy extension, including through the browser's cookies API, will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements. In practice:
- we use it only to run the decoy, alert the customer and improve that detection;
- we transfer it only as needed to provide that service (through the providers listed in Section 3), to comply with the law, or to protect against fraud and abuse;
- we never sell it, never use it for advertising, and never use it to judge anyone's creditworthiness or for lending;
- people at Vantuz read it only when needed for security, such as investigating abuse, when the customer asks us for help with a specific case, or to comply with the law. Collective security learning (at the end of this policy) uses only anonymised, aggregated patterns.
The extension does not use Google APIs and has no access to Google account data.
2. Why we process it and our legal basis
| Purpose | Legal basis (UK/EU GDPR) |
|---|---|
| Providing your account and the platform | Contract (Art. 6(1)(b)) |
| Detecting, investigating and containing intrusions (security telemetry) | Legitimate interests (Art. 6(1)(f); Recital 49 — network & information security) |
| Running the Vantuz Browser Decoy extension on your organisation's browsers (Section 1A) | As your processor, on your documented instruction |
| Checking what your organisation exposes, on your instruction (Exposure Sonar) | As your processor, on your documented instruction; our own records of your authorisation under legitimate interests |
| Sending service and security emails | Contract / legitimate interests |
| Billing | Contract / legal obligation |
| Keeping a record of acceptance of our Terms, and establishing or defending legal claims | Legitimate interests |
| Security, fraud prevention, debugging | Legitimate interests |
Our Legitimate Interest Assessment is available to regulators on request.
3. Data residency and sub-processors
We aim to keep security telemetry processed within the UK/EEA. We use the following sub-processors:
| Sub-processor | Purpose | Location |
|---|---|---|
| Supabase | Authentication and database | EU |
| Railway | Application hosting | EU West (Amsterdam) |
| Vercel | Frontend/site hosting | Global edge |
| Cloudflare | DNS, CDN, WAF, edge worker | Global edge |
| Upstash | Job queue (Redis) | Ireland (eu-west-1) |
| Amazon Web Services | Holding the decoy AWS keys and recording their use (AWS credential and CI/CD secret decoys only) | United States (N. Virginia) |
| Resend | Transactional email | Ireland (EU) |
| Anthropic | AI incident narrative | United States |
| VirusTotal, AbuseIPDB, Shodan | IP reputation enrichment; and, for exposure checks, looking up your own internet-facing hosts | United States |
| Certificate Transparency logs (public) | Not used yet. If we start discovering subdomains from public certificate logs, we will either read the public logs ourselves, so nothing about you is sent to anyone, or add the provider we use to this list with notice first | Global (public logs) |
| Breach-exposure data providers | Checking whether email addresses at your domain appear in known third-party breaches | United States |
Where data is transferred outside the UK/EEA (AI narrative, IP enrichment, exposure lookups, breach-exposure checks and the record AWS makes when a decoy AWS key is used), we rely on appropriate safeguards (UK IDTA / EU Standard Contractual Clauses) and minimise the data transferred. The record of a decoy AWS key being used is made by AWS in the United States and then stored by us in the EU with the rest of your security telemetry.
Accounts you connect are not sub-processors. When you connect your own Microsoft 365, Google Workspace or cloud account, data flows from your provider to us, read-only, under your authorisation; your provider is yours, not ours.
Nothing from an exposure check is sent to an AI provider. Anthropic is used only for incident narratives, as described above.
What leaves us during an exposure check. When you ask us to check what your organisation exposes to the internet, we send the domain names and hostnames you have verified as yours to the providers above that are enabled for your workspace, and we receive back information about those hosts. Looking up your hostnames in DNS also passes them through public DNS resolvers (Cloudflare, Google, Quad9), as any DNS lookup does. We only ever contact hosts under a domain you have proven is yours, only with read-only requests, and at a deliberately slow rate. Breach-exposure checks return email addresses at your domain that appear in known third-party breaches — that is personal data about your people, and it is covered by the retention ceiling in Section 4. We never send your internal data, your files, or the contents of your systems.
4. Retention
Account data: for the life of your account, then deleted, except billing records (kept as long as tax law requires, normally 6 years) and records of acceptance of our Terms (kept for 6 years after your account closes, the period in which a contract claim can be brought in England).
Security and exposure data. Different kinds of data are kept for different periods, because they serve different purposes. Every period below is a maximum: data is deleted or anonymised at the end of it, and an absolute ceiling applies even where a matter is still open.
| What it is | Kept for | Absolute ceiling |
|---|---|---|
| Record of who authorised us to scan which asset | 24 months | 24 months |
| Inventory of your internet-facing assets | while in scope, then 90 days | 18 months |
| A finding (a weakness we identified) | while open, then 90 days | 18 months |
| Raw evidence captured to prove a finding | 30 days | 30 days, no exception |
| Fingerprints of a secret we found exposed | life of the finding | 18 months |
| Personal data about your people (e.g. an email address of yours appearing in a third-party breach list) | while the finding is open | 12 months, no exception |
| Signals that an attacker probed a decoy | 12 months | 12 months |
| Our own operational logs | 24 months | 24 months |
Two of these have no exception, deliberately. Raw evidence and personal data about individuals are never held open by an "active matter" — if a finding is still open after that ceiling, we keep the finding and lose the evidence, and we say so in the product rather than pretending the evidence still exists.
For everything else, a longer period may apply only where needed for an active security or legal matter, or where agreed by contract. An open finding is an active security matter.
5. Your rights
Under UK/EU GDPR you may request access, rectification, erasure, restriction, portability, and you may object to processing based on legitimate interests. To exercise any right, email privacy@vantuz.co. You also have the right to complain to the UK Information Commissioner's Office (ico.org.uk) or your local supervisory authority.
If you work for one of our customers and our checks processed data about you (for example, your account appeared in a check for missing two-step verification), your employer is the controller of that data and the right place for your request; we will help them answer it. If you ask us directly, we will pass your request to your employer. When your employer asks us to stop processing data about you, that instruction is applied before anything is written and does not expire, so the next check does not bring you back.
We respond within one month. That can be extended by two further months for complex requests, in which case we tell you why within the first month.
Automated decisions. We do not make decisions about individuals based solely on automated processing that have legal or similarly significant effects on them. Risk scores and findings are about systems and accounts, and people at our customers decide what to do with them.
A note on security-incident data: if you are an individual whose IP appears in incident telemetry because a decoy was accessed, you may object; we will assess each request, balancing your rights against the security interest, and respond.
5A. Complaints
If you are unhappy with how we have handled your personal data, please complain to us first at privacy@vantuz.co, with "Complaint" in the subject line. We will:
- acknowledge your complaint within 30 days;
- look into it without undue delay, and keep you informed;
- tell you the outcome and what, if anything, we will change.
You can also complain to a supervisory authority at any time, whether or not you have complained to us first:
- in the UK, the Information Commissioner's Office (ico.org.uk);
- in Portugal, the Comissão Nacional de Proteção de Dados (cnpd.pt);
- elsewhere, the authority where you live or work.
6. Security
We protect data with encryption in transit and at rest (AES-256-GCM for integration credentials), strict tenant isolation, access controls, optional two-factor authentication, and regular security testing.
Our staff do not have access to your exposure data by default. If someone at Vantuz needs to look (for example, to review a finding you disputed), they need a written, time-limited permission for a stated reason, and every time they look is recorded in an access log you can see in your workspace.
When you delete your workspace, we delete your data and destroy the encryption key for your evidence in the same operation, and keep only a receipt that it happened. Database backups taken before the deletion age out on our database provider's backup schedule. Until then, the evidence inside those backups stays encrypted and cannot be read without our master key, which is held separately; the rest of the backup is protected by our provider's encryption at rest.
7. Children
The service is not directed to children and is for business use only.
8. Changes and contact
We will post changes here and update the "last updated" date. If a change materially affects how we use personal data, we will also tell account holders by email before it takes effect. We will also notify customers of any new sub-processor, as the DPA requires. Questions or requests: privacy@vantuz.co. Controller: Vantuz Ltd, 71-75 Shelton Street, Covent Garden, London WC2H 9JQ.
Collective security learning (anonymized) — added 2026-06-09 (Phase 2.4)
To improve detection and hardening recommendations for all customers, Vantuz may learn from anonymized, aggregated patterns derived from incidents — for example, which decoy type was triggered, the coarse attack surface, a risk band, and the categories of recommended actions. This learning is internal only. We never sell or share it, and it never includes your name, email, IP addresses, domains, internal URLs, secrets, exact token names, or any identifier that could link a pattern back to you. A workspace is represented only by an irreversible hash bucket, and aggregates are used only above a minimum-volume threshold so no individual record is identifiable.
You can opt out of contributing to collective learning at any time in your environment profile settings (collective_opt_out); opting out does not reduce the protection you receive. Collective patterns may refine our recommendation priors and confidence calibration, but never drive an automatic or destructive action and never disclose that "another customer saw X".