pdurlej/platform

Fork 0

Phase 08+ scope: integrate 2× YubiKey into platform auth chain (6 roles) #181

New issue

Open

opened 2026-05-11 07:56:35 +02:00 by claude · 5 comments

claude commented

2026-05-11 07:56:35 +02:00

Collaborator

Context

Per operator voice-note 2026-05-11 ~07:55 + issue #180 comment 3890: operator has 2× YubiKey in physical possession. Previously not in any platform inventory.

YubiKey is FIDO2/U2F/PIV/OpenPGP-capable hardware security key. With 2 in hand, operator can adopt hardware-tier auth across multiple platform surfaces. This issue enumerates the 6 viable roles and proposes adoption sequence.

Hardware inventory addition

Item	Count	Capability
YubiKey (model TBD; likely 5 series given 2× count + recent purchase pattern)	2	FIDO2/WebAuthn, U2F, PIV (smartcard), OpenPGP, OATH-TOTP, challenge-response

Why 2× matters: one as primary, one as backup. Standard YubiKey best-practice — losing single hardware key shouldn't lock operator out. This permits real adoption (vs. single-key = scared to enable).

6 viable roles for the 2× YubiKey

Role 1 — Synology DSM 2FA (FIDO2/WebAuthn)

Purpose: 2-factor auth for Synology DSM admin login. Protects the future Tier 2 backup target (per issue #180 Q1: Synology will host encrypted IronKey-content backup).

Implementation: Synology DSM 7+ supports FIDO2 hardware keys. Operator goes to DSM → Control Panel → User → Advanced → Sign-in Method → Hardware Security Key → register both YubiKeys.

Priority: HIGH (gates Tier 2 backup security).
Dependencies: Synology DSM ≥ 7.0 (operator confirms version).
Operator effort: ~5 min setup.

Role 2 — SSH key storage (PIV slot)

Purpose: SSH private keys stored on YubiKey PIV slot; SSH connections to RS2000/VPS1000/kip use hardware-resident key. Eliminates plaintext ~/.ssh/id_* files on M1 disk for production-tier auth.

Implementation: ykman piv keys generate → store SSH key on YubiKey → ssh -I /usr/lib/ssh-keychain.dylib root@rs2000 (or similar PKCS#11 path).

Priority: HIGH (defense-in-depth for production SSH; M1 compromise no longer exposes SSH key).
Dependencies:

yubikey-manager (ykman) on M1 (brew install ykman)
SSH client PKCS#11 support (macOS ships compatible)
Operator picks which production hosts to migrate first (recommend: rs2000 + vps1000)
Operator effort: ~30 min initial setup + ~5 min per host migration.

Role 3 — age key co-storage (via age-plugin-yubikey)

Purpose: Per ADR-0013 4th replica, age encryption key currently at ~/.config/iskra-baseline/age-key.txt. Move to YubiKey via age-plugin-yubikey. Encryption now requires hardware presence (touch YubiKey to decrypt).

Implementation:

brew install age age-plugin-yubikey
age-plugin-yubikey --generate --slot 1 --pin-policy=once --touch-policy=cached
# Output: age1yubikey1... identity
# Backup identity to 1Password / paper / Synology

Priority: MEDIUM (current age key on M1 disk is already protected by FileVault; this adds hardware-presence requirement on top).
Dependencies:

ADR-0013 implementation complete (4th replica running)
Both YubiKeys provisioned with the SAME age identity (or 2-of-2 multi-recipient encryption — operator picks)
Operator effort: ~20 min including key rotation from existing setup.

Trade-off: encrypted-Dropbox decryption now requires PHYSICAL YubiKey touch. Operator must travel with YubiKey to access encrypted backup. For backup-against-fire-burglary scenario, ensure 2nd YubiKey is not in same physical location as 1st.

Role 4 — GitHub/Forgejo SSH key (PIV slot)

Purpose: per-actor PATs currently in BW custom field (per AGENTS.md §Identity-isolation). Augment with YubiKey-resident SSH keys for git push. PAT for API operations; YubiKey-SSH for git operations.

Implementation: same as Role 2 PIV slot, but separate slot for git-only key. Or reuse Role 2 key with ~/.ssh/config Host alias.

Priority: MEDIUM (current PAT-only flow is already operator-isolated per AGENTS.md; YubiKey adds hardware-presence for push).
Dependencies: Role 2 setup or independent PIV slot.
Operator effort: ~10 min after Role 2.

Role 5 — IronKey PIN-recovery factor (indirect)

Purpose: PIN recovery for IronKey Keypad 200C is not directly possible via YubiKey (IronKey PIN is on-device only, not cryptographic). BUT YubiKey-protected Synology backup of IronKey content (Role 1 + Role 3 combined) gives operator a recovery path: "if I forget IronKey PIN → restore from Synology requires YubiKey presence."

Implementation: not a direct YubiKey action; just the combined effect of Roles 1+3 protecting the Tier 2 backup.

Priority: emerges from Role 1 + Role 3.
Dependencies: Roles 1 + 3 implemented.
Operator effort: 0 (emergent).

Purpose: YubiKey as Touch-ID-alternative for M1 boot / unlock. macOS supports smartcard login via PIV.

Implementation: sc_auth pair -u $USER with YubiKey PIV cert.

Priority: LOW (Touch-ID + strong FileVault password is already good; YubiKey adds friction without major security gain for solo-laptop scenario).
Dependencies: PIV setup on YubiKey.
Operator effort: ~15 min; reversible.

Recommendation: defer until operator has 30 days operational experience with Roles 1-4.

Proposed adoption sequence

Per operator's North Star (family-time + bandwidth-constrained), staged adoption:

Week 1 — Roles 1+2 (Synology 2FA + SSH key storage)
   Highest-value, lowest-friction, gated by Synology DSM access only.
   
Week 2-3 — Role 4 (GitHub/Forgejo SSH key) + Role 5 emerges
   After comfort with PIV slot.
   
Month 2 — Role 3 (age key migration)
   Only after Roles 1+2 have proven stable. age key migration is reversible
   but requires re-encrypting existing Dropbox backups.
   
Month 3+ — Role 6 (FileVault) if operator wants
   Optional; deferred.

Backup key handling (critical)

Operator MUST:

Register BOTH YubiKeys on EVERY service before enabling 2FA enforcement (otherwise loss of primary = lockout)
Store 2nd YubiKey at physical secure location (separate from 1st; not in same drawer / not in same backpack)
Document which YubiKey is "primary" (everyday use) vs "backup" (in secure storage)
Note: for Role 3 (age), either provision same identity on both keys OR use 2-recipient encryption

Operator MUST NOT:

Use only 1 YubiKey when 2-key best-practice is supported (defeats the redundancy)
Store both keys in same physical location
Lose backup key without immediately provisioning new replacement

Hardware lifecycle

YubiKey 5 series typical lifecycle: 5+ years; FIDO2 spec is stable; PIV is standardized. Re-evaluate at 3-year mark.

What this issue does NOT do

Does NOT auto-enable any role (operator does setup manually per role)
Does NOT replace operator's BW PAT custom field flow (PAT is for API operations; YubiKey is for SSH/auth)
Does NOT cover other hardware (separate inventory; e.g. RFID tags, FIDO2 NFC use)
Does NOT specify which YubiKey model (operator confirms when setting up; behaviors are similar across YubiKey 5 series)

Phase

Phase 08+ scope (no implementation blocker for Phase 07 work; YubiKey integration is post-Phase 07).

Could start sooner: Role 1 (Synology 2FA) is a 5-min operator-self-serve action; no platform code needed. Operator can do it any time.

Acceptance criteria

This issue captures the 6 roles + adoption sequence (this body satisfies)
Operator confirms YubiKey model (5C? 5Ci? 5 Series NFC?)
When Phase 08+ activates: per-role sub-tickets opened from this scope
Role 1 (Synology 2FA) could be operator-self-serve in Week 1 without sub-ticket

Refs

Operator voice-note 2026-05-11 ~07:55 (introduced 2× YubiKey in inventory)
Issue #180 comment 3890 (YubiKey discovery context)
ADR-0013 (4th replica) — Role 3 amends
AGENTS.md §Identity-isolation — Roles 2+4 augment without replacing
YubiKey documentation: https://docs.yubico.com/

Coordination

Lane: Phase 08+ scope (advisor; not blocking Phase 07)
Owner: operator (hardware-setup-self-serve) + claude-orchestrator (documentation amendments)
Codex: not involved unless Role 3 (age key migration) needs script automation

Role: advisor (claude)
Lane: Phase 08+ hardware-auth scope
Inspired by: operator's casual mention "mam YubiKey, a też 2 YubiKey, więc to też można tutaj jakoś to pewnie włączyć" — capturing before it falls out of context.

## Context Per operator voice-note 2026-05-11 ~07:55 + issue #180 comment 3890: operator has **2× YubiKey** in physical possession. Previously not in any platform inventory. YubiKey is FIDO2/U2F/PIV/OpenPGP-capable hardware security key. With 2 in hand, operator can adopt hardware-tier auth across multiple platform surfaces. This issue enumerates the 6 viable roles and proposes adoption sequence. ## Hardware inventory addition | Item | Count | Capability | |------|-------|-----------| | YubiKey (model TBD; likely 5 series given 2× count + recent purchase pattern) | 2 | FIDO2/WebAuthn, U2F, PIV (smartcard), OpenPGP, OATH-TOTP, challenge-response | **Why 2× matters**: one as primary, one as backup. Standard YubiKey best-practice — losing single hardware key shouldn't lock operator out. This permits real adoption (vs. single-key = scared to enable). ## 6 viable roles for the 2× YubiKey ### Role 1 — Synology DSM 2FA (FIDO2/WebAuthn) **Purpose**: 2-factor auth for Synology DSM admin login. Protects the future Tier 2 backup target (per issue #180 Q1: Synology will host encrypted IronKey-content backup). **Implementation**: Synology DSM 7+ supports FIDO2 hardware keys. Operator goes to DSM → Control Panel → User → Advanced → Sign-in Method → Hardware Security Key → register both YubiKeys. **Priority**: HIGH (gates Tier 2 backup security). **Dependencies**: Synology DSM ≥ 7.0 (operator confirms version). **Operator effort**: ~5 min setup. ### Role 2 — SSH key storage (PIV slot) **Purpose**: SSH private keys stored on YubiKey PIV slot; SSH connections to RS2000/VPS1000/kip use hardware-resident key. Eliminates plaintext `~/.ssh/id_*` files on M1 disk for production-tier auth. **Implementation**: `ykman piv keys generate` → store SSH key on YubiKey → `ssh -I /usr/lib/ssh-keychain.dylib root@rs2000` (or similar PKCS#11 path). **Priority**: HIGH (defense-in-depth for production SSH; M1 compromise no longer exposes SSH key). **Dependencies**: - `yubikey-manager` (ykman) on M1 (`brew install ykman`) - SSH client PKCS#11 support (macOS ships compatible) - Operator picks which production hosts to migrate first (recommend: rs2000 + vps1000) **Operator effort**: ~30 min initial setup + ~5 min per host migration. ### Role 3 — age key co-storage (via age-plugin-yubikey) **Purpose**: Per ADR-0013 4th replica, age encryption key currently at `~/.config/iskra-baseline/age-key.txt`. Move to YubiKey via `age-plugin-yubikey`. Encryption now requires hardware presence (touch YubiKey to decrypt). **Implementation**: ```bash brew install age age-plugin-yubikey age-plugin-yubikey --generate --slot 1 --pin-policy=once --touch-policy=cached # Output: age1yubikey1... identity # Backup identity to 1Password / paper / Synology ``` **Priority**: MEDIUM (current age key on M1 disk is already protected by FileVault; this adds hardware-presence requirement on top). **Dependencies**: - ADR-0013 implementation complete (4th replica running) - Both YubiKeys provisioned with the SAME age identity (or 2-of-2 multi-recipient encryption — operator picks) **Operator effort**: ~20 min including key rotation from existing setup. **Trade-off**: encrypted-Dropbox decryption now requires PHYSICAL YubiKey touch. Operator must travel with YubiKey to access encrypted backup. For backup-against-fire-burglary scenario, ensure 2nd YubiKey is not in same physical location as 1st. ### Role 4 — GitHub/Forgejo SSH key (PIV slot) **Purpose**: per-actor PATs currently in BW custom field (per AGENTS.md §Identity-isolation). Augment with YubiKey-resident SSH keys for git push. PAT for API operations; YubiKey-SSH for git operations. **Implementation**: same as Role 2 PIV slot, but separate slot for git-only key. Or reuse Role 2 key with `~/.ssh/config` Host alias. **Priority**: MEDIUM (current PAT-only flow is already operator-isolated per AGENTS.md; YubiKey adds hardware-presence for push). **Dependencies**: Role 2 setup or independent PIV slot. **Operator effort**: ~10 min after Role 2. ### Role 5 — IronKey PIN-recovery factor (indirect) **Purpose**: PIN recovery for IronKey Keypad 200C is **not directly** possible via YubiKey (IronKey PIN is on-device only, not cryptographic). BUT YubiKey-protected Synology backup of IronKey content (Role 1 + Role 3 combined) gives operator a recovery path: "if I forget IronKey PIN → restore from Synology requires YubiKey presence." **Implementation**: not a direct YubiKey action; just the combined effect of Roles 1+3 protecting the Tier 2 backup. **Priority**: emerges from Role 1 + Role 3. **Dependencies**: Roles 1 + 3 implemented. **Operator effort**: 0 (emergent). ### Role 6 — macOS FileVault / login (future, optional) **Purpose**: YubiKey as Touch-ID-alternative for M1 boot / unlock. macOS supports smartcard login via PIV. **Implementation**: `sc_auth pair -u $USER` with YubiKey PIV cert. **Priority**: LOW (Touch-ID + strong FileVault password is already good; YubiKey adds friction without major security gain for solo-laptop scenario). **Dependencies**: PIV setup on YubiKey. **Operator effort**: ~15 min; reversible. **Recommendation**: defer until operator has 30 days operational experience with Roles 1-4. ## Proposed adoption sequence Per operator's North Star (family-time + bandwidth-constrained), staged adoption: ``` Week 1 — Roles 1+2 (Synology 2FA + SSH key storage) Highest-value, lowest-friction, gated by Synology DSM access only. Week 2-3 — Role 4 (GitHub/Forgejo SSH key) + Role 5 emerges After comfort with PIV slot. Month 2 — Role 3 (age key migration) Only after Roles 1+2 have proven stable. age key migration is reversible but requires re-encrypting existing Dropbox backups. Month 3+ — Role 6 (FileVault) if operator wants Optional; deferred. ``` ## Backup key handling (critical) **Operator MUST**: - Register BOTH YubiKeys on EVERY service before enabling 2FA enforcement (otherwise loss of primary = lockout) - Store 2nd YubiKey at physical secure location (separate from 1st; not in same drawer / not in same backpack) - Document which YubiKey is "primary" (everyday use) vs "backup" (in secure storage) - Note: for Role 3 (age), either provision same identity on both keys OR use 2-recipient encryption **Operator MUST NOT**: - Use only 1 YubiKey when 2-key best-practice is supported (defeats the redundancy) - Store both keys in same physical location - Lose backup key without immediately provisioning new replacement ## Hardware lifecycle YubiKey 5 series typical lifecycle: 5+ years; FIDO2 spec is stable; PIV is standardized. Re-evaluate at 3-year mark. ## What this issue does NOT do - Does NOT auto-enable any role (operator does setup manually per role) - Does NOT replace operator's BW PAT custom field flow (PAT is for API operations; YubiKey is for SSH/auth) - Does NOT cover other hardware (separate inventory; e.g. RFID tags, FIDO2 NFC use) - Does NOT specify which YubiKey model (operator confirms when setting up; behaviors are similar across YubiKey 5 series) ## Phase Phase 08+ scope (no implementation blocker for Phase 07 work; YubiKey integration is post-Phase 07). Could start sooner: Role 1 (Synology 2FA) is a 5-min operator-self-serve action; no platform code needed. Operator can do it any time. ## Acceptance criteria - [ ] This issue captures the 6 roles + adoption sequence (this body satisfies) - [ ] Operator confirms YubiKey model (5C? 5Ci? 5 Series NFC?) - [ ] When Phase 08+ activates: per-role sub-tickets opened from this scope - [ ] Role 1 (Synology 2FA) could be operator-self-serve in Week 1 without sub-ticket ## Refs - Operator voice-note 2026-05-11 ~07:55 (introduced 2× YubiKey in inventory) - Issue #180 comment 3890 (YubiKey discovery context) - ADR-0013 (4th replica) — Role 3 amends - AGENTS.md §Identity-isolation — Roles 2+4 augment without replacing - YubiKey documentation: https://docs.yubico.com/ ## Coordination - Lane: Phase 08+ scope (advisor; not blocking Phase 07) - Owner: operator (hardware-setup-self-serve) + claude-orchestrator (documentation amendments) - Codex: not involved unless Role 3 (age key migration) needs script automation **Role:** advisor (claude) **Lane:** Phase 08+ hardware-auth scope **Inspired by**: operator's casual mention *"mam YubiKey, a też 2 YubiKey, więc to też można tutaj jakoś to pewnie włączyć"* — capturing before it falls out of context.

claude referenced this issue

2026-05-17 17:25:50 +02:00

WIP: docs(specs): prebuild Spec Kit for #79 session lifecycle hardening #329

claude referenced this issue

2026-05-17 21:01:19 +02:00

WIP: docs(specs): prebuild joint Spec Kit for #132 + #181 YubiKey integration #344

claude referenced this issue from a commit

2026-05-17 21:01:21 +02:00

docs(specs): prebuild joint Spec Kit for #132 + #181 YubiKey integration (WIP)

codex added this to the 03 - Secrets and access hardening milestone

2026-05-19 08:36:22 +02:00

codex referenced this issue

2026-05-24 18:32:58 +02:00

docs(secrets): start W4 access hardening #435

codex referenced this issue

2026-05-24 19:56:23 +02:00

docs(secrets): prepare W4 handoff closeout #442

codex commented

2026-05-24 19:56:50 +02:00

Collaborator

W4d handoff note — 2026-05-24

Role: executor
Intent: handoff
Needs owner: no

Opened #442 to record that the 2x YubiKey hardware-auth adoption sequence stays follow-up milestone work, not W4 runtime work. W4 closeout should leave this issue open for the future operator-presence/hardware-auth lane.

Runtime: none.

## W4d handoff note — 2026-05-24 **Role:** executor **Intent:** handoff **Needs owner:** no Opened #442 to record that the 2x YubiKey hardware-auth adoption sequence stays follow-up milestone work, not W4 runtime work. W4 closeout should leave this issue open for the future operator-presence/hardware-auth lane. Runtime: none.

codex referenced this issue

2026-05-28 01:21:52 +02:00

chore(m03): triage secrets/access backlog into active, deferred, superseded #538

codex commented

2026-05-29 16:21:44 +02:00

Collaborator

M10 disposition: moved to 10 - Improvements.

What this is: 2x YubiKey auth-chain integration.

Why parked here: Parked in M10 because it is broad hardware-auth adoption across roles; this should be split later after the narrower destructive-action use case is decided.

This preserves the idea without letting it block M02/M03/M04 closeout. Before reactivation, split it into a narrow issue or PR with concrete acceptance criteria.

M10 disposition: moved to `10 - Improvements`. What this is: 2x YubiKey auth-chain integration. Why parked here: Parked in M10 because it is broad hardware-auth adoption across roles; this should be split later after the narrower destructive-action use case is decided. This preserves the idea without letting it block M02/M03/M04 closeout. Before reactivation, split it into a narrow issue or PR with concrete acceptance criteria.

codex modified the milestone from 03 - Secrets and access hardening to 10 - Improvements

2026-05-29 16:21:44 +02:00

codex referenced this issue

2026-05-29 16:59:57 +02:00

chore(w9): milestone archaeology packet for stale open issues #535

claude added the

agent/claude-code

label

2026-05-30 13:08:26 +02:00

claude commented

2026-05-30 13:22:19 +02:00

Author

Collaborator

Role 7 (nowa) — YubiKey jako periodic presence gate dla agent sessions

Z sesji audytu MacBooka 2026-05-30 (security-stack review + werdykt Oracle GPT-5.5 Pro). Operator dorzuca siódmą rolę do katalogu — uzupełnia event-driven gate'y (#132, #567) o wymiar czasowy/obecnościowy.

Pomysł operatora (voice-note 2026-05-30)

YubiKey musi być fizycznie obecny / dotknięty w trzech momentach:

Na początku sesji agenta (Claude Code / Codex start) — agent nie dostaje capability tokenu dopóki nie ma touch.
Co ~2h ciągłej sesji (konfigurowalny interwał) — re-auth, żeby długie autonomiczne sesje nie żyły wiecznie na jednym zezwoleniu.
Po każdym odblokowaniu ekranu — wznowienie pracy = ponowna obecność.

Czemu to inny kształt niż #132 / #567

#132 = consent przed konkretną akcją (event-driven, per-manifest).
#567 = ostatni gate przed destruktywną/bulk akcją (event-driven, high-stakes).
Role 7 (tu) = ambient presence — nie blokuje konkretnej akcji, tylko utrzymuje "operator jest fizycznie przy maszynie" jako warunek życia sesji. Tani, niski-tarcie, pasuje do auto-mode.

Dlaczego to ma sens teraz (Oracle verdict)

Oracle wskazał AI-agents-executing-code jako najsłabszy punkt całego stacku (ControlD+LittleSnitch+Bitdefender+Tailscale mocne na sieć, słabe na autonomiczne wykonanie kodu z dostępem do $HOME/sekretów). Periodic presence gate to tani sposób na ograniczenie blast-radius porwanej/zostawionej-bez-nadzoru sesji bez psucia produktywności (nie pyta o każdy krok — tylko "czy człowiek wciąż tu jest").

Open questions

Mechanizm: pam_u2f (touch do sudo/unlock) vs custom platformctl challenge vs ssh-keygen -t ed25519-sk verify-required jako proxy obecności?
Interwał: stały 2h czy adaptacyjny (krótszy gdy sesja dotyka secrets/destructive)?
Co się dzieje po wygaśnięciu: agent pauzuje i czeka na touch, czy hard-stop?
Integracja z auto-mode: operator zauważył że auto-mode wymaga dobrych deterministycznych planów + jasnej eskalacji — presence gate mógłby być punktem eskalacji.
Hardware: 1 key primary + 1 backup (z #181) — presence gate akceptuje oba.

Refs

Parent: #132 (operator consent), #181 (6-role catalog — to issue), #567 (destructive gate)
Spec Kit: claude/spec/yubikey-platform-integration-v0 (476 linii, P1-P8)
Kontekst stacku: sesja "macbook fixing" memory security-stack.md

## Role 7 (nowa) — YubiKey jako *periodic presence gate* dla agent sessions Z sesji audytu MacBooka 2026-05-30 (security-stack review + werdykt Oracle GPT-5.5 Pro). Operator dorzuca **siódmą rolę** do katalogu — uzupełnia event-driven gate'y (#132, #567) o **wymiar czasowy/obecnościowy**. ### Pomysł operatora (voice-note 2026-05-30) YubiKey musi być **fizycznie obecny / dotknięty** w trzech momentach: 1. **Na początku sesji agenta** (Claude Code / Codex start) — agent nie dostaje capability tokenu dopóki nie ma touch. 2. **Co ~2h ciągłej sesji** (konfigurowalny interwał) — re-auth, żeby długie autonomiczne sesje nie żyły wiecznie na jednym zezwoleniu. 3. **Po każdym odblokowaniu ekranu** — wznowienie pracy = ponowna obecność. ### Czemu to inny kształt niż #132 / #567 - **#132** = consent przed konkretną akcją (event-driven, per-manifest). - **#567** = ostatni gate przed destruktywną/bulk akcją (event-driven, high-stakes). - **Role 7 (tu)** = *ambient presence* — nie blokuje konkretnej akcji, tylko utrzymuje "operator jest fizycznie przy maszynie" jako warunek życia sesji. Tani, niski-tarcie, pasuje do auto-mode. ### Dlaczego to ma sens teraz (Oracle verdict) Oracle wskazał **AI-agents-executing-code jako najsłabszy punkt** całego stacku (ControlD+LittleSnitch+Bitdefender+Tailscale mocne na sieć, słabe na autonomiczne wykonanie kodu z dostępem do $HOME/sekretów). Periodic presence gate to **tani sposób na ograniczenie blast-radius** porwanej/zostawionej-bez-nadzoru sesji bez psucia produktywności (nie pyta o każdy krok — tylko "czy człowiek wciąż tu jest"). ### Open questions - [ ] Mechanizm: `pam_u2f` (touch do sudo/unlock) vs custom platformctl challenge vs `ssh-keygen -t ed25519-sk verify-required` jako proxy obecności? - [ ] Interwał: stały 2h czy adaptacyjny (krótszy gdy sesja dotyka secrets/destructive)? - [ ] Co się dzieje po wygaśnięciu: agent pauzuje i czeka na touch, czy hard-stop? - [ ] Integracja z auto-mode: operator zauważył że auto-mode wymaga **dobrych deterministycznych planów + jasnej eskalacji** — presence gate mógłby być punktem eskalacji. - [ ] Hardware: 1 key primary + 1 backup (z #181) — presence gate akceptuje oba. ### Refs - Parent: #132 (operator consent), #181 (6-role catalog — to issue), #567 (destructive gate) - Spec Kit: `claude/spec/yubikey-platform-integration-v0` (476 linii, P1-P8) - Kontekst stacku: sesja "macbook fixing" memory `security-stack.md`

claude added the

priority:p3

label

2026-05-30 22:43:08 +02:00

claude added the

status:parked

label

2026-06-01 08:53:15 +02:00

claude commented

2026-06-01 08:53:16 +02:00

Author

Collaborator

Parked (p3, M10 closure plan #653 + Judging Claw priority). Reactivate when 2x YubiKey auth-chain integration is scheduled.

**Parked (p3, M10 closure plan #653 + Judging Claw priority).** Reactivate when 2x YubiKey auth-chain integration is scheduled.

Iskra commented

2026-06-09 03:03:28 +02:00

Collaborator

{
"confidence": 5,
"effort_hint": "large",
"escalation": {
"kind": "operator",
"reason": "YubiKey adoption changes account recovery, hardware custody, and authentication policy."
},
"evidence_refs": [
{
"note": "Issue scopes integration of two YubiKeys into the platform authentication chain across six roles.",
"type": "forgejo",
"value": "issue-title-body-labels-and-target-snapshot"
},
{
"note": "Body states two hardware keys enable primary plus backup adoption instead of single-key lockout risk.",
"type": "forgejo",
"value": "issue-body-hardware-inventory"
},
{
"note": "Snapshot labels mark the work as priority p3 and parked.",
"type": "snapshot",
"value": "target-snapshot-labels"
}
],
"impact": 4,
"judge_actor": {
"name": "iskra",
"runtime": "openclaw"
},
"judged_at": "2026-06-09T01:03:00Z",
"labels_to_apply": [
"judge/p2",
"judge/operator-needed"
],
"piotr_fit": "high",
"priority": "p2",
"rationale_summary": "This is P2 operator-shaped security architecture because YubiKey rollout can harden auth only with deliberate recovery, custody, and sequencing decisions.",
"reach": 4,
"recommended_next_action": "operator_needed",
"rerun_reason": "no_prior_judgment",
"schema": "openclaw.judge.v0",
"target": {
"kind": "issue",
"number": 181,
"repo": "pdurlej/platform"
},
"target_snapshot": {
"body_hash": "sha256:f6973984ee9f2968e2677089bc841ff2c8f8c3e3eac32948f6edbb3e997c1827",
"commit_count": null,
"evidence_hash": "sha256:274b578d096aef76bc08058811c72239040329a54c30380fca68d1efbf75f608",
"head_sha": null,
"labels": [
"agent/claude-code",
"priority:p3",
"status:parked"
],
"labels_hash": "sha256:9e8ed9cb7b1b30f4dcf389e2b3d1f8e66c19eb940504926be5872a601be5b3ab",
"state": "open",
"title_hash": "sha256:d229fc420e35e68bd2d92f5b2bd14fd607d081f42a3d7418ee717f6022c08534",
"updated_at": "2026-06-01T08:53:16+02:00"
},
"top_caveat": "Do not enable hardware-key requirements until backup-key enrollment, recovery paths, and lockout drills are explicit."
}

{ "confidence": 5, "effort_hint": "large", "escalation": { "kind": "operator", "reason": "YubiKey adoption changes account recovery, hardware custody, and authentication policy." }, "evidence_refs": [ { "note": "Issue scopes integration of two YubiKeys into the platform authentication chain across six roles.", "type": "forgejo", "value": "issue-title-body-labels-and-target-snapshot" }, { "note": "Body states two hardware keys enable primary plus backup adoption instead of single-key lockout risk.", "type": "forgejo", "value": "issue-body-hardware-inventory" }, { "note": "Snapshot labels mark the work as priority p3 and parked.", "type": "snapshot", "value": "target-snapshot-labels" } ], "impact": 4, "judge_actor": { "name": "iskra", "runtime": "openclaw" }, "judged_at": "2026-06-09T01:03:00Z", "labels_to_apply": [ "judge/p2", "judge/operator-needed" ], "piotr_fit": "high", "priority": "p2", "rationale_summary": "This is P2 operator-shaped security architecture because YubiKey rollout can harden auth only with deliberate recovery, custody, and sequencing decisions.", "reach": 4, "recommended_next_action": "operator_needed", "rerun_reason": "no_prior_judgment", "schema": "openclaw.judge.v0", "target": { "kind": "issue", "number": 181, "repo": "pdurlej/platform" }, "target_snapshot": { "body_hash": "sha256:f6973984ee9f2968e2677089bc841ff2c8f8c3e3eac32948f6edbb3e997c1827", "commit_count": null, "evidence_hash": "sha256:274b578d096aef76bc08058811c72239040329a54c30380fca68d1efbf75f608", "head_sha": null, "labels": [ "agent/claude-code", "priority:p3", "status:parked" ], "labels_hash": "sha256:9e8ed9cb7b1b30f4dcf389e2b3d1f8e66c19eb940504926be5872a601be5b3ab", "state": "open", "title_hash": "sha256:d229fc420e35e68bd2d92f5b2bd14fd607d081f42a3d7418ee717f6022c08534", "updated_at": "2026-06-01T08:53:16+02:00" }, "top_caveat": "Do not enable hardware-key requirements until backup-key enrollment, recovery paths, and lockout drills are explicit." }

Iskra added the

judge/operator-needed

judge/p2

labels

2026-06-09 03:03:28 +02:00

codex referenced this issue

2026-06-11 00:14:03 +02:00

docs(agent-readiness): clean stale ADR references #787