Trust centre
Built to be trusted with your evidence
ScoutSentinel holds screenshots of your customer journeys, test credentials and the record of what broke and when. This page describes how that data is handled. Questions to security@scoutsentinel.com.
Data handling
ScoutSentinel processes three kinds of data: account and configuration data (who you are, what you asked us to watch), observations and evidence (what our probes saw), and secrets you give us so probes can complete a journey (test accounts, test cards, API keys).
Evidence is captured from your own public surfaces using test identities you configure. Use synthetic identities and payment provider test paths; do not point a Watch at real customer accounts. Known secret values are redacted from screenshots, HAR archives, logs and model prompts before storage.
Metadata is stored in the database region chosen at organisation creation (EU or US). Evidence buckets are created in the same region. Retention is a plan entitlement enforced by storage lifecycle rules and by the API; see data retention.
Tenant isolation
Every tenant table carries an organisation id, every query runs through helpers that require an organisation context, and row-level security is enabled as a second line of defence. A two-organisation isolation suite runs in CI.
Authentication
In-house, standards-based: passkeys and password with TOTP, OAuth 2.1 sign-in with Google, Microsoft Entra and GitHub, SAML and OIDC single sign-on on Business and Enterprise, session and API key management with an audit trail.
Audit log
Append-only record of every mutation to Watches, integrations, users, retention and evidence access, exportable on Business and Enterprise plans.
Secure development
Static analysis (Semgrep), dependency audit, secret scanning and end-to-end tests on every change. Infrastructure is defined as code and reviewed.
Encryption and secrets
- In transit: TLS 1.2 or later everywhere, HSTS with preload on public hosts, mutual TLS between private probes and the platform.
- At rest: tenant secrets are envelope-encrypted with a per-organisation data key wrapped by a configured master key. The execution service accesses that key to decrypt secrets when required. Database and object-storage encryption also depend on the deployment's provider configuration.
- In use: secrets are decrypted only inside the probe execution step, never logged, never written to evidence, never sent to a model. Rotation is a single action in the app and is recorded in the audit log.
- Integrity: every evidence object is SHA-256 hashed before its metadata row is committed, and the application cannot edit a stored artefact or its record. The hash is shown beside the artefact and survives object expiry. A hash alone does not prove evidence was never changed, so before the pilot we are introducing a signed, independently timestamped evidence ledger: artefact hashes are chained, sealed into checkpoints signed with a key held outside the application, and timestamped by an independent authority, and an open verifier lets anyone check an evidence pack offline without trusting us.
Evidence access
Evidence is never served from a public bucket. Downloads go through the API, which checks organisation membership and role, issues a short-lived signed URL and writes an audit row naming the user, the artefact and the time. Public report links, where you enable them, expose a chosen report rather than raw evidence and can be revoked at any time.
Business and Enterprise plans can place a legal hold on the evidence behind an Event and export evidence packs with a manifest of hashes.
Synthetic traffic policy
HTTP and browser probes identify themselves with the user agent ScoutSentinel/0.1 (+https://www.scoutsentinel.com/synthetic) and an X-ScoutSentinel-Probe identifier. These markers are not cryptographic proof of origin and should not be your only access-control check. Probes execute configured checks; passive discovery uses configured sources rather than broad port scanning or speculative crawling.
The full policy, including how a site owner can ask us to stop, is at /synthetic.
Sub-processors
Third parties that process customer data on our behalf. We give 30 days' notice before adding one; subscribe to changes by emailing privacy@scoutsentinel.com.
| Sub-processor | Purpose | Location | Data |
|---|---|---|---|
| Cloudflare, Inc. | Compute (Workers, Queues, Workflows, Browser Run), object storage for evidence (R2), DNS and CDN, transactional email | Global edge; storage region chosen per organisation (EU or US) | All processed data in transit; evidence objects at rest |
| PlanetScale, Inc. | Managed Postgres, the source of truth for product data and evidence metadata | EU or US region chosen per organisation | Account, Watch, Observation, Event and audit data |
| Stripe, Inc. | Subscription billing and payment processing | United States, EU entities for EU customers | Billing contact, payment method (never stored by us), invoices |
| Anthropic, PBC | Model inference for the Watch composer, Event explanations and materiality annotations (via Cloudflare AI Gateway) | United States | Redacted step plans, assertion results and evidence summaries; never secrets or raw credentials |
| Twilio Inc. | Programmable voice for telephone journey probes | United States, with UK and EU numbers | Numbers dialled, call audio and transcripts for configured Watches |
Last reviewed 17 September 2026.
Responsible disclosure
If you believe you have found a security issue in ScoutSentinel, email security@scoutsentinel.com. Include enough detail to reproduce the issue. We acknowledge reports within two business days, keep you informed of progress, and credit reporters who wish to be named once a fix has shipped.
Please test only against accounts you own, avoid accessing other customers' data, do not run denial-of-service or automated scanning against production, and give us reasonable time to fix before publishing. We will not pursue legal action against good-faith research that follows these rules. A security.txt is published at /.well-known/security.txt.
Status and incidents
Platform status, planned maintenance and incident history are published at https://status.scoutsentinel.com. Our own runner health is monitored with canary journeys from every location; when a location's canaries fail, results from that location are recorded as unknown rather than as your failure.
Compliance roadmap: SOC 2 Type I is planned for the first year of general availability, with ISO 27001 to follow based on customer demand. We will publish reports here when they exist and will not claim them before then.