Security
Last updated April 18, 2026
Orika handles real source code, API keys, and agent output. This page explains the concrete controls we apply to each of those. If you want to report a vulnerability, jump to Responsible disclosure.
Transport and at-rest encryption
- All HTTPS traffic uses TLS 1.2+ with modern ciphers, terminated at our edge proxy (Railway).
- Our managed Postgres is encrypted at rest by the provider. Database backups use the same encryption.
- The session cookie issued by our identity provider is encrypted and signed with a rotation-capable key.
Authentication
Authentication runs through WorkOS AuthKit. We never store your password. Session tokens are short-lived; refresh tokens rotate on each use. Sign-in supports passwordless email and social providers enabled on our tenant. When we ship enterprise features, SSO/SAML and SCIM will land here.
Secrets
- Your provider API keys (Anthropic, OpenAI, etc.) stay on your machine in the OS keychain. They never touch our servers.
- Payment card details are handled by Stripe; we store only Stripe customer and subscription identifiers.
- Our own secrets (signing keys, service credentials) live in the platform secret store and are injected at process start. Access is audited.
- Webhook signatures from Stripe and other providers are verified before any action is taken.
Remote sandboxes
Pro and Max remote sandboxes run on Daytona. Each workspace is isolated from every other workspace — separate root filesystems, separate network namespaces, separate process trees. Sandboxes hibernate after a short idle window to minimize their attack surface while you are not actively working in them.
Least privilege
Application services run with scoped service accounts against their dependencies: Postgres, Stripe, WorkOS, and Daytona credentials are each narrowly issued. Developer access to production is gated behind SSO and logged; direct database access is avoided in favor of approved migrations and read-only replicas where possible.
Logging and monitoring
We log request metadata, error types, and coarse timing information to diagnose issues. We do not log prompt content, file contents, or secrets. Logs are retained for up to 30 days. Alerting runs against error-rate, latency, and availability metrics; on-call responds to production incidents 24/7.
Data deletion
Deleting your account deletes your profile, subscription record, and remote workspace metadata within 30 days. Remote sandboxes and their contents are deleted immediately on account closure. Billing records required by tax law are retained for the statutory period, then removed.
Incident response
We maintain an incident runbook covering detection, containment, user communication, and post-mortem. Material security incidents affecting user data will be disclosed to affected users within 72 hours of confirmation, with a follow-up post-mortem published when the investigation is complete.
Responsible disclosure
If you believe you have found a vulnerability, please email security@rikalabs.sh with:
- A description of the issue and its impact
- Reproduction steps (a working proof of concept helps)
- Your contact information if you want credit in the disclosure
Please give us a reasonable window to fix the issue before public disclosure. We do not have a paid bug bounty yet, but we will acknowledge contributors publicly (with permission) once the issue is resolved.
Compliance
We are not SOC 2 / ISO 27001 certified today. The controls above are what we build around, and we plan to pursue formal certification as the business matures. Check back here for updates.
Contact
Security questions: security@rikalabs.sh.