Security

1. Less data, by design

The most effective protection for sensitive data is not to collect it. Stanch inspects information on the device where it is sent, so the content itself does not go to our service by default. When Stanch finds a sensitive value, it records a masked preview and a one-way fingerprint keyed separately for each customer, never the value. Each request to an AI service is recorded as usage metadata, whether or not anything is found: the user, the app, the AI provider and the size, never the prompt or the response. Other activity in which nothing is found and nothing is done is not stored.

A customer can choose to keep the content behind selected incidents for investigation. That evidence is stored encrypted, separately from everything else, and only people the customer authorises can open it, each time with a fresh second factor and a stated reason, and every access is recorded.

2. Hosting and encryption

• The service runs on Google Cloud in Germany, with backups in the Netherlands.
• Every connection uses TLS; plain HTTP is redirected to HTTPS, and the console enforces HTTPS with HTTP Strict Transport Security.
• Data is encrypted at rest by Google Cloud. Two-step verification secrets and integration credentials are also encrypted by the application, and evidence is encrypted with keys unique to each customer.
• The server is a hardened Shielded VM with secure boot, no public SSH access, a firewall that opens only the web ports, and automatic security updates. Core secrets are kept in Google Secret Manager.

3. Customer separation and access

• Each customer’s data is separated by PostgreSQL row-level security in the database, in addition to checks in the application.
• The console uses roles (owner, admin, analyst, viewer). Two-step verification, by authenticator app or passkey, is required for owners and admins and can be required for everyone. Sessions expire after 12 hours, and sensitive changes ask for a fresh second factor.
• Administrative actions are recorded in an audit log that the application itself cannot delete.

4. Our team’s access

Stanch staff have no standing access to customer data through the application. Our operators work through a separate platform account whose roles need a second person’s approval and whose accounts require two-step verification. To help with a support request, an operator needs a session that the customer’s owner approves; it is read-only, time-limited, tied to one named person, shown on every page and recorded in the customer’s audit log.

Separately, a small number of named Stanch administrators maintain the servers that host the service, and so can technically reach the data stored on them. That access goes through Google’s identity-aware proxy and OS Login, is used only to run, secure and restore the service, and is logged.

5. The software on your devices

• Each enrolled device has its own key and signs what it reports, so reports are bound to that device and customer.
• The agent installs an update only after checking its signature against a key built into the agent, and refuses older versions.
• Its keys and queued records are readable only by the system and administrators, and its logs are redacted.

6. Building and running the service

• Changes are tested automatically, including tests that customers’ data stays separated.
• Dependencies are pinned and checked for known vulnerabilities, and container images are scanned before they are published.
• The database is backed up daily to private, versioned storage, with daily backups kept 30 days and weekly backups eight weeks.
• Server health is monitored, with alerts to our operations team.

7. Certifications and questionnaires

Stanch does not currently hold a third-party security certification or attestation. We are glad to answer security questionnaires and to share more detail under confidentiality: write to contact@stanch.ai.

8. Reporting a vulnerability

If you believe you have found a security vulnerability in Stanch, email security@stanch.ai, in English or Hebrew. Please report it privately, and do not share it with anyone else until we have agreed a disclosure date with you. We do not publish a PGP key, and we do not run a bug bounty.

What to include

• a short description of the issue and its security impact;
• the affected component and its version, with the operating system, browser and relevant settings;
• minimal steps to reproduce it, using test data in an environment you own or are explicitly authorised to test;
• what you expected and what you observed, with sanitised evidence and times;
• whether it is exposing data now, and how to reach you.

Send the minimum evidence needed. Do not send passwords, API keys, tokens, private keys, enrolment files, real customer data, or unredacted sensitive values, and do not attach database dumps or unredacted logs.

What happens next

We aim to acknowledge your report within three business days. We will assess it, keep you informed while we work on it, tell you when it is fixed, and agree a disclosure date with you. If you would like to be credited, tell us how.

Scope

Reports may concern the Stanch endpoint agent, the browser extension, the console and its programming interfaces, customer separation, the handling of sensitive data, and the integrity of our updates. Denial-of-service testing, social engineering of our staff or customers, physical attacks, and testing any system or customer account that you do not own or have written permission to test are out of scope.

9. Safe harbour for good-faith research

If you make a good-faith effort to follow this policy while researching and reporting a vulnerability, we will consider your research authorised, we will not pursue or support legal action against you for it, and we will work with you to understand and fix the issue quickly. If a third party brings legal action against you for research that followed this policy, we will make it known that you acted in line with it.

Good faith means that you:

• test only systems you own or are explicitly authorised to test, and never another customer’s account;
• access, keep and disclose no more data than you need to show the issue, and stop and tell us as soon as you meet customer or personal data;
• do not degrade, disrupt or destroy any service or data;
• report the issue to us privately and give us reasonable time to fix it before any disclosure.

This safe harbour covers only claims under our control. It does not authorise you to break any law or to act on behalf of a third party, and it does not bind any customer or other third party.

10. Contact

Security reports: security@stanch.ai. Other security questions: contact@stanch.ai. The same reporting address is published for machines at app.stanch.ai/.well-known/security.txt.