In the Helios cloud, each run inside its own sandbox. The sandbox starts when the run starts and is destroyed when it ends. A workflow run stops after 30 minutes. Two runs never share a sandbox.

Can an agent see the credentials for our integrations?

No. The agent makes a normal API request from the sandbox. The request leaves through a proxy that attaches the credential for that host and that run. The token never enters the sandbox or the model's context.

How are secrets stored?

With envelope encryption. Each secret is encrypted with AES-256-GCM under its own data key, and that key is wrapped by a master key in AWS KMS. Secrets are write-only and are never passed to an agent.

Who in our company can see a workflow or its runs?

Whoever it was shared with. Each resource is either restricted to the people and groups it was shared with or visible to the whole organization. Resource roles are viewer, operator, editor, and admin. Shares can expire.

Can agents reach our private network?

Yes, over Tailscale. Configure it for the organization or for one project. With OIDC mode, Helios stores no Tailscale credential.

What stops a webhook trigger from being abused?

Signatures. Each request carries an HMAC-SHA256 signature and a timestamp, checked with a timing-safe comparison. Requests older than five minutes are rejected. Rotate the secret at any time.

Do you have a SOC 2 report?

Not one we can share on this page today. Book a demo and we will walk through the controls described here with your security team.

Yes. Helios uses the shared WarpBuild sign-in, which supports SAML 2.0 and OIDC. Contact support to enable it for your organization.

Can we see what an agent did after the fact?

Yes. Every run keeps a full transcript with each tool call, its arguments, and its result. Sandbox lifecycle events are recorded against the run and organization. There is no separate activity log for dashboard actions yet.

Security

Isolated runs. No agent holds a token.

Every run gets its own sandbox. Credentials are added at the network layer, outside the sandbox. This page describes each control and names the limits.

Book a demo

Get started free

One sandbox per run
Credentials never enter the sandbox
Full run transcripts

Isolation

Every agent works on its own computer

An agent is a process on a real machine, and that machine is the security boundary. The sandbox exists for one run and then goes away.

A fresh sandbox per run and per chat: Every workflow run and every chat starts in a new cloud sandbox with its own filesystem, processes, and network egress. Code the agent writes, packages it installs, and files it downloads stay inside that boundary and are gone when the run ends.
No sharing between runs: Two runs never share a machine. A run cannot read another run's files or reach its processes. The blast radius of a bad instruction is one sandbox.
A 30 minute limit: A workflow run stops after 30 minutes. Long tasks are split into several runs on a schedule.
No inbound traffic: Sandboxes accept no public inbound connections. The agent reaches out to do its work. Nothing on the internet reaches in.
Private networking, when you need it: Connect sandboxes to your private network over Tailscale. Configure it once for the organization or for one project. Choose an API key or OIDC. With OIDC, Helios stores no Tailscale credential at all.
Your own environment image: Build the sandbox image from your Dockerfile when the default image is not enough. The same isolation rules apply to custom images.

Credentials

Agents use your tools without your keys

The most valuable thing an agent touches is the credential that lets it act. Helios is built so the agent can act without ever holding it.

Credentials stay on the Helios side: When you connect GitHub, Slack, or Stripe, Helios stores the OAuth token or API key. The agent never receives it.
Injected by the egress proxy: The agent's code makes a normal API request from the sandbox. The request leaves through a proxy that attaches the credential for that host and that run. The response comes back. The key does not.
The model sees a redacted config: When an agent inspects how an integration is set up, encrypted fields are removed before the description reaches the model. It learns only that an integration is authenticated.
Scoped to the resources you pinned: Pin one repository, one channel, or one database to a workflow and that is what the agent can reach. The reach of a task is a decision someone made.
Databases with the user you choose: Connect Postgres, MySQL, or ClickHouse with the database user you pick, through an SSH tunnel if you need one. A read-only user gives the agent read-only access.
One hour credentials for Library files: When a run reads or writes Library files, it gets an S3 credential limited to the paths it was granted and valid for one hour.

Secrets and variables

Two kinds of values, treated differently

Variables and secrets look alike in the UI and behave very differently. The difference is what an agent is allowed to see.

Variables are configuration: A variable is a plain value like a channel name, a repository slug, or a threshold. Agents receive variables as run context and refer to them by name in the prompt.
Secrets are write-only: A secret is encrypted with AES-256-GCM under its own data key, and that key is wrapped by a master key in AWS KMS. Once saved, the API never returns the plaintext to the UI or to an agent.
Secrets never enter a prompt: Agents do not receive secrets as text. They reach your tools through integrations, where Helios applies the credential outside the sandbox.
Four scopes: Set a value on the organization, a project, a user, or one workflow. The most specific level wins. Editing requires the editor role on that resource.
Bring secrets from Infisical: Connect Infisical with Universal Auth and reference a secret by its Infisical path. Helios resolves it when the run starts.

	Variable	Secret
