Security controls for pilots.
Saykai audits your Nav2/ROS 2 configuration and catches unsafe changes directly inside your own CI — there is no separate backend your data passes through. This page describes how we approach security for early deployments.
Disclaimer: This page is informational only and does not modify any agreement with Saykai, Inc.
Pilot security, clearly scoped.
Saykai is early stage. For pilots, we scope security and data handling up front so there are no surprises. We can provide a short pilot security appendix covering the specific configuration used for your pilot.
What we protect.
Customer Content
"Customer Content" is your robot configuration, policy, and audit results — and by design, none of it is submitted to Saykai. The GitHub Action runs entirely inside your own CI runner.
- Safety Specs (saykai-policy.yml) and Safety Packs
- Behavioral simulation outputs and audit findings
- Run metadata, trace IDs, and signatures
- Your Nav2/ROS 2 configuration files
> Note: all of the above stays inside your own CI environment and your own repo. Saykai never receives it.
Account & Operational Data
Limited data we do handle directly, separate from your Customer Content, to run pilots and support you.
- Pilot contact and scoping information
- Operational logs for our own release infrastructure (e.g., binary download requests)
- Support communications
How we use Customer Content
You own your Customer Content, and it never leaves your own CI environment. Saykai does not receive, process, or store your robot configs, policy files, or Safety Packs. There is nothing of yours for us to sell.
Customer Content cannot be used to train any model, shared or otherwise — it never reaches Saykai's infrastructure in the first place.
Security controls for pilots.
Data Flow
In Transit: The only network calls the GitHub Action makes are HTTPS downloads of the signed runner binary and, if you opt in, posting a comment to your own PR using your own token.
At Rest: We do not store your Customer Content — there is nothing at rest to encrypt, because it never leaves your CI runner.
We confirm the exact data flow during pilot onboarding.
Access Controls
No Saykai personnel have access to your Customer Content — it runs and stays entirely inside your own CI environment, under your own repo's existing access controls.
Support access, if ever needed, is scoped to your own pilot contact information only.
Integrity & Auditability
Every run produces a Safety Pack cryptographically signed (Ed25519) and hardware-bound, so you can independently verify that a result hasn't been tampered with — stored in your own repo, not by Saykai.
We maintain limited operational logs for our own release infrastructure only.
Retention & Deletion
We do not retain your Customer Content, because we never receive it. Retention and deletion of policy files, Safety Packs, and audit trails are entirely under your own control, in your own repo and artifact storage.
Pilot contact and support data is deleted on request at the end of the pilot.
Operational Security
Subprocessors
Saykai may use vetted vendors for its own release infrastructure and business tools (hosting, email). None of these process your Customer Content, since the Action never sends it anywhere. For pilots, we can provide a current subprocessor list on request.
Incident Response
If a security incident affects Saykai's own release infrastructure, our goals are to contain the issue quickly, assess impact, restore service, and notify affected customers.
Compliance
Saykai aims to meet common enterprise security expectations. We do not claim ISO certification unless explicitly stated in writing.
Found a security issue?
If you believe you found a security issue, please email us with a description, steps to reproduce, and supporting evidence. We triage and respond based on severity.
Email security@saykai.com