From 3a50f57b66363e256bc607d96da0417fc9e244ca Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN <53631862+PR0M3TH3AN@users.noreply.github.com> Date: Fri, 14 Aug 2026 23:59:11 -0400 Subject: [PATCH] docs: correct the capability location in the security model It moved out of the app directory in the previous commit; the principals table still described the old location. Co-Authored-By: Claude Fable 5 --- docs/agent_security_model.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/agent_security_model.md b/docs/agent_security_model.md index f3b04822..6baf0569 100644 --- a/docs/agent_security_model.md +++ b/docs/agent_security_model.md @@ -18,7 +18,7 @@ one machine. | Principal | Proves itself with | Gets | |---|---|---| -| Owner | The capability secret in a `0600` file beside the socket | Everything: unlock/lock, the parent seed, token issuance, status, shutdown | +| Owner | The capability secret in a `0600` file under `XDG_RUNTIME_DIR` (deliberately not in the app directory) | Everything: unlock/lock, the parent seed, token issuance, status, shutdown | | Token holder | A bearer token issued by the owner | Only what the token's scopes and constraints allow, enforced by the daemon | | Anyone else | Nothing | Nothing but a liveness ping | @@ -35,6 +35,11 @@ That does not distinguish the owner's CLI from a scoped agent that was handed a token — both run as you. The capability file raises the bar to "can read the owner's files", which is the same bar as the vault itself. +It is stored outside the app directory on purpose. A scoped agent has to be +given that directory to find the socket and the profile registry, so a +capability kept there would ship the escape hatch with the keys — a reviewer +demonstrated exactly that escalation. + **It does not defend against a same-uid attacker.** Anyone who can read that file, read the vault, or `ptrace` the daemon has already won. Defending against that needs an OS-level boundary (a separate user, a container, a