Security. How Orrin keeps your code to its sandbox, who can see what, and how to tell us if you find a problem.

Every run gets its own Firecracker microVM, created for that run and destroyed when it ends. A run never shares a machine with another run. Its network reaches your package registry and nothing else unless your project allows more.

On Enterprise, the sandboxes run in your own AWS or Google Cloud account, and model calls go through your own endpoint, so no code leaves your account.

• Orrin asks GitHub and GitLab for the permissions to read, push to its own branches and open pull requests. It never asks for permission to merge.
• Each project lists the folders, commands and secrets Orrin may use. Anything else waits for an approval.
• Our staff cannot read your code. Access to run records needs a support ticket from you and is logged.
• SSO with SAML and SCIM is available on Enterprise.

Data is encrypted in transit with TLS 1.2 or later and at rest with AES-256. Secrets you give a project are stored in a dedicated key management service and are only decrypted inside a run's sandbox.

Orrin Labs has a SOC 2 Type II report, covering March to August 2026, available under NDA. ISO 27001 certification is in progress and expected in the first half of 2027. We run an external penetration test twice a year.

We give customers 30 days' notice by email before adding a subprocessor.

If you find a security problem, write to security@orrin.dev. We reply within one working day, keep you updated until it is fixed, and will not take legal action against research done in good faith. We pay rewards for valid reports, from $250 to $10,000.