pdurlej/platform

Fork 0

explore(security): YubiKey-backed operator consent for bounded agent execution #132

New issue

Open

opened 2026-05-09 14:03:59 +02:00 by Iskra · 4 comments

Iskra commented

2026-05-09 14:03:59 +02:00

Collaborator

Context

Piotr is exploring a Product Pro Summit demo and broader agent-control pattern where autonomous/semi-autonomous agent workflows can be started or escalated only after a physical operator approval using YubiKey.

This is not “give the agent the key”. The intended pattern is:

agent prepares action/plan/manifest -> platform presents bounded execution manifest -> Piotr physically approves/signs with YubiKey -> agents receive a time-scoped, capability-scoped authorization token -> execution proceeds within those bounds.

Working name:

YubiKey-backed operator consent for bounded autonomous execution

or shorter:

operator presence gate.

Why this matters

For agentic systems, the dangerous boundary is not read-only reasoning. It is when an agent moves from planning into real-world mutation:

creating/updating external project state,
opening/merging PRs,
deploying,
sending messages externally,
spending money/tokens above a threshold,
accessing secrets,
starting multi-agent workflows,
granting delegation to other agents.

A physical presence gate could provide a strong, auditable human-in-the-loop control without making the human approve every tiny step.

Candidate scenarios

1. Product Pro Summit demo

Demo fantasy:

Piotr gives Iskra a brief.
Iskra creates/updates upstream work in Kan.
Downstream projection appears in Forgejo Projects/issues.
Hermes upstream agency starts working for ~10 minutes.
Heartswarm/Swarmheart performs the next 10-minute delivery loop after Piotr command.
YubiKey acts as the 2FA/operator authorization gate for starting or escalating these processes.

The demo should show:

human speaks intent,
agent prepares plan/manifest,
YubiKey confirms operator presence,
agents act within explicit limits,
board/project state changes visibly,
audit trail remains replayable.

2. Step-up auth for risky actions

Possible policy tiers:

read-only: no YubiKey required,
internal draft/write: soft approval or existing session,
Kan/Forgejo mutation: bounded session approval,
deploy/public/external send: YubiKey required,
destructive/security-sensitive: YubiKey + explicit manifest + maybe second confirmation.

3. Signed delegation manifest

Example manifest:

{
  "action": "start_swarmheart_demo",
  "project": "product-pro-summit-demo",
  "allowed_until": "2026-05-09T14:30:00Z",
  "max_cost_usd": 20,
  "targets": ["kan", "forgejo"],
  "allowed_commands": ["create_task", "add_checkpoint", "attach_artifact", "request_decision"],
  "forbidden_commands": ["deploy", "delete", "external_send"],
  "operator": "piotr"
}

YubiKey signs/approves the manifest. Agents do not receive secrets; they receive only the resulting signed authorization/decision state.

4. Commit / decision / artifact signing

Explore whether YubiKey should be used for:

SSH/FIDO2 auth to Forgejo/Git,
GPG or SSH commit/tag signing,
signing decision manifests,
WebAuthn approval in a control panel,
local CLI confirmation with touch-required key.

Questions to answer

Is this best implemented as WebAuthn, FIDO2/SSH signing, GPG signing, PIV, or a combination?
What is the minimal viable operator approval primitive for OpenClaw/Platform?
Where should signed approvals live: platform DB, OpenClaw state, event log, Forgejo issue comments, or all via projections?
How do we prevent replay of old approvals?
How do we scope approvals by time, target, action, cost, and project?
Can approvals be revoked/cancelled mid-run?
How should agents verify that a given action is authorized?
How does this integrate with Swarmheart/Kan/Forgejo Projects/Iskra Signal UX?
What happens if Piotr has two YubiKeys? Can both be registered as equivalent operator authenticators with different backup/rotation semantics?
How to make the demo impressive without weakening real security?

Initial design constraints

Agent must never get direct access to the YubiKey, private key, or reusable secret.
Physical touch/approval should authorize a bounded manifest, not a broad ambient session.
Approval must be auditable and replayable.
Approval should be revocable or naturally expire quickly.
The default should be least privilege: action allowlist, time window, project scope, target systems, budget/cost cap.
The system should distinguish “operator saw this” from “operator authorized this exact action”.
Avoid building a heavyweight IAM system in v1.

Proposed v1 exploration output

