Security
We assume the model can be fooled. So we built for it.
Prompt injection is an unsolved problem for every AI system. Rather than trusting a model to resist it, we designed the platform so that the damaging outcomes are prevented by infrastructure.
Guarantees
What the architecture guarantees, and what it mitigates.
We are explicit about the difference. This describes the design of a product in private development.
| Outcome | How it’s handled | Strength |
|---|---|---|
| Reading files outside the repos a session is working on | Each agent session runs in its own sandbox that contains only its bound repositories; nothing else exists to be read | Prevented by design |
| Stealing platform, organization or cloud credentials | Agent sandboxes hold no platform, organization or cloud credentials. Gateways attach short-lived, scoped credentials to each request after a policy check | Prevented by design |
| Reaching other customers, the host, the cluster or cloud APIs | Sandboxed runtimes, per-tenant isolation and default-deny networking | Prevented by design |
| Sending data to an attacker’s server | No network egress except through our gateways and your allowlist | Prevented by design |
| Leaking secrets through PRs or comments | Outbound secret scanning at the gateways | Mitigated |
| Getting malicious code merged | Independent Reviewer on a different model family, required checks, your branch protection, and a human approval whenever a run ingested untrusted outside content (on by default) | Mitigated |
Design
How the platform is built.
- Isolated agent sessions
- Every role runs in its own sandboxed pod with only its bound repositories, its own state, scratch space and a read-only image. A test suite runs inside the sandbox on every release to prove nothing else is reachable.
- No platform, organization or cloud credentials in sandboxes
- Forge, tracker, model, cloud and registry access goes through gateways that inject short-lived, least-privilege credentials and audit every call. The one opt-in exception: if you connect a personal model subscription, a short-lived access token for it is placed in your own sessions only.
- Your OpenRouter account, handled carefully
- If you connect your own account, your management key is vaulted, readable only by an isolated credential broker, and used solely to mint short-lived, spend-limited keys per workspace.
- Tenant isolation in the data layer
- Per-tenant namespaces, network policies, encryption keys and row-level security. Enterprise adds dedicated nodes, databases and customer-managed keys.
- Package gate
- Agent package installs pass through a gate that blocks non-existent, brand-new or malicious packages, a real risk with AI-suggested dependencies.
- Audit everything
- A tamper-evident audit log of sign-ins, admin changes, agent actions, approvals and merges, exportable to your SIEM.
Data
Your data stays yours.
- Never used for training
- We don’t train models on your code or conversations, and model traffic can be restricted to zero-data-retention providers.
- Regional
- Your data, including backups, stays in the region you choose (US or EU).
- Encrypted and deletable
- Encryption in transit and at rest with per-tenant keys, so deleting a tenant also destroys its backups.
Compliance
Compliance roadmap.
We are building to the controls these frameworks require from day one. Status reflects reality: nothing is claimed until an independent auditor has issued a report.
| Framework | Status |
|---|---|
| SOC 2 Type I (Security, Availability, Confidentiality) | Planned for general availability |
| SOC 2 Type II | Planned; observation period follows Type I |
| NIST CSF 2.0, SP 800-53 Rev. 5 (Moderate) alignment, SSDF, AI RMF | Controls mapped in design |
| GDPR data processing agreement | At launch |
| ISO/IEC 27001 and 42001 | Roadmap |