Helix Security
Helix is designed to be an autonomous engineer, not an uncontrolled one. Every layer of the system has controls to prevent accidental or malicious damage.
Approval gates
The critic reviews actions before they execute. It classifies actions by risk:
- Read-only — file reads, log tailing, status checks.
- Setup — sandbox provisioning and repository cloning.
- Write — file writes, schema changes, command execution.
- Destructive — deletion, infra tear-down, credential changes.
- External — calls to third-party APIs or deployments.
The critic can approve automatically, require human confirmation, or reject an action based on the configured autonomy level.
Guardrails
Guardrails enforce high-level policy instead of low-level filesystem regexes. The Daytona sandbox already isolates the filesystem, so Helix guardrails focus on:
- Preventing destructive commands on production systems.
- Blocking secret leakage in logs and tool output.
- Enforcing team quotas for compute, tokens, and sandboxes.
- Rejecting actions that exceed the current autonomy level.
Role-based access control
Helix respects the team role of the user who started the conversation:
- Owner — full access, including plan approvals and admin actions.
- Admin — can manage team settings and approve high-risk plans.
- Member — can run Helix in permitted workspaces.
- Guest — read-only access unless explicitly granted write permissions.
Audit logging
Every tool call, plan approval, and credential access is written to the audit log. Audit records are immutable and scoped to the team. Owners and admins can export them from the team settings page.
Secret handling
Secrets are stored encrypted in Supabase and decrypted only inside the agent server when a tool needs them. They are never sent to the browser, never written to the sandbox filesystem, and redacted in logs.
Runtime isolation
Each conversation runs in its own Daytona sandbox. Sandboxes do not share processes, network namespaces, or persistent volumes unless explicitly configured. When a run ends or a sandbox is destroyed, its temporary state is removed.
Incident response
If Helix detects an unexpected outcome — for example, a command that deletes files outside the project directory — it pauses the run, marks the task as failed, and requires an owner or admin to resume.