Survey implementation options: WebAuthn, FIDO2 SSH, GPG, PIV, age/sops-style signing, local CLI touch gate.
Recommend one minimal v1 path for Product Pro Summit demo.
Define a signed approval manifest schema.
Define verification flow for agents/platform commands.
Define storage/audit model.
Define revocation/expiry behavior.
Define UX: Signal prompt vs web dashboard vs local CLI/browser approval.
Include threat model: stolen session, malicious prompt, compromised agent, replay attack, overbroad approval, lost key.
Consider two-key setup for Piotr: primary + backup.
Identify which parts belong in platform vs iskra-openclaw vs Swarmheart/agent runtime.

Acceptance criteria

This issue is exploratory. It is done when we have:

A concrete recommendation for YubiKey-backed operator approval in agent workflows.
A minimal architecture for bounded autonomous execution approvals.
A Product Pro Summit demo path that is safe enough to show and honest enough not to fake security.
A clear decision on whether implementation should start in platform, iskra-openclaw, or both.

## Context Piotr is exploring a Product Pro Summit demo and broader agent-control pattern where autonomous/semi-autonomous agent workflows can be started or escalated only after a physical operator approval using YubiKey. This is not “give the agent the key”. The intended pattern is: > agent prepares action/plan/manifest -> platform presents bounded execution manifest -> Piotr physically approves/signs with YubiKey -> agents receive a time-scoped, capability-scoped authorization token -> execution proceeds within those bounds. Working name: **YubiKey-backed operator consent for bounded autonomous execution** or shorter: **operator presence gate**. ## Why this matters For agentic systems, the dangerous boundary is not read-only reasoning. It is when an agent moves from planning into real-world mutation: - creating/updating external project state, - opening/merging PRs, - deploying, - sending messages externally, - spending money/tokens above a threshold, - accessing secrets, - starting multi-agent workflows, - granting delegation to other agents. A physical presence gate could provide a strong, auditable human-in-the-loop control without making the human approve every tiny step. ## Candidate scenarios ### 1. Product Pro Summit demo Demo fantasy: 1. Piotr gives Iskra a brief. 2. Iskra creates/updates upstream work in Kan. 3. Downstream projection appears in Forgejo Projects/issues. 4. Hermes upstream agency starts working for ~10 minutes. 5. Heartswarm/Swarmheart performs the next 10-minute delivery loop after Piotr command. 6. YubiKey acts as the 2FA/operator authorization gate for starting or escalating these processes. The demo should show: - human speaks intent, - agent prepares plan/manifest, - YubiKey confirms operator presence, - agents act within explicit limits, - board/project state changes visibly, - audit trail remains replayable. ### 2. Step-up auth for risky actions Possible policy tiers: - read-only: no YubiKey required, - internal draft/write: soft approval or existing session, - Kan/Forgejo mutation: bounded session approval, - deploy/public/external send: YubiKey required, - destructive/security-sensitive: YubiKey + explicit manifest + maybe second confirmation. ### 3. Signed delegation manifest Example manifest: ```json { "action": "start_swarmheart_demo", "project": "product-pro-summit-demo", "allowed_until": "2026-05-09T14:30:00Z", "max_cost_usd": 20, "targets": ["kan", "forgejo"], "allowed_commands": ["create_task", "add_checkpoint", "attach_artifact", "request_decision"], "forbidden_commands": ["deploy", "delete", "external_send"], "operator": "piotr" } ``` YubiKey signs/approves the manifest. Agents do not receive secrets; they receive only the resulting signed authorization/decision state. ### 4. Commit / decision / artifact signing Explore whether YubiKey should be used for: - SSH/FIDO2 auth to Forgejo/Git, - GPG or SSH commit/tag signing, - signing decision manifests, - WebAuthn approval in a control panel, - local CLI confirmation with touch-required key. ## Questions to answer - Is this best implemented as WebAuthn, FIDO2/SSH signing, GPG signing, PIV, or a combination? - What is the minimal viable operator approval primitive for OpenClaw/Platform? - Where should signed approvals live: platform DB, OpenClaw state, event log, Forgejo issue comments, or all via projections? - How do we prevent replay of old approvals? - How do we scope approvals by time, target, action, cost, and project? - Can approvals be revoked/cancelled mid-run? - How should agents verify that a given action is authorized? - How does this integrate with Swarmheart/Kan/Forgejo Projects/Iskra Signal UX? - What happens if Piotr has two YubiKeys? Can both be registered as equivalent operator authenticators with different backup/rotation semantics? - How to make the demo impressive without weakening real security? ## Initial design constraints - Agent must never get direct access to the YubiKey, private key, or reusable secret. - Physical touch/approval should authorize a bounded manifest, not a broad ambient session. - Approval must be auditable and replayable. - Approval should be revocable or naturally expire quickly. - The default should be least privilege: action allowlist, time window, project scope, target systems, budget/cost cap. - The system should distinguish “operator saw this” from “operator authorized this exact action”. - Avoid building a heavyweight IAM system in v1. ## Proposed v1 exploration output - [ ] Survey implementation options: WebAuthn, FIDO2 SSH, GPG, PIV, age/sops-style signing, local CLI touch gate. - [ ] Recommend one minimal v1 path for Product Pro Summit demo. - [ ] Define a signed approval manifest schema. - [ ] Define verification flow for agents/platform commands. - [ ] Define storage/audit model. - [ ] Define revocation/expiry behavior. - [ ] Define UX: Signal prompt vs web dashboard vs local CLI/browser approval. - [ ] Include threat model: stolen session, malicious prompt, compromised agent, replay attack, overbroad approval, lost key. - [ ] Consider two-key setup for Piotr: primary + backup. - [ ] Identify which parts belong in `platform` vs `iskra-openclaw` vs Swarmheart/agent runtime. ## Acceptance criteria This issue is exploratory. It is done when we have: 1. A concrete recommendation for YubiKey-backed operator approval in agent workflows. 2. A minimal architecture for bounded autonomous execution approvals. 3. A Product Pro Summit demo path that is safe enough to show and honest enough not to fake security. 4. A clear decision on whether implementation should start in `platform`, `iskra-openclaw`, or both.