Stored as	Plaintext	Envelope-encrypted
Readable back	Yes	No
Passed to agents	Yes, as run context	No

Access model

Access controls for people and agents

Who someone is comes from sign-in. What they can touch is decided by grants on each resource and by their role in the organization. Both are evaluated by Cedar on every request.

One permissions model, everywhere: Every request is checked by the same policy engine, whether it comes from the dashboard, the API, or a run. Permissions come from grants.
Organizations are hard boundaries: A principal and a resource must belong to the same organization. That rule outranks every grant.
Groups and service accounts: Put people and service accounts in groups and share with the group. A service account is a named identity for automation. Disable it and everything it ran stops.
Sharing with expiry: Share a workflow, project, or integration with a person, a group, or everyone in the organization. Set the share to expire after a day, a week, or a custom date. You can never share above your own role.
Act as a person, by choice: A service account can use your own GitHub or Slack login for a grant when you turn that on. Otherwise it uses the Helios app credential.
SSO through WarpBuild auth: Helios uses the shared WarpBuild sign-in. Login with GitHub, Google, or your identity provider over SAML 2.0 or OIDC. Contact support to enable SSO for your organization.

Scope	Role	What it allows
Resource	Viewer	Can see the resource. Cannot change it or act through it.
Resource	Operator	Can also run it or work through it without changing what it is.
Resource	Editor	Can also change it, including what lives inside it.
Resource	Admin	Full control, including its secrets and the identities that act as it.
Organization	Viewer	Can see the organization's groups and service accounts. Creates nothing.
Organization	Member	Can also create projects and service accounts.
Organization	Admin	Can also manage groups and who belongs to them.

Run history

Read what every agent did

Trust comes from being able to check. Every run leaves a record you can open.

A full transcript for every run: Each run keeps its reasoning, every tool call with its arguments and result, timing, and error codes. Open any past run and read exactly what the agent did.
Tool calls as they happen: In chat, each API call and shell command appears in the thread while the agent works. Stop the run at any point.
Model calls are traced: Helios traces every model call with Langfuse. The trace links the prompt, the response, and the cost to the run that made it.
Sandbox lifecycle is recorded: Sandbox creation, pause, resume, and shutdown arrive over signature-verified webhooks and are stored against the run and the organization that caused them.
What is not here yet: There is no notification when a run fails and no export of run history. Read the transcript in the dashboard or over the API.

Spend controls

A bill you can read and cap

An agent that can run all night can also spend all night. Helios puts the ceiling in your hands.

Everything is priced in credits: Model calls and sandbox time are both charged in credits. You start with 5,000 free credits. After that, one credit costs $0.002.
A spending limit per product: Set a monthly limit for Helios, separate from the WarpBuild CI limit. Spend stops at the number you set.
Triggers stop at zero: When credits run out, scheduled and event triggers stop starting runs. Nothing queues up a bill you did not expect.
Auto refill, if you want it: Turn on auto refill with a threshold and an amount of your choosing. Leave it off and runs simply stop until you add credits.
Cost per run in the record: Model spend and sandbox cost are tracked per organization and visible next to the run that used them.

Network and webhooks

Control inbound and outbound access

Agents accept work from outside. A webhook fires, an MCP server answers. Each doorway is checked before anything walks through it.

Signed webhooks: Every webhook trigger has its own secret. Each request carries an HMAC-SHA256 signature and a timestamp. Helios checks both with a timing-safe comparison and rejects anything older than five minutes.
Secret rotation: Rotate a webhook secret whenever you need to. The endpoint keeps its address. Only the signature changes.
MCP servers that cannot point inward: When you attach an external MCP server, Helios resolves and checks the destination before every connection. The URL must be HTTPS. Loopback, private and reserved ranges, link-local addresses, and cloud metadata endpoints are refused.
Transport headers stay fixed: You can send an MCP server up to twenty custom headers, including Authorization. Headers that define the transport itself, such as host and content-length, are refused.
Encryption in transit and at rest: Traffic to Helios and between Helios and your tools is encrypted in transit. Data at rest is encrypted. Secrets get a second envelope on top.

Data and disclosure

Where your data goes, and who to call

No badges. A list of who holds your data, and an address for anyone who finds a problem.

Where data lives: Helios runs on cloud infrastructure in the United States. Every run executes in a cloud sandbox. Customer data is stored with the providers on the subprocessor list and nowhere else.
Subprocessors: Every vendor that touches customer data is listed with what it does. See the subprocessor list.
Your data does not train models: Helios does not use your prompts, files, or run output to train models. Model providers are listed as subprocessors.
Data processing addendum: A DPA is available for customers that need one. Read how to request it.
Responsible disclosure: Found a vulnerability? Email [email protected] with the steps to reproduce it. We reply to every report and will not take action against good-faith research.

Questions from security reviews

Bring your security review

Walk through each control with the people who built it.