Security overview

A short overview for people deciding whether to adopt it. Full documentation for security and IRB reviewers comes after the first installation.

Not released yet, and not yet checked on a real installation. The main rules below are checked by automated tests on the development machine; a few rest on design and configuration checks (see the end).

What it stops

A workspace holds only the files its owner may see among the data chosen for it, read-only.
A workspace goes out only through a proxy, to the places an admin set, and never reaches other workspaces or the portal.
A workspace holds no database or storage credentials.
When the agent wants to add data or release outputs, nothing runs until the researcher approves.
A release is visible only to people who may see all the data behind it.

What it does not stop

What the agent reads goes to the model provider (Anthropic) under the researcher's own Claude account.
Researchers can download the files they may see through the editor. Each transfer is recorded.
People an admin allows SSH can take files in bulk, and the product does not record SSH sessions or transfers.
Admins can see all data and releases, and the saved work folders, including the conversations with the agent.
Whoever has root on the server is trusted.

What we design against: an agent's mistakes, and instructions planted in what it reads

We assume the users are the institution's own researchers. The risk is an agent that means no harm but makes a mistake, or follows instructions hidden in something it reads.

So the network, credentials and mounts (the folders a workspace sees) are controlled from outside the workspace. People are trusted and agents are fenced: researchers can look at and take the files they work with, and the agent's reach is narrow.

The content of what the agent reads and writes is not inspected. What is controlled is what the agent can reach.

One installation serves one institution's own researchers; it is not an open public service, and no installation is shared between institutions.

Data access

A workspace holds only the files its owner may see and chose for it.

A workspace's /data holds only the files its owner may see among the data chosen for it, read-only. Source data is never copied.
Data a person may not see gets the same answer as data that does not exist, in lists, previews and requests.
Permission changes reach running workspaces at once.
Everything a workspace could ever see stays on its record, and the record never shrinks. Revoking access does not lift the restriction on that workspace's releases.
There are no deny rules. Data to keep apart goes in its own folder or a derived table.
Removing data keeps earlier versions so past releases stay reproducible. A separate, approved destruction procedure for legal deletion duties is planned.

Network

Workspaces have no direct route out. Every outbound connection goes through a proxy that allows only what an admin has opened for that workspace; by default, Claude and the package repositories.

Each workspace has its own internal network with no server address on it, so there is no direct way out.
Outbound connections go through one proxy and pass only the rules an admin set for that workspace. Changes apply at once and are recorded.
A workspace cannot look up internet names (DNS) itself; the proxy does.
No rule, “Fully open” included, reaches other workspaces, the gateway, or the portal and IDE addresses.
A workspace reaches the system through one door only: the gateway's workspace endpoint, which takes requests about that workspace alone and identifies it by its network address, so there is no secret inside the workspace.
The internal network opens only when an admin chooses “Fully open” or an internal-network rule; other ports of this server open only when an admin names the address.
The services that join the networks do not forward packets, so even root inside a workspace cannot route around the proxy.
Each workspace has its own web origin, so a page opened in one workspace cannot use another workspace or the portal.
Recent connections, allowed and blocked, can be viewed per workspace. This is the proxy's recent log, not a long-term record.

Credentials

Apart from the Claude token, nothing in a workspace holds a credential to another system.

Workspaces hold no database or storage credentials, and no credential to the portal.
The Claude token is a read-only file outside the work folder, handed to the Claude process when Claude starts. It is never in the environment's settings, the IDE or terminal environment, the work folder or a saved environment.
The token file is readable as the workspace user. The agent's file-reading tool is denied it, but commands the agent runs are not.
Data, secrets and the agent's rules are mounted read-only, so even root inside the workspace cannot change them. Processes run as a non-root user, nothing is privileged, and there is no Docker socket.
Stored Claude tokens and authenticator secrets are encrypted. API tokens are stored as hashes only.

Human approval

When the agent wants to add data or release outputs, it can only ask; the researcher approves.