Iskra referenced this issue

2026-05-09 14:06:10 +02:00

investigate(mobile): fix Forji iOS Forgejo PAT auth and prepare upstream PRs #133

glm referenced this issue from a commit

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

WIP: feat(agent-access): v0 4-slice skeleton — session-scoped credential delivery [#76]

claude referenced this issue

2026-05-17 10:17:51 +02:00

WIP: feat(agent-access): v0 4-slice skeleton — session-scoped credential delivery [#76] #323

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:49 +02:00

Collaborator

W4d handoff note — 2026-05-24

Role: executor
Intent: handoff
Needs owner: no

Opened #442 to record that YubiKey/operator-presence work is valuable future design, but not a W4 closeout blocker. Recommended shape remains decision/spec first, then bounded-manifest approval; agents must never receive the hardware key or reusable secret.

Runtime: none.

## W4d handoff note — 2026-05-24 **Role:** executor **Intent:** handoff **Needs owner:** no Opened #442 to record that YubiKey/operator-presence work is valuable future design, but not a W4 closeout blocker. Recommended shape remains decision/spec first, then bounded-manifest approval; agents must never receive the hardware key or reusable secret. 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

ollama referenced this issue

2026-05-28 13:06:00 +02:00

explore(security): YubiKey as last operator approval gate before bulk-destroy / irreversible actions #567

codex commented

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

Collaborator

M10 disposition: moved to 10 - Improvements.

What this is: YubiKey-backed operator consent for agent execution.

Why parked here: Parked in M10 because it belongs to future operator-presence/capability work, not the current Infisical/PAT cleanup lane.

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: YubiKey-backed operator consent for agent execution. Why parked here: Parked in M10 because it belongs to future operator-presence/capability work, not the current Infisical/PAT cleanup lane. 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:45 +02:00

claude added the

agent/claude-code

label

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

claude referenced this issue

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

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

claude commented

2026-06-01 08:54:35 +02:00

Collaborator

M10 closure note: held, not parked. This issue has no priority:* from Judging Claw, unlike the rest of M10. It is part of the security / agent-access cluster (#76 Agent Access Plane + #132/#567 YubiKey operator-consent). Held out of the p3-park batch because security-sensitive design warrants a deliberate priority decision, not default-parking. Next: Judging Claw / operator assigns priority, then consolidate the cluster into one Agent-Access + Hardware-Consent ADR. Ready reference: Infisical Agent Vault (Context7 /infisical/agent-vault).

**M10 closure note: held, not parked.** This issue has no `priority:*` from Judging Claw, unlike the rest of M10. It is part of the security / agent-access cluster (#76 Agent Access Plane + #132/#567 YubiKey operator-consent). Held out of the p3-park batch because security-sensitive design warrants a deliberate priority decision, not default-parking. Next: Judging Claw / operator assigns priority, then consolidate the cluster into one Agent-Access + Hardware-Consent ADR. Ready reference: Infisical Agent Vault (Context7 `/infisical/agent-vault`).

Iskra commented

2026-06-08 03:02:44 +02:00

Author

Collaborator

{
"confidence": 5,
"effort_hint": "large",
"escalation": {
"kind": "hermes_review",
"reason": "Physical operator consent for agent mutation needs security and product architecture shaping."
},
"evidence_refs": [
{
"note": "Issue explores YubiKey-backed operator consent for bounded autonomous agent execution.",
"type": "forgejo",
"value": "issue-title-body-labels-and-target-snapshot"
},
{
"note": "Body defines a manifest-to-physical-approval flow that grants time-scoped capability authorization.",
"type": "forgejo",
"value": "issue-body-intended-pattern"
},
{
"note": "Body frames real-world mutation as the dangerous boundary requiring explicit operator presence.",
"type": "forgejo",
"value": "issue-body-risk-boundary"
}
],
"impact": 5,
"judge_actor": {
"name": "iskra",
"runtime": "openclaw"
},
"judged_at": "2026-06-08T01:01:00Z",
"labels_to_apply": [
"judge/p1",
"judge/hermes-candidate"
],
"piotr_fit": "high",
"priority": "p1",
"rationale_summary": "This is P1 architecture work because physical operator consent can become the core safety gate for bounded agent mutation.",
"reach": 5,
"recommended_next_action": "hermes_candidate",
"rerun_reason": "no_prior_judgment",
"schema": "openclaw.judge.v0",
"target": {
"kind": "issue",
"number": 132,
"repo": "pdurlej/platform"
},
"target_snapshot": {
"body_hash": "sha256:8732a5b0d008ac1f7784d9b4be93bd8d0cfb3f0ed2d986f64ee4faf366f8ea01",
"commit_count": null,
"evidence_hash": "sha256:4aebcbde70f44cb037ed2a29d1fe2677d1c2914bb387b5b691551ad0f3b3e714",
"head_sha": null,
"labels": [
"agent/claude-code"
],
"labels_hash": "sha256:ae196d477682b017093b459243e1d16cfb291d1ea2cc928b191bab51fa5081d7",
"state": "open",
"title_hash": "sha256:5eb05e31d04b27eaf704ed5c06d5496c0b33686d22690fd944a7ee7a64986772",
"updated_at": "2026-06-01T08:54:35+02:00"
},
"top_caveat": "Keep the core as signed scoped consent and auditability, not merely YubiKey possession or secret storage."
}

{ "confidence": 5, "effort_hint": "large", "escalation": { "kind": "hermes_review", "reason": "Physical operator consent for agent mutation needs security and product architecture shaping." }, "evidence_refs": [ { "note": "Issue explores YubiKey-backed operator consent for bounded autonomous agent execution.", "type": "forgejo", "value": "issue-title-body-labels-and-target-snapshot" }, { "note": "Body defines a manifest-to-physical-approval flow that grants time-scoped capability authorization.", "type": "forgejo", "value": "issue-body-intended-pattern" }, { "note": "Body frames real-world mutation as the dangerous boundary requiring explicit operator presence.", "type": "forgejo", "value": "issue-body-risk-boundary" } ], "impact": 5, "judge_actor": { "name": "iskra", "runtime": "openclaw" }, "judged_at": "2026-06-08T01:01:00Z", "labels_to_apply": [ "judge/p1", "judge/hermes-candidate" ], "piotr_fit": "high", "priority": "p1", "rationale_summary": "This is P1 architecture work because physical operator consent can become the core safety gate for bounded agent mutation.", "reach": 5, "recommended_next_action": "hermes_candidate", "rerun_reason": "no_prior_judgment", "schema": "openclaw.judge.v0", "target": { "kind": "issue", "number": 132, "repo": "pdurlej/platform" }, "target_snapshot": { "body_hash": "sha256:8732a5b0d008ac1f7784d9b4be93bd8d0cfb3f0ed2d986f64ee4faf366f8ea01", "commit_count": null, "evidence_hash": "sha256:4aebcbde70f44cb037ed2a29d1fe2677d1c2914bb387b5b691551ad0f3b3e714", "head_sha": null, "labels": [ "agent/claude-code" ], "labels_hash": "sha256:ae196d477682b017093b459243e1d16cfb291d1ea2cc928b191bab51fa5081d7", "state": "open", "title_hash": "sha256:5eb05e31d04b27eaf704ed5c06d5496c0b33686d22690fd944a7ee7a64986772", "updated_at": "2026-06-01T08:54:35+02:00" }, "top_caveat": "Keep the core as signed scoped consent and auditability, not merely YubiKey possession or secret storage." }

Iskra added the

judge/hermes-candidate

judge/p1

labels

2026-06-08 03:02:45 +02:00

Iskra referenced this issue from pdurlej/judging-claw

2026-06-08 03:02:45 +02:00

[Judging Claw] hermes_candidate for pdurlej/platform#132 (p1) #62

codex referenced this issue

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

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