Runtara security model and deploymentRuntara's security model: who operates each deployment, how workflows run in a WebAssembly sandbox, the audit trail, air-gapped options, and SOC 2 status.How Runtara worksdocsHow Runtara worksdocssecurity

Security model

How Runtara worksUpdated

Choose who operates the infrastructure. Keep model access and workflow permissions explicit. Review the record of what ran. There is no custom code for your team to own or maintain.

Deployment responsibilities

On Cloud, Runtara operates a virtual machine for your instance. With a customer-managed deployment, you provide the infrastructure. Your team chooses the connected systems and model account in both.

Scroll sideways to compare both deployment options.

Responsibilities for each Runtara deployment option
ResponsibilityRuntara-managed CloudCustomer-managed
InfrastructureRuntara provisions and manages a VM for your instance.You provide and manage infrastructure in your cloud or on-premises.
Hosting locationYour instance runs in a US or EU region, as you choose, and its data stays in that region.You choose the location and network configuration.
Business-system accessYou choose the connections and their permissions.You choose the connections and their permissions.
Model account and billYour credentials, your chosen endpoint, your provider bill.Your credentials, your chosen endpoint, your provider bill.
Runtime updatesRuntara operates the hosted instance.You apply supplied updates on your infrastructure, with routine update assistance included in Enterprise.

On Cloud, Runtara processes data on your behalf. Review the data processing agreement and deployment terms for the arrangement you will use.

Execution controls

Runtara runs each workflow in a WebAssembly sandbox. The authored workflow compiles to WebAssembly and has no direct access to files, the network, or credentials. It requests named host calls, and the runtime checks each request against the connection and scope declared for that step.

Workflow execution boundary
  1. 01 / INPUTDocuments and records

    Data enters the workflow.

  2. 02 / SANDBOXCompiled workflow

    No direct filesystem, network, or credential access.

  3. 03 / HOST CALLRuntime checks scope

    Only declared connections and resources are permitted.

Permitted request → Configured system or model endpointUndeclared request → Denied and recorded

The execution boundary

A workflow cannot reach an arbitrary host or resource. Each external effect passes through the runtime's declared host-call interface.

Inspect an execution example

The model's tool set

The model chooses from tools fixed when the workflow is authored. Adding a capability requires a workflow edit, review, and a new compiled binary.

Inspect a model capability example

Audit evidence

Your instance database keeps the context, actions, and decisions together. Inspect an individual run without assembling its history from separate exports.

  • What the step received. The source values and inputs used at that point in the run.
  • What the system returned. Machine events and the outputs of calls to connected systems.
  • Who approved the next step. The human response and timestamp alongside the resulting action.
View an example audit query

Illustrative invoice run INV-0847: one query returns the machine events, approval, and ERP write.

Customer-managed and air-gapped deployment

Deploy in your cloud or on-premises. Your team provisions, operates, secures, and backs up the infrastructure, and applies the software updates we supply. Enterprise includes routine update assistance and agreed operational support, with responsibilities defined in your proposal.

Review the connected data paths

Your workflows use the systems and model endpoints you configure. Where you use Runtara's hosted gateway, interface requests and configuration or authentication data may transit Runtara infrastructure, as described in the deployment terms.

Fully air-gapped environments

An air-gapped deployment has no network route to the public internet in either direction. A fully air-gapped installation has no route to Runtara infrastructure. Updates are delivered as artifacts for your team to apply. Model endpoints and business systems must be reachable within the permitted environment; because model calls always use your own credentials and endpoint, AI steps can run against a model endpoint you operate inside it.

Read the deployment terms

Security review and SOC 2

Enterprise includes architecture and data-flow documentation, security questionnaire assistance, and a review of deployment responsibilities. We help your team understand how Runtara fits your environment and internal requirements.

Current SOC 2 status

Runtara does not currently have a SOC 2 report. SOC 2 is on our roadmap. The documentation and assistance we provide today support your review; they are not an independent audit opinion.

Scope matters for every deployment

Any future SOC 2 report would apply only to the services and controls within its stated scope. It would not automatically cover your cloud or on-premises infrastructure. Your access controls, network, backups, and operating procedures remain your responsibility and part of your own security assessment.