Security
Built for trust
An agent that can run code, read your database, and act in your tools has to be worth trusting with all three. This page describes how Helios isolates agents, where credentials live, how secrets are encrypted, and what your administrators control.
- SOC 2 Type II
- GDPR
- Sandbox isolation per run
Architecture
Every agent works on its own computer
A Helios agent is a process on a real machine, and that machine is the security boundary. Everything an agent does — the code it runs, the files it writes, the calls it makes — happens inside a sandbox that exists for one run and then goes away.
- One sandbox per run
- Every run of every agent starts in a fresh cloud sandbox with its own filesystem, its own processes, and its own network egress. Code the agent writes, packages it installs, and files it downloads all live inside that boundary and go away with it.
- Isolation between runs
- Two runs never share a machine. A run cannot read another run's files, reach another run's processes, or inherit anything a previous agent left behind. The blast radius of a bad instruction is one sandbox.
- No inbound traffic
- Sandboxes are created with public traffic switched off. An agent reaches out to do its work; nothing on the internet reaches in.
- Sandboxes run on E2B
- The sandbox layer is provided by E2B, which appears on our subprocessor list alongside every other vendor that touches customer data.
- State persists on purpose
- What carries across runs is what you asked to carry: an agent's memory and the files in its workspace, stored durably and reattached to the next run. Nothing carries over as a side effect of a machine being reused, because the machine is not reused.
- Lifecycle events are recorded
- Sandbox creation, pause, resume, and shutdown arrive over signature-verified webhooks and land in an audit table, tagged with the run and organization that caused them.
Credentials
Agents use your tools without holding 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 being trusted with the credential itself.
- Credentials live server-side
- When you connect Slack or GitHub or Stripe, the credential is stored by Helios. Agents call those APIs through Helios, which attaches the credential at the edge of the request. The token stays on our side of the line.
- The model does not hold your tokens
- An agent asks Helios to call an endpoint. Helios makes the call. What comes back to the agent is the response, not the key that unlocked it — so a token cannot leak into a prompt, a log line, or a file the agent wrote.
- Even direct calls are credential-free
- Some tasks need to talk to a host straight from the sandbox. For those, Helios attaches the credential to the run's outbound requests at the network layer, scoped to the specific host it was pinned to and set to expire. The agent's code makes the request. It still never holds the key.
- The model sees a redacted config
- When an agent inspects how an integration is configured, the encrypted fields are stripped before the description ever reaches the model. It learns that an integration is authenticated, not what authenticated it.
- Envelope-encrypted secrets
- Every secret you store is encrypted with AES-256-GCM under its own data encryption key, and that key is itself wrapped by a master key in AWS KMS. One wrapped key opens one secret. Rotating or revoking a secret touches nothing else.
Data controls
You decide what an agent can reach
Access is scoped in layers, and the layers compose: the credential Helios holds, the project the agent lives in, and the specific resources it has been pinned to.
- Scoped variables and secrets
- A variable or secret belongs to the whole organization, to a single project, or to one task. A project's agents see the project's values and the organization's values, and nothing belonging to a project they were not put in.
- Pinned integration resources
- Pin a specific GitHub repository to an agent, and that is the codebase it works with. The reach of a task becomes a decision somebody made, written down, rather than whatever the credential happened to allow.
- Databases on your terms
- Connect Postgres, MySQL, or ClickHouse, optionally through an SSH tunnel, with the database user you choose. If that user can only read one schema, that is what the agent can do.
- Memory belongs to the agent that earned it
- What an agent learns across runs is stored against that agent and reattached to its next run, so context compounds where the work happens.
Identity & access
Two layers of roles, one source of truth
Who someone is comes from your identity provider. What they can touch is decided twice: once for the organization, and again for each resource inside it.
- SAML 2.0 and OIDC
- Connect the identity provider you already run. JumpCloud customers are in production today, and any provider that speaks SAML 2.0 or OIDC will connect. Administrators configure it themselves, from organization settings.
- Just-in-time provisioning
- The first sign-in through your provider creates the account, in the right organization, with the role you assigned. No invitations to chase.
- SCIM
- Helios follows your directory. Create a user there and the account appears here; deactivate them there and their access ends here.
- Resource visibility
- Every resource is either restricted to the people it has been shared with, or visible to the whole organization. You choose per resource.
| Scope | Role | What it allows |
|---|---|---|
| Organization | Admin | Runs the organization: identity, members, billing, and every resource in it. |
| Organization | Member | Creates agents, connects integrations, and runs work. |
| Organization | Viewer | Reads what has been shared with them, and changes nothing. |
| Resource | Admin | Owns this agent, project, or integration — including who else gets access. |
| Resource | Editor | Changes how this resource works, and runs it. |
| Resource | User | Runs this resource and reads its output. |
Network & webhooks
The ways in are the ways you opened
Agents accept work from the outside — a webhook fires, an MCP server answers. Each of those doorways is checked before anything walks through it.
- Signed webhooks
- Every webhook trigger carries an HMAC-SHA256 signature computed with a secret belonging to that webhook alone, plus a timestamp. Helios checks the signature with a timing-safe comparison and rejects anything older than five minutes, so a URL somebody found is not a way to start your tasks.
- Secret rotation
- Rotate a webhook secret whenever you need to. The endpoint keeps its address; only the signature changes.
- MCP connections that refuse to be redirected
- When you attach an external MCP server, Helios resolves and checks the destination before it connects, and again before every connection after that. The URL must be HTTPS. Loopback and localhost, private and reserved IPv4 ranges, IPv6 loopback and link-local and unique-local addresses, and the cloud metadata endpoints are all refused — so an MCP server URL cannot be aimed back at internal infrastructure.
- Transport headers stay ours
- You can send an MCP server the headers it needs, including Authorization, up to twenty of them. The headers that define the transport itself — host, content-length, connection, transfer-encoding, and the rest — are refused, so a server configuration cannot quietly rewrite the request underneath it.
- Encryption in transit and at rest
- Traffic to Helios and between Helios and your tools is encrypted in transit. Data at rest is encrypted, and secrets get a second envelope on top.
Compliance
Certified, and specific about it
SOC 2 Type II
Helios is SOC 2 Type II certified. The audit covers the controls behind everything on this page — how we handle access, change management, and the infrastructure your agents run on — observed over time rather than on one good day.
GDPR
We process customer data as a processor, on your instructions, in line with GDPR.
Subprocessors
Every vendor that touches customer data is listed, with what they do and where. E2B runs the sandboxes. Model providers run the models.
See the subprocessor listYour data does not train models
No data passing through Helios is used to train or improve AI models, and we hold zero data retention agreements with the model providers we work with. Your prompts, your files, and the output of your runs stay yours.
Questions we get from security reviews
Bring your security review
Start an agent on a real task today, or walk the architecture through with the people who built it.