Trust
Security
What is in place, described at a level that is useful to a reviewer without being useful to an attacker.
Architecture
Sailient systems are being designed to run inside a boundary the operator controls, with no outbound dependency on Sailient infrastructure for them to operate. That is a design goal for every concept on this site — and, like the concepts themselves, not yet a verified property of a shipping system.
Data protection
Conduit is being designed so that requests pass a data protection boundary before a model is selected, so that the model that answered and the sources it used are recorded — which is what would make a request auditable afterwards — and so that any telemetry leaving a deployment stays under the operator's control. These are design goals, not yet verified properties.
This website
The public site is a static build served from the edge. It sets HSTS, a content security policy, frame-ancestors denial, nosniff, a referrer policy and a permissions policy. Form endpoints validate every field server-side and apply rate limiting and a honeypot.
The site does not expose an administration interface. Changes reach production only through the repository, review and build pipeline.
Application security
- All user input is treated as untrusted and sanitised server-side
- No provider API keys are present in browser code
- Dependencies are pinned and reviewed before upgrade
What we do not claim
Sailient holds no published certification or third-party attestation, and this page does not imply one. See the trust centre for the position on certifications.
Security contact
Vulnerability reports go to security@sailientgroup.com. The responsible disclosure page sets out what to include.