Security
How the platform is built, what protects your keys and data, what we have not yet done, and how to report a vulnerability.
This page describes what is actually implemented. Where something is not done, it says so — a security page that only lists strengths is a security page a procurement team cannot use.
Access to the platform
API keys are stored as hashes, never in plain text. A key is shown once at creation. If it is lost we cannot recover it, and we will not; you issue a new one and revoke the old.
Keys carry an environment: wi_test_ keys are metered but never billed, so an integration can be exercised fully before it costs anything.
Every request carries a request identifier, and administrative actions are written to an append-only audit log.
Traffic leaving the platform
Requests are checked before they are made. URLs are validated against server-side request forgery gates: private address ranges, link-local addresses, and redirects that would cross into them are refused rather than followed. A path disallowed by robots.txt returns an error instead of being fetched.
Requests toward one domain are paced regardless of how fast you send them. There is no setting that disables this, and support cannot disable it for you.
Data at rest and in transit
All connections to the API use TLS. Stored artifacts — rendered pages, screenshots — are retrieved through short-lived signed URLs, not through public object storage.
Observations and account records are held in the region chosen when the workspace is created. Tell us if you have a residency requirement before you sign up, so we can say plainly whether we can meet it.
Retention and deletion
Retention periods are configured per workspace and enforced by a scheduled deletion job rather than left to manual housekeeping. On termination we delete workspace data within 30 days, sooner on request, and confirm when it is done.
How the platform is built
The code is covered by automated checks that run before anything ships: type checking, unit tests, and a mutation guard that deletes each load-bearing mechanism in turn and fails if the tests still pass — because a mechanism no test defends is a mechanism nobody is protecting.
Data that leaves the system passes a further set of executable checks. Reports do not generate when one fails.
What we have not done
- No SOC 2 report, and no ISO 27001 certification. Neither has been undertaken. We would rather say that than imply otherwise.
- No third-party penetration test has been published. If your procurement requires one, tell us and we will discuss scope and timing.
- No published uptime history yet. Availability targets exist only on plans whose order form states them.
Reporting a vulnerability
Write to us with enough detail to reproduce the issue. We will acknowledge within three business days, keep you informed while we work, and credit you if you would like to be credited.
We will not take legal action against good-faith research that stays within your own account, avoids other customers' data, does not degrade the service for others, and gives us reasonable time to fix the issue before disclosure.
Last updated