diff --git a/docs/ci.md b/docs/ci.md
index 9b43f675..4b306deb 100644
--- a/docs/ci.md
+++ b/docs/ci.md
@@ -53,34 +53,6 @@ jobs:
 
 This runs on every PR, executing all flake checks (treefmt, rustfmt, cargo test, cargo clippy, module evaluation). No `--no-build`: the checks' derivations are the canonical source of truth.
 
-## Security: unsandboxed builds and trusted contributors
-
-**hive-ci should only run CI for trusted contributors.** The security boundary is weaker than it looks:
-
-### What unsandboxed builds mean
-
-nspawn containers cannot create user-namespaces, so `nix.settings.sandbox-fallback = true` is set in the container. This means every `nix build` (and `nix flake check`) runs **without a build sandbox** — the build process has full access to the container filesystem, network, and any bind-mounts during the build phase.
-
-A malicious `default.nix` or build script in a PR can therefore:
-
-- **Read the core admin token** at `/run/hive-ci/core-token` (bind-mounted into the container for runner auto-registration). This token has `read:admin + write:admin` scopes on hive-forge — enough to read any repo, enumerate users, and issue forge admin API calls.
-- **Make arbitrary network requests** to any address reachable from the container. The container shares host netns, so `http://127.0.0.1:<forgePort>` is reachable.
-- **Write to the container filesystem**, including corrupting the runner's state dir or `.runner` credentials.
-
-Note: `nix flake check --no-build` (eval-only) reduces the attack surface but does not eliminate it — `builtins.fetchGit`, `builtins.fetchurl`, and import-from-derivation can reach the network and filesystem during evaluation. The default CI workflow runs full `nix flake check` (builds derivations), which is the higher-risk path.
-
-### Mitigation
-
-For a hive used by a single operator or a small trusted team, the risk is low — all contributors are already trusted with forge access anyway.
-
-For repos with external contributors or fork PRs:
-
-- Use Forgejo's **fork PR approval workflow** (`repository.settings` → "Require approval for fork PRs from first-time contributors") to gate CI until a maintainer approves the first PR.
-- Or restrict the CI workflow trigger to push events on branches (not `pull_request` from forks) — forks can't push to upstream branches.
-- As a structural fix, move `core-token` out of the container bind-mount tree and use a scoped registration-only token. That work is tracked separately.
-
-The current design is appropriate for a trusted-team hive where all contributors have implicit forge access.
-
 ## References
 
 - `nix/modules/hive-ci.nix`: runner configuration, auto-registration script, container setup.