​

Threat Model

​

Adversary

• The host kernel and container runtime.
• The Crewship binary and sidecar binary on disk. The curl | sh installer verifies the SHA-256 against a signed checksums file and — when cosign is on PATH — also verifies the Sigstore signature against the project’s release workflow identity. Homebrew and Docker Compose installs rely on the upstream channel’s own integrity; operators in regulated environments should run cosign verification manually. See Install.
• The operator running crewship.

• Anything the agent reads — system prompt, user prompt, tool output, fetched documents, MCP server responses.
• The agent’s own output, until the scrubber has run over it.
• Network destinations the agent wants to reach.

​

Layer 1 — Container isolation

• UID 1001 (agent) for the agent process; UID 1002 for the per-agent sidecar.
• CapDrop: ["ALL"] as the starting capability set.
• CapAdd: ["NET_RAW"] is added back so the agent can use ping and other ICMP-shaped probes inside its sandbox. This is the one capability that survives the drop.
• no-new-privileges security opt + read-only root filesystem
  • PID limit + memory + CPU quotas + tmpfs /tmp with a 500 MB cap.
• No Docker socket bind-mounted into the agent container. The agent cannot launch sibling containers, mount the host docker.sock, or enumerate peers.
• Mounts: the workspace directory read/write and /output/<agent>/ for any persistent files; nothing else by default.
• NetworkMode is instance-wide, set from the server config (p.cfg.Network) — not per-agent. Operators who need per-agent network isolation must build it at the host network layer (e.g. per-crew Docker networks) rather than rely on the runtime default.

​

Privileged-mode escape hatch

​

Blast radius if the agent escapes

​

Layer 2 — Sidecar credential broker

1. Credentials live in the host’s encrypted store (internal/sidecar/credstore) encrypted with AES-256-GCM using the operator’s ENCRYPTION_KEY.
2. A per-agent sidecar runs alongside the agent container, also as a non-root user (UID 1002).
3. The agent’s outbound HTTP traffic is proxied through the sidecar. When the agent calls https://api.openai.com/..., the sidecar:
   • Checks the destination against the per-agent allowlist.
   • Looks up the credential mapped to that destination.
   • Injects the Authorization header on the way out.
   • Forwards the response back.
4. The sidecar’s credentials are loaded once at startup over stdin as a base64-encoded JSON payload. They are never written to the agent container’s environment.

