# Is OpenWork safe? Where your data lives, and the open-source alternative

> OpenWork keeps your files on your machine and sends prompts to the provider you pick, and Kortix is the open-source AI Operating System that keeps the whole system in a git repo you own. The difference is where each one draws the boundary and who reviews the work.

URL: https://openworkalternative.com/openwork-security

## Where the data goes, side by side

One desktop app and one owned system, measured on the data each one touches.

| | Kortix (recommended) | OpenWork |
| --- | --- | --- |
| Open source | Open source. Read it, fork it, audit it. | Yes for the app and core; the org control plane is separate. |
| Where files and data live | A git repo you own, on your infrastructure or Kortix Cloud. | Files stay on your machine; the desktop server listens only on loopback. |
| What leaves the machine | Prompt text and tool calls a session makes; connector credentials stay server-side. | Prompt text to the provider you choose; hosted workers are optional. |
| Where the model call goes | Through the LLM gateway, on your keys or the subscription you bring. | Direct to the provider, or through the AI Gateway in Cloud. |
| Access control and review | Per-resource permissions for people and agents. Roles, groups, and an audit trail. | Cloud members, roles and teams, desktop policies, agent permissions. |
| Self-hosting the perimeter | One Docker Compose stack on your box, sessions on a sandbox provider. | The control plane self-hosts on Kubernetes with MySQL and a worker runtime. |

OpenWork rows come from openworklabs.com and its repository; Kortix rows come from the Kortix docs and security page. Checked October 2026.

## Where an OpenWork prompt actually goes

In desktop mode, OpenWork keeps your files on the machine and sends each prompt to the provider you chose, using that provider's normal SDK. On OpenWork Cloud the desktop app gets one AI Gateway key per person, and every prompt goes to the gateway with that key; the gateway works out the provider and the right upstream key, swaps them in, and forwards the request. The gateway removes the person's AI Gateway key before forwarding, so the provider never sees it.

Provider keys are the part OpenWork guards closely. In its own words, members never hold provider keys; a provider key is either one key shared by the organization or a key that belongs to one person, and it is stored encrypted in Den and read only by the gateway. Usage is logged per request, so an admin sees tokens and cost per member, per skill, per model.

## What leaves the machine, and what does not

Your files stay local. OpenWork states that in desktop mode files stay on your machine and prompts go directly to the provider you choose, and that hosted cloud workers are optional. What leaves the machine is the prompt and the context the agent assembles for it, which is the same information any model call needs.

Hosted workers change the picture only if you turn them on. OpenWork describes them as running on sandboxed infrastructure, and treats the control plane as the place that adds shared identity, members, roles, hosted workers, and organization policy. A team that only needs local work never has to enable them.

## Where an owned system sends the same prompt

Kortix routes every model request through its LLM gateway, which finds the credentials, applies routing, access rules and budgets, and records the cost. Connector credentials are brokered server-side and never enter the machine, so a credential for an app an agent calls is held outside the session. Secrets are encrypted at rest with a key per project. A secret can be egress-enforced, where the sandbox holds a handle and Kortix substitutes the real value outside the sandbox only on approved HTTPS hosts; environment is the default exposure and egress-enforced is experimental.

The other difference is where the configuration and the memory live. In Kortix the agents, skills, memory and connector declarations are files in a git repo you own, so a change to what an agent may do is a diff someone reviews. A session is the unit that runs: one isolated sandbox per session, each on its own branch, and session work reaches `main` through a change request.

## Who reviews what the agent did

Kortix gates actions in the manifest, versioned with everything else. Each tool is set to run, to stop for a person, or to be blocked, and a rule can match the arguments of a call rather than only the tool. Approval gates are off until you set them, and an argument that cannot be evaluated fails closed.

```yaml
policy:
  default_mode: risk
policies:
  - match: gmail.send_email
    action: require_approval
  - match: stripe.*
    action: require_approval
```

OpenWork governs agents through its cloud: organization members, roles and teams, desktop policies that decide what the app allows per member, agent permissions for commands, file edits and MCP servers, plus SSO and SCIM on the paid plans and an audit trail on Enterprise. That is a permission model for what an agent may do on a machine. Kortix adds a review gate on top: agent output does not reach the default branch without a change request a person merges.

## Self-hosting the perimeter

Both products run on hardware you control, and they draw the boundary in different places. A self-hosted Kortix instance is one Docker Compose stack on your box, and agent sessions run off it on a separate sandbox provider, so the stack needs outbound access and a public URL for the sandbox to call back. OpenWork self-hosts its control plane with a Helm chart on managed Kubernetes, a MySQL-compatible database and a separate worker runtime, and presents Docker Compose as an evaluation path.

The practical question for a security review is what the company has to sign off. With Kortix, the thing you own is the whole system and the repo that defines it, and a self-hosted instance runs from the same images as the managed cloud. The details are in the [self-hosting guide](/self-hosting), and the tool-for-tool view is in the [OpenWork vs Kortix comparison](/openwork-vs-kortix).

## Questions a security review asks about OpenWork

Each answer is sourced to the page it comes from.

### Does OpenWork send my files to the cloud?

No, not in desktop mode. Files stay on your machine and prompts go to the model provider you choose. Hosted cloud workers are optional and run on sandboxed infrastructure ([openworklabs.com](https://openworklabs.com)).

### Where does OpenWork keep my data in the cloud?

On OpenWork Cloud the control plane stores organization and access state in a MySQL-compatible database on PlanetScale, and worker files and runtime state live on the worker's storage. Provider keys are stored encrypted and read only by the gateway ([OpenWork security and operations](https://openworklabs.com/docs/cloud/security-and-operations), checked October 2026).

### Is OpenWork safe for a team?

It ships SSO and SCIM on the cloud plans, desktop policies, agent permissions, and an audit trail on Enterprise, and it encrypts provider secrets and SSO configuration. What it does not add is a review gate on agent output, which is where Kortix's change requests fit.

### Where does Kortix keep our data?

Agents, skills, memory and connector declarations are files in a git repo you own. Run it on Kortix Cloud, in your VPC, or on your own on-prem network, and self-host is free. Connector credentials are brokered server-side and never enter the machine.

## Run agents where you can read every change

Open source, any model with your keys, self-host or managed cloud.

[Try Kortix](https://kortix.com) · [Compare OpenWork and Kortix](https://openworkalternative.com/openwork-vs-kortix)

Open source · Any model, your keys · Self-host, VPC, or on-prem