Skip to content

docs: keep the Bitwarden account that can read the secrets off agent machines - #86

Merged
groupsky merged 1 commit into
mainfrom
docs/82-bitwarden-account
Oct 16, 2026
Merged

groupsky merged 1 commit into
mainfrom
docs/82-bitwarden-account

Conversation

@groupsky

Copy link
Copy Markdown
Contributor

Closes #82.

Why

T7 says: never log in to the approver's Telegram account on an agent machine. The docs had no such rule for the Bitwarden side. Whoever is logged in to a Bitwarden account that can read the store's secrets can read them in Bitwarden's own apps, with no tap and no entry in nodkey's audit log. A common setup keeps the main Bitwarden account open on the computer where the agent works.

What changes

  • THREAT-MODEL.md: a new threat, T32, in the same form as T7. It lists who can read the secrets (checked against Bitwarden's help pages and, for the member who made a project, Bitwarden's server code; seen 2026-10-16), what to do, and the risk that remains. The trust table (section 3), the known limits (section 5, item 9) and the assumptions (section 7) name the rule.
  • docs/setup.md:
    • Section 1 adds the rule next to the Telegram rule, and says not to save these passwords in a password manager that is open on an agent machine.
    • Section 5 adds it for bws (with the Free Secrets Manager plan, as Bitwarden's plan page shows it) and for bw (no emergency access).
    • Section 9 gets a new subsection, "The Bitwarden accounts that can read the secrets".
  • README.md: step 2 and "Before real use" name the rule.
  • DESIGN.md section 11: one sentence, so that "bws does not have these problems" does not read as if no person can read the secrets.

Review

A security review subagent checked it in three rounds. All Bitwarden quotes match the pages; all links and anchors resolve. The Go tests that read DESIGN.md pass (they check sections 5, 7, 13 and 14; this changes section 11). Docs only; no code changes.

…machines

T7 says: never log in to the approver's Telegram account on an agent
machine. The docs had no such rule for Bitwarden. Whoever is logged in
to an account that can read the store's secrets can read them in
Bitwarden's own apps, with no tap and no entry in nodkey's audit log.

The new threat T32 lists who can read the secrets, by Bitwarden's
documentation and source code: owners and admins of the organization,
the member who made the project, members with access to the project or
to one secret, members of a machine account that can read them, and for
bw the separate account and its emergency access contacts. It says what
to do: use an account that is never logged in on an agent machine, do
not save its master password or two-step key in a password manager
that is open there, use two-step login with an app or a security key,
and check the members after each change.

The trust table, the known limits (section 5), the assumptions
(section 7), setup.md sections 1, 5 and 9, the README and DESIGN.md
section 11 point to the rule. setup.md section 5 also notes the Free
Secrets Manager plan (seen 2026-10-16).

Closes #82
@groupsky
groupsky merged commit 24297af into main Oct 16, 2026
7 checks passed
@groupsky
groupsky deleted the docs/82-bitwarden-account branch October 16, 2026 13:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs: keep the Bitwarden account that can read the secrets off agent machines

1 participant