> qubichelm

// security

Giving an AI your repository is a real decision. Here is what it can reach.

The short version: Claude only gets as far as the mode you choose, it never holds your real keys, and nothing it changes reaches your repository without a person approving it.

A sealed brass diving bell hanging on a chain in deep water

// reach, by mode

Most runs never touch a shell.

  • api sends one request with files attached. Claude can't change anything.
  • agent edits files with qubichelm's own tools, inside one run's copy of the repository. Every path is checked: nothing outside the copy, nothing in its git history, no following links out of it. There is no shell and no network.
  • cli gets a real shell, so it goes to the runner, below.
what each mode can reach
api
the files sent with the request
agent
its own copy of the repository
cli
a throwaway container on a separate machine
all
never your real keys, never your remote

// the runner

A separate machine, and a new container for every run.

Command-running work never executes on the machine that serves the app.

  • The runner talks only to the app, over an encrypted private tunnel. You never reach it, and the internet never sees it.
  • Each run gets a fresh container with its own user-space kernel (gVisor), so code inside can't call the host's kernel directly.
  • Inside: a read-only system, an unprivileged user, no capabilities, no way to gain privileges, and caps on memory, CPU and processes.
  • Internet access goes through an allow-list that refuses private networks, cloud metadata and the app's own servers.
  • The container and its files are destroyed when the run ends. A run nobody is watching is stopped.
a cli run, from the container's side
# the kernel is gVisor's, not the host's
uname -r            4.19.0-gvisor
# no route out except the allow-list
curl example.com    blocked
curl npm registry   200 via allow-list
curl metadata       403
# the key it holds is a one-run token
ANTHROPIC_API_KEY   one-time token, not your key

// keys and secrets

Your keys stay in the vault.

  • Secrets are encrypted at rest with AES-256-GCM, each under its own data key, sealed by a master key the app's own server account can't read from disk.
  • Claude's API calls go through a proxy for that one run, which swaps a one-time token for your key. The real key never enters a sandbox.
  • Runs that use the qubichelm API get a token that only lives as long as the run.
  • Secrets are write-only from the screen: you can replace one, never read it back.
what a run is given
repository      a copy; history read-only
anthropic key   one-time token via proxy
github token    never; the app commits
qubichelm api   token that expires with the run
other secrets   none

// your repository

Claude proposes. qubichelm commits, after you approve.

  • qubichelm reaches GitHub with a fine-grained token you create: one repository, the permissions you pick.
  • Only changed files come back from a run; qubichelm builds the diff and the commit from its own copy. Repository hooks never run.
  • The approval gate shows the diff before anything is committed or pushed. Reject, and nothing left the building.
  • Commits and pull requests are signed off by qubichelm, with Claude's summary attached, so the history says what happened.
pull request

Tidy README
opened by qubichelm from run kv58aa5b, 1 file changed, approved by a person

Merged

// your data and your account

Walled off, watched, and backed up somewhere else.

  • Organizations can't see each other

    Isolation is enforced by the database itself (row-level security), and the app connects with a role that can't switch it off.

  • Bot checks at the door

    Sign-in and sign-up go through Cloudflare Turnstile, checked on the server before a password is even looked at.

  • An audit trail

    Sign-ins, approvals, changes to people, secrets and settings, and which token did what.

  • Least privilege on the servers

    The account the app runs as can't read the secrets files and can't change what the system runs.

  • Encrypted offsite backups

    Every night, encrypted before upload, to storage in another region. Restores are tested.

  • Pinned and patched

    Runtime and Claude CLI versions are pinned and updated on purpose, and security advisories are checked against the stack as they land.

// found something

Tell us, privately.

If you think you've found a security issue, please report it through the contact on our security.txt rather than in public, and give us a chance to fix it first.

security.txtContact