mara/hyperhive
mara/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

fixup! docs: the trust-boundary pages keep the operator guidance, the mechanism moves to implementation

Browse source
This commit is contained in:
iris 2026-11-06 19:12:16 +01:00 • committed by mara
commit 514a7c1580
1 changed files with 3 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/2-handbook/trust-boundary/security.md
View file

@ -2,8 +2,8 @@
## Agent trust model
The sections below document specific mechanisms (nixbld isolation,
privilege separation). This section frames the model they
The implementation docs document the specific mechanisms (nixbld isolation,
privilege separation; see the list at the end). This section frames the model they
serve: **what hyperhive defends, what it deliberately doesn't, and where the
operator is accepting risk.** It's the reference for "is it safe to give an
agent capability X?."
@ -20,7 +20,7 @@ default**. Isolating credentials _from the agent itself_ is therefore **not a
goal**: an agent can read its own tokens, its own `/home/<name>/.claude`, and
run arbitrary commands as root inside its container. (The narrow exception is
_cross-tenant_ leakage — for example the unsandboxed-nix-build `0600` token policy
below stops a build's nixbld user reading the agent's own forge token. That hardens
(see [nix builds](../../4-implementation/trust-boundary/nix-builds.md)) stops a build's nixbld user reading the agent's own forge token. That hardens
the boundary; it doesn't sandbox the agent from itself.)
<!-- vale write-good.Passive = YES -->