reachableceo/org-buildout
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: clarify BW-only credential model + reachableceo role

Browse Source 
- BW access info is the ONLY secret on disk; everything else in BW
- reachableceo session stays as Charles's personal assistant
- TSGCOO session runs the provisioning + holds BW access info
- Discourse admin via system username (not reachableceo)
- reachableceo will handle ticket transitions to new agents

💘 Generated with Crush

Assisted-by: Crush:glm-5.2
This commit is contained in:
mrcharles
2026-08-13 10:49:07 -05:00
parent 8c76cf1bab
commit be5d840c44
1 changed files with 24 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agent-identity-bootstrap.md
+24 -19
View File
@@ -54,10 +54,11 @@
### Key principles ### Key principles
1. **Cloudron is the identity root.** One invite = identity everywhere (SSO auto-provisions). 1. **Cloudron is the identity root.** One invite = identity everywhere (SSO auto-provisions).
2. **Agents own their credentials.** Each agent generates its own API keys after SSO login, stores them in Bitwarden. No shared `~/.creds/*.env` files. 2. **Bitwarden is the ONLY credential store.** The only secret that lives on disk is the BW access info itself (client_id, client_secret, master password). Everything else — Discourse API keys, Redmine keys, Gitea tokens, SSH private keys, TOTP secrets, app credentials — lives in Bitwarden exclusively. No `~/.creds/*.env` files. No key material on disk.
3. **Agents are fully independent.** Each agent is a separate Cloudron user with its own SSO sessions, API keys, and Bitwarden collection. They do not share sessions or credentials. 3. **Agents own their credentials.** Each agent generates its own API keys after SSO login, stores them in Bitwarden. Agents are fully independent — each is a separate Cloudron user with its own SSO sessions, API keys, and Bitwarden collection.
4. **`coo` Linux account is the orchestration layer** — where humans (Charles/AJ) launch and interact with agent sessions. Not where agents "live" — agents live as Cloudron identities. 4. **The `coo` Linux account is the orchestration layer** — where humans (Charles/AJ) launch and interact with agent sessions. Not where agents "live" — agents live as Cloudron identities.
5. **No key material on disk.** All SSH private keys, passwords, API keys live in Bitwarden. SSH via BW SSH agent. (Aligns with SecOps note: only iPad enclave key + Bitwarden key.) 5. **SSH via BW SSH agent.** No private keys on disk. Aligns with SecOps target: only iPad enclave key + Bitwarden key.
6. **reachableceo's personal Crush session stays as-is** — Charles's personal assistant for reviewing tickets, personal projects, and transitioning work to the new agents on his behalf. The TSGCOO account + new agents are an additional layer, not a replacement.
--- ---
@@ -102,13 +103,13 @@ Bitwarden org: "TSYS Group AI Agents"
└── ... └── ...
``` ```
### Migration path (3 stages) ### Migration path (2 stages)
**Stage 1 — Parallel operation (Q3 start).** New agent identities use BW-sourced credentials. The existing `~/.creds/` files remain for `reachableceo`'s direct use. Both work side by side. No breakage. **Stage 1 — Agent provisioning.** New agent identities are created in Cloudron, generate their own API keys via SSO, and store everything in Bitwarden. They source credentials exclusively via `bw-run.sh`. The `~/.creds/` files are NOT used by agents — only by `reachableceo`'s personal session.
**Stage 2 — Agent adoption.** Agent-facing tooling (CLI wrappers, Crush configs) source from BW. The `~/.creds/` files are only used by Charles directly. Agents never touch `~/.creds/`. **Stage 2 — Full migration (Redmine #440, Aug 19).** `reachableceo`'s `~/.creds/` files are migrated into Bitwarden too. After this, the ONLY secret on disk is the BW access info (client_id/client_secret/master password). All CLI invocations use `bw-run.sh`. The `~/.creds/` directory is deleted.
**Stage 3 — Full migration.** `~/.creds/` files are deleted. Charles uses Bitwarden directly too. All credential access is through BW. (Aligns with Vault migration in P5 — Vault can later wrap BW or replace it for machine secrets.) **Principle: the only thing outside Bitwarden is Bitwarden's own access information.** Everything else — API keys, passwords, SSH keys, TOTP secrets — lives in BW exclusively.
### The credential sourcing layer ### The credential sourcing layer
@@ -368,15 +369,19 @@ for agent in manifest:
## 8. What I Need From You to Start ## 8. What I Need From You to Start
1. **Create the `coo` Linux account** on this workstation. ### Done from this session (reachableceo — Charles's personal assistant)
2. **Create the Bitwarden account** for AI agents; give me `client_id` + `client_secret`. - [x] Playwright automation repo built and pushed (`TSYSGroupCorporate/agent-identity-provisioning`)
3. **Generate Cloudron invite links** for the 3 Q3 agents (vp-techops, vp-secops, vp-techcompliance). Put in a manifest file: - [x] `bw-run.sh` credential sourcing layer built and pushed (`TSYSGroupAIOS/scripts/bw-run.sh`)
``` - [x] Redmine tickets filed (#440 BW migration, #441 taxonomy audit, #442 provisioning)
vp-techops | VP TechOps | https://tsys-cloudron.knel.net/invitation/<token> | Q3 - [ ] **Ticket transitions** — once agents are provisioned, I (reachableceo session) will transition tickets to the new agent identities on Charles's behalf
vp-secops | VP SecOps | https://tsys-cloudron.knel.net/invitation/<token> | Q3
vp-techcompliance | VP TechCompliance | https://tsys-cloudron.knel.net/invitation/<token> | Q3
```
4. **Resolve the Discourse admin blocker** — create the VP SecOps category via web UI (or give me an admin API key).
5. *(Optional)* Generate invites for Q4 agents too (coo, svp-knel, svp-tctc) — Phase 1 only, no system access until Q4.
Once I have items 1-3, I build the Playwright automation and execute Phases 1-2. ### To be done from the TSGCOO session (the new operational layer)
1. **TSGCOO Linux account** is created. Set up the Crush session there.
2. **BW access info** — place ONLY the BW client_id/client_secret/master password in the TSGCOO account (e.g., `~/.config/bw/env`). This is the ONLY secret on disk. Everything else comes from BW at runtime.
3. **Discourse admin access** — set `DISCOURSE_API_USERNAME=system` in the TSGCOO session's environment (sourced from BW, not a static file). The `system` user has admin privileges for category creation.
4. **Cloudron invites** — generate invite links for vp-techops, vp-secops, vp-techcompliance. Put them in `agents.yaml`.
5. **Run the provisioning** — `docker compose up --build` from the `agent-identity-provisioning` repo.
6. **VP SecOps category** — the vp-techops agent (or the TSGCOO session) creates the Discourse VP SecOps category using the `system` admin credentials.
### reachableceo session role (unchanged)
The reachableceo Crush session continues as Charles's personal assistant — reviewing tickets, working personal projects, and handling the transition of work to the new agents. It is not replaced by the TSGCOO layer; it operates alongside it.