How inis.run runs untrusted code.

Each execution runs in a dedicated virtual machine with its own kernel and its own memory — not a container. VMs are single-use: created for one session, destroyed afterwards, never reissued to another customer. A session can additionally drop administrative privileges inside the guest.

On the host, each VM runs under its own unprivileged operating-system identity with its own CPU and memory limits — no two VMs share one. If that cannot be set up, the session does not start.

A written isolation model for external review is in progress. Until it is published, we walk security teams through the design directly.

Sessions can run with deny-by-default egress: outbound traffic is limited to the domains you allowlist at session creation, and the policy can be changed on a live session through the API. Enforcement happens on the host, outside the VM, so code inside the sandbox cannot alter it.

POST /v1/sessions
{
  "egress": {
    "mode": "deny",
    "allow": ["api.openai.com"]
  }
}

All sandbox outbound traffic currently leaves through a single fixed address, 51.15.136.120, which you can allowlist on your own infrastructure. Any change will be announced in advance.

Connections are an opt-in way to call third-party APIs without giving the sandbox the credential. You bind an origin and a secret when creating a session; code inside calls the API as normal, and the credential is attached to the request at the host, on the way out. The secret is never placed in the sandbox — not as an environment variable, a file, or an argument — so model output, logs, and prompts cannot leak what the code never held.

This narrows exposure; it is not an absolute boundary. Code that controls its own outbound requests can recover an injected credential if the destination reflects it back, such as a debug or echo endpoint. The full behaviour, including this limit, is documented in Connections.

Sessions have explicit lifetimes: an idle timeout pauses a session, a maximum lifetime pauses it permanently, and a retention window for paused sessions destroys the data. Destroying a session deletes its disk and memory state. Every destroy, including automatic expiry, writes a deletion receipt to the execution log recording what was destroyed, when, and why. Receipts are readable per session through the API.

Checkpoints are kept on a separate lifecycle: they outlive the session they came from and are deleted when you delete them, or when the account is closed. Deletion receipts for checkpoints and templates are in progress.

Session and checkpoint storage on the host is encrypted at rest, with a disk-encryption key generated fresh on every host boot and never written to persistent storage. Anything archived to object storage — long-paused checkpoints and templates — is additionally wrapped under a key unique to your account before it leaves the host. Full detail is in the DPA, Annex 3.

The platform records session lifecycle events — created, executed, paused, destroyed. For sessions running under an egress allowlist, it also records every outbound connection attempt, allowed or denied, with destination and originating session. Sessions on the default open policy are not filtered, and their traffic is not logged.

Events are hash-chained per node, so gaps or edits are detectable, and the log can be exported. It is readable in the console and through the audit API.

inis.run is EU-owned and operated from Ireland, with no US parent entity. All hardware is physically located in the EU, and session data is processed and stored there. The sub-processor list names every third party that handles customer data. A data processing agreement is published in draft; final legal review is in progress.

Dependencies are scanned for known vulnerabilities on every change, and swept again weekly to catch CVEs disclosed against code that hasn’t moved. We have not commissioned a third-party penetration test. To report a vulnerability, see the disclosure policy.

Live status and per-check uptime are public at status.inis.run, measured from outside our own infrastructure so the page still reports when we are the thing that is down. There is no SLA today.

SOC 2 is in progress. For security questionnaires, email team@inis.run — we answer in writing.