coilysiren commented

Owner

Consume cli-guard deny-by-structure engine: ward holds its own `protectedCommands` literal

Consumer side of cli-guard#79, ward flavor.

Why

ward#4 established protected-CLI isolation (deny-direct, wrappers, security doctor, PATH-shim + passwordless-sudo posture). cli-guard#79 generalizes the mechanism into a literal-driven engine so the deny logic stops being an exhaustive, drifting enumeration and becomes a small stable literal the consumer owns.

What

Once cli-guard#79 lands:

ward declares its own small literal protectedCommands: [...] (its protected tools, e.g. the cloud/cluster tooling from ward#4's example-cloud / example-clusterctl) plus route hints to the approved wrappers, in ward's .agent-guard/repocfg config.
ward delegates shim generation, basename/absolute-path hook matching, and sudo-floor posture to the cli-guard engine instead of carrying its own policy spelled out.
ward doctor security consumes the engine's posture checks (binary not user-executable, no broad passwordless sudo, no cred env) rather than reimplementing them.

Boundaries (both, sequenced)

Front-door now: shims route humans + agents to the audited ward wrapper.
sudo/ownership floor: real privileged binaries root-owned + not user-executable, agent user no passwordless sudo. The human shortcut is sudo <realtool> via the password she holds. Same-user absolute-path caveat per cli-guard#79.

Acceptance

ward owns its protected-command literal; cli-guard library stays policy-free.
ward doctor security findings come from the shared engine.
No exhaustive rendered denylist is ward's system of record; the literal + engine are.
ward#4 behavior (exec, lint, hook, doctor security) preserved.

cli-guard#79 (engine)
ward#4 (protected CLI isolation, security doctor)

# Consume cli-guard deny-by-structure engine: ward holds its own `protectedCommands` literal Consumer side of cli-guard#79, ward flavor. ## Why ward#4 established protected-CLI isolation (deny-direct, wrappers, security doctor, PATH-shim + passwordless-sudo posture). cli-guard#79 generalizes the mechanism into a literal-driven engine so the deny logic stops being an exhaustive, drifting enumeration and becomes a small stable literal the consumer owns. ## What Once cli-guard#79 lands: - ward declares its own small literal `protectedCommands: [...]` (its protected tools, e.g. the cloud/cluster tooling from ward#4's `example-cloud` / `example-clusterctl`) plus route hints to the approved wrappers, in ward's `.agent-guard`/`repocfg` config. - ward delegates shim generation, basename/absolute-path hook matching, and sudo-floor posture to the cli-guard engine instead of carrying its own policy spelled out. - `ward doctor security` consumes the engine's posture checks (binary not user-executable, no broad passwordless sudo, no cred env) rather than reimplementing them. ## Boundaries (both, sequenced) 1. Front-door now: shims route humans + agents to the audited ward wrapper. 2. sudo/ownership floor: real privileged binaries root-owned + not user-executable, agent user no passwordless sudo. The human shortcut is `sudo <realtool>` via the password she holds. Same-user absolute-path caveat per cli-guard#79. ## Acceptance - ward owns its protected-command literal; cli-guard library stays policy-free. - `ward doctor security` findings come from the shared engine. - No exhaustive rendered denylist is ward's system of record; the literal + engine are. - ward#4 behavior (exec, lint, hook, doctor security) preserved. ## Related - cli-guard#79 (engine) - ward#4 (protected CLI isolation, security doctor)

coilysiren added the

sunday-sprint

P2

labels

2026-06-06 04:16:46 +00:00

coilysiren added

P3

and removed

P2

labels

2026-06-17 08:39:50 +00:00

coilysiren added

P4

headless

and removed

P3

labels

2026-06-18 06:19:28 +00:00

coilyco-ops commented

2026-06-18 07:38:27 +00:00

Member

🛫 ward pre-flight: NO-GO

ward agent claude headless ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

blocked on upstream cli-guard#79 (the engine) — can't confirm it merged or learn its consumer API from the issue text alone, so unattended integration would be guesswork.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent claude headless <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

This is the consumer half of a two-repo change that is explicitly gated: "Once cli-guard#79 lands" — ward can only delegate shim generation, hook matching, and sudo-floor posture to the cli-guard engine if that engine exists and exposes a stable consumer API. The issue text gives me no confirmation that cli-guard#79 has merged, nor any sketch of the engine's consumer surface (function names, config schema for .agent-guard/repocfg, how ward doctor security is meant to call into it), so an unattended run risks either building against a non-existent dependency or inventing an integration contract that won't match what cli-guard actually shipped. The acceptance criteria (literal owned by ward, library stays policy-free, doctor findings sourced from the shared engine) are clear in intent but unverifiable without reading the upstream engine, which a fire-and-forget run can't safely guess at. This needs a human to confirm cli-guard#79 landed and point at its consumer API before detaching.

NO-GO: blocked on upstream cli-guard#79 (the engine) — can't confirm it merged or learn its consumer API from the issue text alone, so unattended integration would be guesswork.

Posted automatically by ward agent claude headless pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent claude headless` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > blocked on upstream cli-guard#79 (the engine) — can't confirm it merged or learn its consumer API from the issue text alone, so unattended integration would be guesswork. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent claude headless <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> This is the consumer half of a two-repo change that is explicitly gated: "Once cli-guard#79 lands" — ward can only delegate shim generation, hook matching, and sudo-floor posture to the cli-guard engine if that engine exists and exposes a stable consumer API. The issue text gives me no confirmation that cli-guard#79 has merged, nor any sketch of the engine's consumer surface (function names, config schema for `.agent-guard`/`repocfg`, how `ward doctor security` is meant to call into it), so an unattended run risks either building against a non-existent dependency or inventing an integration contract that won't match what cli-guard actually shipped. The acceptance criteria (literal owned by ward, library stays policy-free, doctor findings sourced from the shared engine) are clear in intent but unverifiable without reading the upstream engine, which a fire-and-forget run can't safely guess at. This needs a human to confirm cli-guard#79 landed and point at its consumer API before detaching. NO-GO: blocked on upstream cli-guard#79 (the engine) — can't confirm it merged or learn its consumer API from the issue text alone, so unattended integration would be guesswork. </details> --- Posted automatically by `ward agent claude headless` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-06-23 06:43:43 +00:00

Member

🛫 ward pre-flight: NO-GO

ward agent claude headless ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

hard dependency on upstream cli-guard#79 engine landing first; can't verify it's published or know its API surface unattended, and the task is undoable without it.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent claude headless <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

This issue is explicitly the consumer half of cli-guard#79 and is gated on that engine landing first ("Once cli-guard#79 lands..."). The whole task is delegating shim generation, hook matching, and sudo-floor posture checks to the cli-guard engine — so it can only be done if that engine is published and its API surface is known. From the issue text alone I can't confirm cli-guard#79 has landed or what its actual interface looks like, and if it hasn't, ward has nothing to consume and the run dead-ends. That's a real cross-repo sequencing dependency, not something I can resolve or safely guess at unattended.

NO-GO: hard dependency on upstream cli-guard#79 engine landing first; can't verify it's published or know its API surface unattended, and the task is undoable without it.

Posted automatically by ward agent claude headless pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent claude headless` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > hard dependency on upstream cli-guard#79 engine landing first; can't verify it's published or know its API surface unattended, and the task is undoable without it. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent claude headless <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> This issue is explicitly the consumer half of cli-guard#79 and is gated on that engine landing first ("Once cli-guard#79 lands..."). The whole task is delegating shim generation, hook matching, and sudo-floor posture checks to the cli-guard engine — so it can only be done if that engine is published and its API surface is known. From the issue text alone I can't confirm cli-guard#79 has landed or what its actual interface looks like, and if it hasn't, ward has nothing to consume and the run dead-ends. That's a real cross-repo sequencing dependency, not something I can resolve or safely guess at unattended. NO-GO: hard dependency on upstream cli-guard#79 engine landing first; can't verify it's published or know its API surface unattended, and the task is undoable without it. </details> --- Posted automatically by `ward agent claude headless` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilyco-ops referenced this issue

2026-06-23 06:48:48 +00:00

via this comment, its become clear that warded agents need to know how t… #230

coilyco-ops added

and removed

labels

2026-06-24 04:11:44 +00:00

coilyco-ops commented

2026-06-24 17:26:01 +00:00

Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P3 - Consume the cli-guard deny-by-structure engine, kept, blocked on cli-guard#79.
consult - Blocked on the upstream engine, human-gated until it lands.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P3** - Consume the cli-guard deny-by-structure engine, kept, blocked on cli-guard#79. - **consult** - Blocked on the upstream engine, human-gated until it lands.

coilyco-ops commented

2026-06-24 17:28:17 +00:00

Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P3 - Consume the cli-guard deny-by-structure engine, kept, blocked on cli-guard#79.
consult - Blocked on the upstream engine, human-gated until it lands.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P3** - Consume the cli-guard deny-by-structure engine, kept, blocked on cli-guard#79. - **consult** - Blocked on the upstream engine, human-gated until it lands.

coilysiren added

interactive

and removed

consult

labels

2026-07-01 04:29:59 +00:00

coilysiren commented

2026-07-06 18:57:51 +00:00

Author

Owner

Closing: superseded. cli-guard's deny-by-structure engine landed (v0.75: cli/repocfg) and ward already consumes it - ward doctor security over protected_binaries (cmd/ward/repocfg.go, doctor.go, doctor_probes.go), which is this issue's acceptance. Re-triage 2026-07-06.

coilysiren closed this issue

2026-07-06 18:57:52 +00:00

Rows
Columns

Consume cli-guard deny-by-structure engine: ward holds its own protectedCommands literal #56

Consume cli-guard deny-by-structure engine: ward holds its own protectedCommands literal

Why

What

Boundaries (both, sequenced)

Acceptance

Related

🛫 ward pre-flight: NO-GO

🛫 ward pre-flight: NO-GO

Consume cli-guard deny-by-structure engine: ward holds its own `protectedCommands` literal