Get started
Explore Crewship
GitHubGet started

Security

Security, built in.

The crew is the trust boundary. This page explains, in plain words, what the Go server does to keep each crew in its own container, keys sealed and the record honest, and what is not done yet.

Threat model Report a vulnerability

Isolation

Every crew runs in its own container: non-root, read-only root, cap-drop ALL, no Docker socket.How it works

Audit

An append-only journal chained with HMAC-SHA256. crewship journal verify exits non-zero on a break.How it works

Secrets

AES-256-GCM vault, a sidecar that adds API keys outside the agent, AGE-encrypted backups.How it works
01IsolationShipped

The crew is the boundary.

Every crew runs in its own Linux container. Agents in one crew share it; crews never share one. Crews do still share one Docker network, so network isolation between crews is not enforced yet.

crew · Releasedevcontainers/base:bookworm
RileyClaude Code · lead
SamCodex CLI
ContainsgitghNode 22Python 3.12Terraform 1.9bash
sidecar 127.0.0.1:9119egress allowlistread-only root

How it works

  • The Go server creates the container through your runtime: Docker, Podman, Colima, OrbStack, Rancher Desktop or Apple Containers.
  • It runs as a non-root user, with a read-only root filesystem, every Linux capability dropped and no new privileges.
  • There is no Docker socket inside the crew. A crew marked Privileged gives most of this up, on purpose.
docs.crewship.ai/security/container-isolation
02CredentialsShipped

How a key reaches an agent.

You add a key once. Crewship encrypts it, assigns it to a crew or an agent, and hands it over at the last possible moment.

How it works

  • Keys are stored with AES-256-GCM. There are 11 credential types, from API keys and OAuth to SSH keys and certificates.
  • For Claude Code, Codex and Gemini, a sidecar in the crew listens on 127.0.0.1:9119 and adds the API key to the outgoing request. The agent process never reads it.
  • OAuth tokens, Cursor, Factory Droid, other OpenCode providers and SECRET values do reach the container environment. We say so plainly.
  • Retiring a credential erases the key for good and keeps its ID and audit history. Chat output is scrubbed for credential patterns.
docs.crewship.ai/security/encryption
03AccessShipped

Who can do what, checked in code.

Five workspace roles: Owner, Admin, Manager, Member and Viewer. The check is not a convention; it is enforced on every route.

Members 4
  • PaulAll files · all keysOwner
  • JaneApproves runsManager
  • RileyGitHub key onlyAgent
  • SamNo keysAgent

How it works

  • Every route in the Go server that changes data declares its required role when it is registered. A test in CI fails if one does not.
  • Agents only get the credentials assigned to their crew. Guests see only what they are invited to and can never become Admin.
  • Member and role changes, credential changes and CLI token changes are written together with a chained audit record.
docs.crewship.ai/security/rbac
04ArtifactsBeta

Shared work without shared secrets.

Pages, documents and the artifacts on the way are where people and agents make things together. They are built so the work can be shared without the keys behind it.

How it works

  • A Page holds no query and no credentials. Agents and routines push JSON into it, and each panel has its own permissions.
  • Documents are private to their owner and the workspace Owner by default, with checkpoints and a history you can restore.
docs.crewship.ai/guides/pages
05AuditShipped

A record you can verify.

Every model call, tool use and decision goes into an append-only journal. You do not have to trust it; you can check it.

How it works

  • Each entry is chained to the previous one with a keyed HMAC-SHA256.
  • crewship journal verify walks the whole chain and exits non-zero if anything was changed or removed.
  • The journal is searchable and exportable, and OpenTelemetry spans can go to your own collector (beta).
docs.crewship.ai/security/audit
06ApprovalsBeta

A person decides before it runs.

Important work waits for a person. A manager or above approves or denies in the Inbox, and the decision goes on the record.

How it works

  • A gate can hold an agent run before it starts, and a mission task before it counts as done.
  • It does not yet pause a risky tool call in the middle of a run. That is on the list below.
docs.crewship.ai/guides/harbormaster
07Supply chainShipped

Backups and updates you can trust.

Release images and checksums are signed, and backups are encrypted. macOS binaries are not code-signed or notarized.

How it works

  • Images and checksums are signed with cosign, with SBOM and provenance attestations. A CVE scan and an amd64/arm64 smoke test run before an image is tagged.
  • crewship self-update checks the SHA-256 checksum and the Sigstore signature before it swaps the binary, and takes a snapshot before migrating.
  • Backups are AGE-encrypted archives of a workspace or a crew, with a dry-run restore.
docs.crewship.ai/guides/upgrades
08Not done yetNot yet

What is missing today.

Crewship is an open beta. A security page should say what is missing, so here it is.

Not done yet 5
  • Single hostSeveral hosts and Kubernetes are future work.
  • Shared networkCrews share one Docker network; isolation between crews is not enforced yet.
  • Mid-run tool callsApprovals gate a run and a task, not a risky call in the middle of a run.
  • Egress allowlistA guardrail for clients that use the proxy, not a network firewall.
  • macOS buildsNot signed or notarized yet, so Gatekeeper warns.

How it works

  • Single host only. Several hosts and Kubernetes are future work.
  • Crews share one Docker network; network isolation between crews is not enforced yet.
  • The egress allowlist is a guardrail for clients that use the proxy, not a network firewall.
  • macOS builds are not signed or notarized yet.
docs.crewship.ai/security/threat-model

Read more in the docs

All security docs