The approved command runs once, as the workspace owner, exactly as requested. If the files change after the request, it does not run.
The server enforces the approval, so the agent cannot click through it.
Inside a workspace the owner has no admin rights, even when the owner is an admin, and requests from other workspaces are not visible.
By default, at most 10 requests can wait per workspace.
Only these two actions need approval. Running code, reading /data and using the internet addresses the workspace allows do not.

Releases

A release is visible only to people who may see all the data its workspace has seen.

So a model built from CT images and health records is never shown to someone cleared only for the health records.
When a source permission changes, who can see it is recomputed and the old value kept in its history. Revoke a permission and share links close at once.
A share link is an address. Permission is checked every time it opens, and only people with an account on the same installation can open it.
Widening who can see a release needs an admin's written reason, and the decision is recorded.
In a release's sources, data the viewer may not see appears without a name.
Outputs are checked before release: symbolic links, special files and paths outside the work folder are refused.

Sign-in can require a code from an authenticator app, and does for every account once the site faces the internet.

The code is asked only after a correct password, attempts are rate-limited, and a used code is never accepted again.
For accounts with an authenticator app, creating SSH keys and API tokens needs a code from the last 10 minutes. API tokens are refused from the internet by default.
Sessions last 12 hours at most, and end after 60 minutes without use.
HTTPS is supported, and required before the site faces the internet and to set up an authenticator app. Internet access comes through a tunnel, without opening server ports.
SSH is allowed per person by an admin, with registered keys only and no passwords.
Single sign-on (SSO) is planned.

Records

The audit log is append-only: the database accepts additions only.

Recorded: Sign-ins, commands run from the screen, the API or a workspace (refusals included), opens of workspaces and releases, release previews and downloads, file transfers through the web editor, permission changes and widenings.
Not recorded: What the terminal shows. SSH sessions and transfers (they appear only in OpenSSH's own logs). What the agent sends to the model API.

Your security and IRB reviewers get concrete records: who used which data, in which workspace, what was released, and who could see it. Compliance is assessed by your institution.

The ways data can leave

Source data stays on your server. There are four ways out, and they are known.

The model provider: What the agent reads goes to Anthropic's API under the researcher's own Claude account. Data terms follow each person's account settings, and the institution cannot enforce them. The product does not record what is sent.
Downloads in the editor: Researchers can view and download the files they may see in the web editor. Each file transfer through the editor is recorded.
SSH: Allowed per person by an admin. With it, files can be taken in bulk with scp or sftp. SSH sessions and transfers appear only in OpenSSH's own logs; the product does not record them.
Releases: People allowed to see a release can open and download it. Views and downloads are recorded.

What it does not do

What the product does not stop, or leaves to the institution and the server operator.

Admins can see all data and releases in the installation, and can open the work folders and environments saved with releases, including the conversations with the agent.
Researchers can use sudo inside a workspace. Data, network, secrets and the agent's rules are fenced from outside and do not change.
Whoever has root on the server is trusted. The database accepts only additions to the audit log, but root can change the file itself.
Nothing enforces that the agent follows its rules, and data content is not inspected: no de-identification or detection of personal data. De-identified data is a derived table an admin prepares.
Disk encryption and backups are the server operator's choice, not product features.
We claim no certification. Compliance is assessed by your institution.
A formal data-destruction procedure is not built yet.

The main rules are checked by automated tests

The main rules on this page are checked by automated tests; the workspace, network and mount rules run against real containers.

Examples of what the tests check

/data in a workspace lists exactly the chosen and permitted files
Connections and name lookups outside the rules are refused, and changed rules apply at once
Even “Fully open” reaches no other workspace, the gateway or the portal
Root via sudo cannot change /data, the secrets or the agent's rules
Who can see a release follows all of its data, and a revoke closes the link at once
An approved command runs once, and only if the requested files are unchanged
The Claude token is not in the work folder, a saved environment or the environment's settings

A few rest on the design and the configuration checks instead: encryption of stored secrets, keeping data rather than deleting it, and HTTPS. GPU use was checked by hand on the development machine, not by the automated suite. Nothing has been checked on a real installation yet.

How it works For institutions

At a glance