• Read API keys via printenv, cat /proc/1/environ, or any other env-var introspection — credentials don’t live in the agent’s env.
• Reach an HTTP destination not in its allowlist as long as it uses the HTTP_PROXY / HTTPS_PROXY env vars that orchestrator injects (http://127.0.0.1:9119). Well-behaved Go/Python/Node HTTP clients honor this; clients that ignore proxy env vars (or that open raw sockets) can bypass it. Hard egress filtering at the network layer is the operator’s responsibility — see Container isolation for hardening options.
• Exfiltrate credentials by tricking the LLM into echoing them — the scrubber (Layer 3) drops anything that looks like a key in the agent’s output before it lands in the journal or web UI.

​

Layer 3 — Output scrubber

​

Layer 4 — Keeper policy layer

• Allow — the call proceeds (default for everything not matched).
• Deny — the call is blocked, the agent receives a structured error, the decision is journalled.
• Require approval — the call pauses, a waitpoint lands in the operator’s Inbox, and the agent resumes (or is denied) on the operator’s choice.
• Escalate — the call routes to a second-opinion agent (“gatekeeper LLM”) for a softer decision, with the final answer captured in the journal.

​

Layer 5 — Memory prompt-injection scanner

​

Flow

• The scanner runs in three stages from cheapest (unicode codepoint scan) to most expensive (base64 decode + re-scan). Most content fails fast at step 1 or 2; the base64 path only fires on content that LOOKS like it might be hiding an encoded payload.
• The homoglyph fold (Cyrillic ј → Latin j, etc.) is folded into the regex pass — it’s not a separate step. Pure-ASCII content skips the NFKD normalisation entirely so the operator-typed CREW.md doesn’t pay the homoglyph tax.
• Quarantine write failures fail closed: the model gets an IsError=true tool result rather than the poisoned content. A half-working scanner is worse than no scanner if it leaks on the failure path.
• Idempotency: same content → same SHA → same .quarantine/{sha}.md filename, overwritten in place. Reading a poisoned file twice doesn’t accumulate duplicate quarantine copies.

​

Rule families (current — PR-F4 v2)

​

What the scanner does NOT catch (yet)

• Cross-language homoglyph beyond Cyrillic/Greek — Hebrew, Armenian, Mathematical Alphanumeric Symbols block. Low priority because the existing rules target English-language injection patterns and the homoglyph fold table only needs to cover what attackers can substitute for ASCII letters in the existing rule set. Extensions are additive.
• Multi-step prompt injection — content that’s benign on its own but builds an instruction when combined with the next read. Out of scope; the scanner is single-pass per file.
• Adversarial LLM output mimicking benign content — content that says “PROCEED” to a downstream agent’s heuristic check. That’s a Layer 4 (Keeper) defence, not Layer 5.
• Content the agent SELF-AUTHORED that’s later read by another agent — peer cards are a real attack surface here. The peer-card writer caps content to 1500 B + the GDPR cascade can purge cards, but a malicious agent writing instructions into a peer card today bypasses the inbound-only scan because peer cards are written authoritatively. Tracked as PR-F follow-up: extend ScanContent to peer-card WRITE path.
• Inbound content above the per-tier byte cap — caps are 4000 / 4000 / 1500 / 8000 / 30000 / 1500 / no-cap (lessons) bytes per tier. The scanner runs on whatever fits within the cap; content truncated by cap before reaching the scanner is benignly cut off.

​

Quarantine response — what an operator sees

[BLOCKED: "prompt_injection" pattern "ignore_previous_instructions"
detected in "daily/2026-05-21.md". Original content quarantined to
.quarantine/a3f8e2c1...md for operator review. This placeholder
is a safe substitute; the poisoned content was never returned to you.]

1. .quarantine/{sha256}.md lands on disk inside the agent’s container — content + YAML frontmatter (category / pattern / source path / SHA) so triage tooling can route without re-running the scan
2. A journal entry fires (entry_type = memory.scan.hit) with the same triple
3. The agent’s next tool result includes the placeholder so the model can see SOMETHING happened (it can ask the operator about it instead of looping on “why is this file empty”)

​

Fail-closed posture

​

What this composition does and does not protect against

​

Beta posture and known gaps

• Egress is HTTP_PROXY-style, not network-enforced. Agents that bypass HTTP_PROXY or open raw sockets exit the allowlist unchecked. Operators who need hard egress control must layer Docker network policies (--internal, custom networks, egress firewall) on top.
• NET_RAW is added back so the agent can ping. Acceptable for the convenience trade-off, but operators with stricter requirements can drop it in their crew security profile.
• Privileged crews bypass most of Layer 1. Anything flagged Privileged: true is outside this threat model.
• Container-runtime isolation is the host’s responsibility. The default Docker config is not rootless, and Apple Containers / Colima have different threat profiles than upstream Docker.
• Keeper rulesets ship empty. Operators write the rules that matter for their environment; there is no “secure by default” policy yet.

​

Tenant isolation on internal-auth handlers

• Workspace-bound tokens (wsv1.<workspace_id>.<HMAC-SHA256(master, derivation_context || workspace_id)>, derived by internaltoken.DeriveWorkspaceToken) are what sidecars receive at startup via their stdin IPCConfig. The MAC is keyed by the master secret and computed over a fixed versioned domain-separation context concatenated with the workspace ID (not the workspace ID alone). The middleware re-derives the MAC from the embedded workspace ID and the in-memory master secret, so a token captured inside a container only ever authorizes the workspace it was issued for. Derivation is stateless; tokens roll with the master on every boot. The binding is enforced as a mandatory request scope, not as an optional ?workspace_id check (that earlier shape left a hole: a bound token that simply omitted the query fell through to unscoped reach). requireInternal now, for a bound token:
  • rejects (403) a supplied ?workspace_id that disagrees with the binding; and
  • injects the bound workspace into ?workspace_id when the caller omits it. Every handler that filters by ?workspace_id (webhook secret, list credentials, agent/chat resolve, crew/agent create, …) is therefore tenant-scoped automatically — there is no “legacy unscoped” fall-through for bound tokens. Path-param mutations that do not read the query (chat message-count / title, run finalize, credential status) additionally constrain their WHERE clause by the bound workspace from context (foreign rows → 404, never mutated). Handlers scoped by a workspace_id carried only in the JSON body (issue/mission/assignment/query/escalation create, confidence report, cost record, journal emit, pipeline save) enforce the same binding in-handler via assertInternalTokenWorkspace (403 on a foreign tenant), since the auth middleware cannot inspect bodies.
• The master token (CREWSHIP_INTERNAL_TOKEN) never enters a container. It remains valid for host-side trusted callers (the chat bridge resolver, the webhook secret resolver, and the LLM proxy cost monitor) that dial the internal API in-process over loopback (127.0.0.1 / ::1). Because the master’s bound scope is empty it authorizes every workspace, so a copy leaked into a crew container would otherwise retain full cross-tenant power. To cap that blast radius, requireInternal pins the master to a loopback origin: a master token arriving from a Docker-bridge / LAN IP (the only place a container-side leak could be replayed from) is refused with 403. Sidecars reach the API from a bridge IP and always carry a bound token, so they are unaffected. Operators who front crewshipd with a reverse proxy that rewrites RemoteAddr opt back into token-only with CREWSHIP_INTERNAL_ALLOW_ANY=true (the same kill-switch that relaxes the network gate), accepting that the token is then the sole guard.

​

Resolved exception — Keeper Phase 2 family

• Asymmetric forgery (caller passes workspace A in query, claims workspace B in body) is rejected by the assertBodyWorkspaceMatchesCtx helper in internal/api/keeper_phase2.go, which compares both values and returns 400 on mismatch.
• Symmetric forgery (caller picks one foreign workspace consistently across both query and body) is closed by PR-F24: the X-Internal-Token a sidecar holds is bound to its workspace at issue time, and both internalAuth and internalWsCtx validate that binding against ?workspace_id (403 on mismatch).

• The binding derives its trust from the sidecar process boundary (UID 1002 vs. agent UID 1001). An attacker who fully compromises the sidecar process itself still acts with that one workspace’s authority — the intended blast-radius cap.
• The master-token loopback pin assumes host-side trusted callers reach the internal API over loopback, which holds for the in-process callers in this codebase (internal/chatbridge/resolver.go dials WithInternalLoopbackURL = 127.0.0.1:<port>; the LLM-proxy TokenSyncer / CredentialMonitor dial cfg.Auth.NextjsURL, which defaults to http://localhost:<port>). If an operator overrides CREWSHIP_NEXTJS_URL to a non-loopback host so the proxy dials the API across a network hop, those master-token calls will be refused unless CREWSHIP_INTERNAL_ALLOW_ANY=true is also set — a deliberate fail-closed posture, documented here rather than silently relaxed.

​

Hardening surface — what’s locked vs. what’s tracked

​

Reporting issues

​

Related

• Container isolation
• Encryption
• RBAC
• Audit logging
• Credentials guide
• Keeper guide
• Telemetry — what crash-reporting does and does not send.