Security
Built for your security review.Walls no prompt can move.
Your agents can install anything, call anything and write anywhere. That is only safe if the walls are real. In Machine they live in the platform, below the agent, where no prompt can argue its way through.
One sandbox per session · Connector keys stay out · Nothing merges itself
- Isolation
- One sandbox per session
- Secrets
- AES-256-GCM, a key per project
- Principals
- People and service accounts
- Path to main
- A change request, with default-deny merge
01Isolation
Every session gets a machine of its own.
A session is not a tab in a shared runtime. It runs on its own machine, and the database refuses to give two sessions the same one. The wall between two of your sessions is the same wall between you and another customer.
inside one session
- Its own sandbox, with its own filesystem and its own lifetime
- A clone of your project repo, on a branch named after the session
- The tools, dependencies and runtime your project declares
- Only the secrets this session was granted, placed there at boot
sandbox wall
never crosses in
- Any other session: same project, same team, or another customer
- Connector credentials. Those are resolved server-side.
- Machine’s own upstream provider keys. No sandbox may hold them.
- Write access to main. A session can only propose.
One sandbox per session
Each session gets exactly one machine, and the database enforces it rather than a convention. Sessions never share a filesystem, and every machine has a bounded lifetime instead of living forever.
A microVM when you want one
On Machine’s own Platinum compute, a sandbox is a Cloud Hypervisor microVM. Daytona and E2B are supported too. The provider is a deployment choice, and we will tell you which one you are on instead of blurring them together.
One branch per session
The machine clones your repo and cuts a branch named after the session. Every edit and commit that session makes stays on that branch and nowhere else.
Disposable on purpose
The machine is not precious. A bad install or a wiped folder leaves with it. Only what the session commits survives.
02Credentials
A key is granted to a session, not pasted into a prompt.
A tool needs a real credential to do real work. So the honest question is not whether the machine ever holds one. It is which machine holds which key, who decided that, and what never gets in at all.
- 01
Stored
Encrypted with AES-256-GCM, under a key derived for each project.
- 02
Granted
The person’s role and the agent’s declared grant both have to allow it.
- 03
Delivered
Placed in the session at boot, by name, on tmpfs with mode 0600.
- 04
Used
The tool reads it from the environment. It is not written into the prompt.
- 05
Shredded
The file is wiped at shutdown, and the machine is destroyed with it.
Encrypted per project
Values are sealed with AES-256-GCM. Each project’s key is derived with HKDF-SHA256, so one project’s ciphertext cannot be opened with another project’s key. The envelope is versioned, so the scheme can move forward without a flag day.
Two gates, not one
In your project config, an agent declares which secrets it may ever be given. A session receives only the overlap of that grant and the role of the person who started it. So an agent can never reach past its own declaration, or past the person behind it.
Connector credentials never enter the machine
3,000+ apps in a click, plus MCP, OpenAPI, GraphQL and raw HTTP. The third-party credential is held and resolved server-side. The machine holds one scoped Machine token and calls through it. Machine’s own provider keys follow the same rule: no sandbox is allowed to hold them.
What we will not claim
A runtime secret granted to a session is a real environment value inside that session, because that is how a tool uses it. We would rather tell you so than call it invisible. The controls that matter are the two gates above, and the fact that the machine is destroyed with it.
03Identity & permissions
An agent is a principal, not a loophole.
Most AI tools let an agent reach whatever its person can reach. Machine does not. An agent identity carries its own policies, checked on their own, so it cannot inherit its way into something you never granted.
principal
persongroupservice account
may
resource type
accountprojectsandboxtriggerchannelmembergroup
A permission ties a principal to an action on a resource type.
Built-in roles, on every plan
account
- Owner. Full control of the account.
- Admin. Manages members, groups, roles and tokens.
- Member. Baseline membership of the account.
project
- Manager. Full control of the project, including members and delete.
- Editor. Creates and edits project content, and runs sessions.
- Member. Reads, runs sessions and fires triggers. The floor role for a project.
Enterprise
- SAML 2.0 SSO. Provider config, just-in-time provisioning and group-claim mapping. One identity provider per account today.
- SCIM 2.0. Directory sync over /scim/v2, with tokens you mint and revoke. Built against Okta and Microsoft Entra.
- Custom roles. Your own roles and fine-grained policy bindings, beyond the presets.
- Groups. Grant to a group once, instead of to twenty people twenty times.
Available on Enterprise, and on a self-hosted instance with an Enterprise licence. The built-in roles are free on every plan.
Service accounts
A service account is a real machine identity your account owns, not a human token in disguise. Policies attach to it directly. Every request it makes is checked against its own policies alone, so it never inherits the reach of whoever created it.
Scope a team to specific agents
Narrow a person or a group to named agents and skills inside a project: marketing may use this agent and that skill, and nothing else. Anything you leave unscoped stays project-wide, so narrowing is something you opt into, not something you have to undo.
04Control
Decide what needs a person before it happens.
Approval is not a switch buried in an admin panel. It is a block in your project config, versioned with everything else, that says which tool calls run, which wait for a person, and which are refused.
# reads run; writes and destructive calls wait for a personpolicy: default_mode: risk policies: # a name-only rule cannot gate the target; conditions can - match: gmail.send_email action: require_approval conditions: - arg: to match: /@example\.com$/ # anything else through this tool is refused - match: gmail.send_email action: block # gate a whole connector with one glob - match: stripe.* action: require_approvalThree actions
always_run, require_approval and block. A rule matches a glob over fully-qualified tool paths, so one line can cover a single call or a whole connector.
Gate the target, not just the tool
"May the agent send email?" is not a guardrail. Conditions match the arguments, so the rule can say "only to these addresses". An argument that cannot be evaluated fails closed.
No blanket "allow always"
Every gated call is approved on its own, with its arguments in front of you. There is no session-wide grant for a later call with different arguments to hide behind. That shortcut was removed at the enforcement point, not just from the UI.
Set the default you want
default_mode: risk lets reads run and sends writes and destructive calls to a person. A project with no policy block keeps the permissive legacy default, so set this yourself.
05How work lands
Opening a change request and merging it are different powers.
An agent can write all it likes on its own branch. Landing that work on main is a separate power it does not have unless you hand it over on purpose. And handing it over is itself a change someone has to approve.
- Step 00
The session works on its branch
Every edit lands on the branch cut for that session. Nothing the agent does shows up in any other session, or on main. - Step 01
It commits and opens a change request
When the agent wants work to outlive the machine, it commits and opens a change request against main. That is the only door. - Step 02
A person reads the diff
A change request is a diff. An agent rewriting its own prompt gets reviewed like any code change, because it is one. A change request whose manifest does not validate cannot merge at all. - Step 03
Merging is default-deny
Merge is its own capability, refused to every agent unless an admin grants it. That grant lives in your project config, so an agent cannot widen its own reach without a change request someone else approves.
06Audit
Recording is never what you pay for.
Every account action and every agent action is captured, on every plan. Your plan decides who can read, export or stream that record. Not whether it exists.
Account audit log
Membership, roles, policies, tokens, groups and IAM changes are recorded as they happen, on every plan.
Every gated tool call
Each call an agent makes through a connector becomes a row: the action, the actor, the session, the risk class, whether it ran, was denied or waited for a person, and who resolved it. Arguments are kept as a preview built by subtraction, so a credential cannot end up in the record.
Export it or stream it
Pull the log as CSV or JSONL, or have every event posted to your own SIEM over a webhook signed with HMAC-SHA256. Reading, exporting and streaming are Enterprise entitlements.
The repo is its own history
Configuration is files. Who changed which agent, skill or policy, and who approved it, is git history you already know how to read.
07Deployment & posture
Run it where your policy says it has to run.
Scoped access, explicit approvals, isolated execution and a complete audit record, in one platform.
Machine Cloud
The managed service. We run the control plane and the compute. You run the company.
Self-hosted
One Docker Compose stack on your own box, from the same images the managed cloud runs. Your database and your files sit on disk you control.
Your VPC or on-prem
A single-tenant deployment inside your own network. Air-gapped and other isolated setups are scoped with us, not self-served.
- SOC 2 Type I
- In progress
- SOC 2 Type II
- In progress
- GDPR
- Operated
We do not hold ISO 27001 or HIPAA, and we will not hint that we do. When a report lands, this line changes that day, and not before.
08Responsible disclosure
Found something? Tell us privately.
Please do not open a public issue for a vulnerability. Email the security contact with the affected version or commit, how to reproduce it, and the impact.
- Acknowledgement
- Within 3 business days
- Triage and severity
- Within 5 business days
- Coordinated disclosure
- Agreed with you, 90 days by default
Talk to us
Bring us yoursecurity review.
Send the questionnaire, the architecture questions and the deployment constraints. We would rather answer them properly than have you guess from a marketing page.
- One sandbox per session
- Nothing merges itself
- Audit recorded on every plan