Security and data residency
How Helix isolates agent work, where your code and credentials live, and what "runs on your infrastructure" actually means.
The core promise
Helix is designed so that code and credentials stay where you put them. When you run Helix on your own infrastructure, your source code, API keys, SSH keys, and .env files never leave your hardware — not even for inference, if you configure local models.
When you use Helix Cloud, your code is held in our infrastructure within the region you selected. We don't train on your data.
Agent isolation
Every spec task session runs in its own isolated container with:
- Separate filesystem — no access to the host or other sessions
- Separate network — each session gets its own network bridge with a non-overlapping subnet; sessions cannot see each other's traffic
- Separate Docker daemon — via the Hydra isolation layer inside the sandbox
Even if an agent runs a malicious command (or you make a mistake in a spec task), the blast radius is the session's container. The host machine and other sessions are unaffected.
See Sandboxes and the desktop environment for the technical architecture.
Credentials and secrets
Credentials used by agents are never stored in plaintext. Helix uses AES-256-GCM encryption at rest for:
- Git provider OAuth tokens (GitHub, GitLab, Bitbucket)
- SSH keys
- AI provider API keys
- Any secrets you configure for assistants or API integrations
The encryption key is operator-controlled (set at install time via helix-encryption-key). Helix never sees an unencrypted copy of your secrets after they're stored.
Inside a sandbox, agents access your source control provider via Helix's credential proxy — the agent never receives your raw OAuth token or SSH key. If the sandbox is compromised, the credential it used expires with the session.
Inference routing
When agents call LLMs, the request routes through Helix's /v1 proxy on your control plane. The raw API key is on the control plane; the agent in the sandbox gets a short-lived session token to the proxy.
For users who want LLM inference to stay on-premises entirely, local models can be served via Ollama or vLLM on the same cluster. In this configuration, no request leaves your infrastructure.
Code never reaches Anthropic/OpenAI directly
When an agent calls an LLM via the Helix proxy, the prompt content (which may include code snippets) goes to the LLM provider you configured. For Anthropic and OpenAI, this is subject to their API terms. If this is a concern:
- Use a self-hosted vLLM or Ollama endpoint (inference stays on-premises)
- Use Anthropic's zero data retention API tier (opt-in via their console)
Data residency
| Deployment | Where your data lives |
|---|---|
| Helix Cloud | HelixML-managed infrastructure (region selected at sign-up) |
| Mac App | Your machine only — nothing leaves your hardware |
| Linux / Kubernetes | Your cluster — you control every node |
| Sovereign Server | Your data centre — the physical hardware is yours |
Access controls
- Organization-level isolation — all resources (projects, tasks, repos, secrets) are scoped to an organization. Users in organization A cannot see organization B's data.
- Role-based access — team members can be granted admin, member, or read-only roles per project
- SSO — Helix supports OIDC-compatible SSO providers; see Sovereign Server — SSO & RBAC for configuration
- Audit logging — all user actions are logged on self-hosted deployments
For enterprise access control configuration (RBAC, SSO, SCIM), see Sovereign Server — SSO & RBAC.