Machine
Machine for teams

Agents your security teamcan sign off on.

Single sign-on, roles, approval gates and a full audit record, built into the platform where a prompt cannot argue with them. Run it on our cloud, in your VPC, or on your own hardware.
Talk to usStart free

SSO · RBAC · Governed agents · Complete audit records

enterprise controls
Sign-in
SAML 2.0 SSO with just-in-time provisioning
Directory
SCIM 2.0 sync, built against Okta and Microsoft Entra
Access
Custom roles, groups and service accounts
Approvals
Run, ask a person, or block, per tool call
Audit
Export as CSV or JSONL, or stream to your SIEM
Deployment
Machine Cloud, your VPC, or on-prem
1
Sandbox per session
2
Gates on every secret
3
Policy actions per tool
3,000+
Apps, one scoped token
01Identity & access

Your directory decides who gets in.

People sign in through your identity provider and land with the right role. Agents get identities of their own, so they never borrow more reach than you gave them.

SAML 2.0 single sign-on

Point Machine at your identity provider. People are provisioned the first time they sign in, and group claims map to roles. One identity provider per account today.

SCIM 2.0 directory sync

Joiners and leavers follow your directory. You mint and revoke the sync tokens yourself. Built against Okta and Microsoft Entra.

Custom roles and groups

Write your own roles with fine-grained policy bindings. Grant to a group once, not to twenty people twenty times.

Service accounts

A machine identity your account owns. Its requests are judged only against its own policies, never against the reach of whoever created it.

Scope a team to named agents

Let marketing use this agent and that skill, and nothing else. Anything you leave unscoped stays project-wide, so narrowing is a choice you make.

Built-in roles on every plan

Owner, Admin and Member for the account. Manager, Editor and Member for each project. The enterprise controls build on top of them.

SSO, SCIM, custom roles and groups come with Enterprise, on our cloud or on a self-hosted instance with an Enterprise licence.

02Approval gates

A person signs off before it happens.

Approvals live in your project config, versioned with everything else. Say which tool calls run, which wait for a person, and which never run at all.
your project config
# reads run; writes and destructive calls wait for a person
policy:
  default_mode: risk
 
policies:
  # gate the target, not just the tool
  - match: gmail.send_email
    action: require_approval
    conditions:
      - arg: to
        match: /@example\.com$/
 
  # any other send is refused
  - match: gmail.send_email
    action: block
 
  # one glob gates a whole connector
  - match: stripe.*
    action: require_approval

Run, ask, or block

Three actions: always_run, require_approval and block. One rule can cover a single call or a whole connector.

Rules read the arguments

Gate who an email goes to, not just whether email is allowed. An argument the rule cannot check fails closed.

Every call, on its own

Each gated call is approved with its arguments in front of you. There is no blanket "allow always" for a later call to hide behind.

Merging is default-deny

Agents propose work as change requests. Merging is a separate power no agent has until an admin grants it, and that grant is itself a reviewed change.

Gates are yours to switch on. A project with no policy block keeps the permissive default, so set default_mode: risk.

03Isolation & secrets

Every session gets walls of its own.

Each session runs on its own machine, with its own branch and only the keys it was granted. The walls sit below the agent, in the platform.
01

One sandbox per session

The database will not let two sessions share a machine. Sessions never share a filesystem, and every machine has a bounded lifetime.
02

microVM where you want it

On Machine’s Platinum compute a sandbox is a Cloud Hypervisor microVM. Daytona and E2B are also supported, and we will tell you which one you are on.
03

One branch per session

Every edit lands on a branch named after the session. Only what it commits survives, and it reaches main through a change request.
04

Connector keys stay outside

Third-party credentials are resolved server-side. The machine holds one scoped Machine token, and our own provider keys never go in.
how a secret travels
  1. 01Stored

    Sealed with AES-256-GCM under a key derived per project.

  2. 02Granted

    Your role and the agent’s declared grant must both allow it.

  3. 03Delivered

    Placed in the session at boot, by name, on tmpfs at mode 0600.

  4. 04Used

    The tool reads it from the environment, never from the prompt.

  5. 05Shredded

    Wiped on shutdown, and the machine goes with it.

Straight answer: a secret a session is granted is a real environment value inside it, because that is how a tool uses it. The controls that matter are the two gates and the shredding.

04Audit

Everything is recorded. On every plan.

Every account action and every gated agent action is captured, whatever you pay. Enterprise decides who can read, export and stream the record.
what one tool-call record holdsrecording
action
The tool call the agent made
actor
Who or what made it
session
The session it came from
risk
The risk class of the call
outcome
Ran, denied, or waited for a person
resolved by
The person who decided
arguments
A preview built by subtraction, so no credential lands in it

Account audit log

Members, roles, policies, tokens, groups and IAM changes are recorded as they happen.

Export it or stream it

Pull the log as CSV or JSONL, or post every event to your SIEM over a webhook signed with HMAC-SHA256.

Config with a history

Agents, skills and policies are files. Who changed what, and who approved it, is git history you already know how to read.
05Deployment

Run it where your policy says.

Same product, three places to run it. Pick the one your review needs, and bring any model on your own keys.
Managed

Machine Cloud

We run the control plane and the compute. You run the company.
Free to self-host

Self-hosted

One Docker Compose stack on your own box, from the same images our cloud runs. Your database and files stay on disk you control.
Single-tenant

Your VPC or on-prem

A deployment inside your own network. Air-gapped and other isolated setups are planned with us, not self-served.
Any model, your own keys: BYOK, your ChatGPT subscription, and managed model controls.
where we actually stand
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 imply it. This list changes the day a report lands, not before.

06Working with us

Bring us the hard questions.

We would rather answer your review properly than have you guess from a marketing page.
Step 01

Tell us what you need

Write to support@mytsi.org with your team, your tools and where Machine has to run.
Step 02

Send the security review

The questionnaire, the architecture questions, the deployment constraints. We answer them straight.
Step 03

Pick your deployment

Our cloud, your VPC, or on-prem. Isolated and air-gapped setups get planned together.
Step 04

Agree the terms

Custom pricing, with an SLA, a DPA and dedicated support on the Enterprise plan.
Talk to us

Put agents to workwith the controls on.

Tell us about your team and your review. Or start free today and add the enterprise controls when you are ready.
Talk to usStart free
  • SAML SSO
  • SCIM
  • RBAC
  • Approval gates
  • Audit export