Trust
Security
What we actually do to secure the systems behind an AI employee. Mechanisms, not badges.
Last reviewed August 2026
Isolation
Each AI employee runs in its own container with its own workspace. The separation is structural rather than a matter of application code remembering to check: our database enforces row-level isolation between tenants, and that enforcement is covered by an automated test suite that runs on every change.
Access to our infrastructure
Administrative access is by key only, with password authentication disabled and the service moved off its default port. Secrets live in root-owned files on the host and are never committed to a repository.
Our hosts are deliberately not mutually trusting: the machine running customer workloads holds no key material for our other systems, so trust runs one way only.
In transit
Traffic is served over TLS 1.3. The obsolete TLS 1.0 and 1.1 protocols are refused rather than merely discouraged, and standard protective response headers are set on every response.
How we find our own problems
We run periodic security audits against our production host and track what they find to closure rather than to a backlog. Findings from those audits have changed our infrastructure, which is the point of running them.
What we do not claim
We hold no security certifications and display no compliance badges. We are not going to imply an audit standard we have not been through. If a certification matters to your procurement process, tell us and we will give you a straight answer about where we stand.
Reporting a vulnerability
If you find a security issue, tell us at chadi@peaklight.ai and we will respond. Please give us a reasonable window to fix it before publishing.
This page is being finalised. It states our current position honestly rather than waiting for legal polish. For the current version in writing, or for anything this page does not answer, contact us.