Security and data residency

Self-hosted Helix keeps your source code, API keys, and SSH keys on hardware you control, gives every agent session its own isolated sandbox so a compromised agent cannot reach your host or other sessions, and encrypts all stored credentials with an operator-held key. On Helix Cloud, your code stays in the region you selected and HelixML does not train on your data.

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

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.

Frequently asked questions