Security

Runtara's security properties come from how the system is built and where it is deployed, not from settings someone has to configure correctly. There are three boundaries, and each one holds on its own.

  • Where it runsA self-hosted deployment executes inside your infrastructure. Nothing reaches us.
  • How it runsWorkflows compile to WebAssembly and execute with no ambient access to filesystem, network, or credentials.
  • What it can doThe tools available to an AI step are fixed when the workflow is authored, not discovered at run time.
Three nested boundaries: the deployment boundary encloses the WebAssembly execution sandbox, which encloses the fixed set of tools an AI step may call.
Three boundaries, nestedA reviewer who distrusts one still has the other two.

Where it runs

The deployment boundary

A self-hosted deployment transmits no customer data to Runtara. The runtime executes inside your infrastructure, against your systems, using your model credentials. There is no Runtara-operated service in the path, no telemetry channel carrying your records, no support tunnel into your environment, and no copy of your data on our infrastructure.

  • Every component runs on infrastructure you own: the server, PostgreSQL for platform state, a separate PostgreSQL for your object model, and Valkey or Redis for execution checkpoints. All runtime state is written to a volume you control.
  • Deployable to your cloud account, your private cloud, or bare metal you already own.
  • Runs fully offline in environments with no route to the public internet in either direction. Updates are delivered as artifacts you apply on your own schedule.
  • Language models are called through your credentials against your endpoint. Prompts and documents travel from your infrastructure to your provider, under agreements your legal team has already signed.
Runtime, both PostgreSQL databases, Valkey or Redis, and the model endpoint all sit inside a closed perimeter marked your infrastructure, with the link toward Runtara crossed out.
The perimeter is closedYour model endpoint sits inside it, alongside everything else the platform runs.

How it runs

The execution boundary

A workflow definition goes through the Runtara compiler and is emitted as a WebAssembly binary. That binary is what executes, rather than an interpreted script carrying the privileges of the host process.

Inside the sandbox there is no ambient authority. Every effect a workflow has on anything outside itself passes through a host call that the runtime mediates. For a review that puts the unit of trust on the host boundary — a small, stable, auditable surface that holds across every edit to a business process.

  • Workflows compile to WebAssembly, targeting wasm32-wasip2.
  • There is one execution model. No configuration runs workflow logic outside the sandbox.
  • No raw filesystem, no raw network, no credential access from inside workflow logic.
  • Long-running work checkpoints after each step, so a crash or a deploy resumes rather than replays.
A workflow definition passes through the Runtara compiler to a WebAssembly binary that runs in a sandbox with no filesystem, network, or credential access, reaching them only through a mediated host call.
One way out, mediated by the runtimeEvery effect on anything outside the sandbox passes through a host call.

What it can do

The capability boundary

The tools an AI step can call are chosen when the workflow is authored and compiled into the binary that runs. At run time the model chooses among that fixed set. Adding a tool means editing the workflow and compiling it again, which is a change your review process already sees.

That bounds what a hostile document can achieve. The worst case is a tool from the authored set called with bad arguments, which keeps the review on one fixed artifact: the workflow itself.

  • The tool set for an AI step is fixed when the workflow is authored and compiled into the binary that runs.
  • Capabilities are granted at authoring time. There is no run-time path by which a model acquires one.
  • Every tool call is a workflow step, recorded with the inputs it received and the output it returned.
  • A step that requires human approval pauses the run until a person answers, and resumes with their decision.

What else a review of Runtara covers.

Vendor risk assessment is a different exercise here than it is for a processor. What you are reviewing is software running in your environment, under your controls, on your network.

Source-available runtime

The runtime is published under AGPL-3.0. Your engineers can read the code that will execute inside your environment before it does, and again on every version you take.

Documentation for your review

Architecture documentation and data-flow diagrams are provided for your security review, describing every component, every stored artifact, and every outbound call the runtime can make.

Your questionnaire answered

Send us the questionnaire your review runs on — SIG, CAIQ, or your own — and we fill it in, with the architecture documentation behind the answers.

DPA for managed Cloud

Managed Cloud is a different arrangement: there, Runtara does process data on your behalf, under a data processing agreement and with data kept in-region in the EU.

Send us your questionnaire.

Tell us which review you have to pass and what your security team needs to see. We will send the architecture documentation, answer the questionnaire, and walk your engineers through the deployment.