README defines 'warded' as a deny-list bounding the agent's reach; container-permissions.md says no deny wall exists anywhere and isolation is the sole boundary

coilyco-ops commented

2026-07-01 22:54:00 +00:00

Owner

Why

Persona security-skeptic / angle front-page. The README's second paragraph defines the product name by an enforcement mechanism:

Read "warded" as a protective circle - the deny-list and allowlisted verbs bounding its reach, not "warded off".

The skeptic's next click is the container docs, where docs/container-permissions.md states the opposite, deliberately (per ward#375):

The container writes no permissions.deny list. There is no harness-level guard against force-push, history rewrites, or hard resets - the container's isolation … is the sole boundary.
The AGENTS.container.md wall (force-push, other repos, data loss out of bounds) stays a doctrine the agent follows, not an enforced rule.

So for the flagship use (a warded agent in a container): there is no deny-list, and "allowlisted verbs" bound nothing — the agent runs bypassPermissions with a full shell, and dev-verb gating applies only when it chooses to route through ward. The actual (and defensible!) boundary is container isolation plus a repo-scoped token. But that is not what the front page says the name means. A security evaluator who reads both pages concludes the front page oversells the mechanism — and if the front page oversells the mechanism, they stop trusting the parts they can't verify.

This is the definitional-sentence sibling of #452 ("refuse Y and prove it" vs the fail-open hook): same class (front-page enforcement claim contradicted by the project's own honest docs), different sentence, independently fixable. Related: #451 (SECURITY.md scope omits the agent surface), #473 (blast-radius claim vs --repo grants), ward#375 (the eng change that made isolation the sole boundary).

Deliverable

Rewrite the "protective circle" sentence to name the real boundary for the container case — ephemeral container isolation + repo-scoped token + doctrine — and reserve "deny-list / allowlisted verbs" language for the surfaces where lists actually enforce (cli-guard dev verbs on the host, permissions.deny where users configure it).

Done condition

No front-page sentence attributes to warded agents an enforcement mechanism that docs/container-permissions.md says does not exist; a reader of both pages finds one consistent story about what bounds a warded agent.

Severity: adoption-fatal · persona: security-skeptic · angle: front-page
Filed by Claude Code during a cold-read release pressure test (run 34).

## Why Persona `security-skeptic` / angle `front-page`. The README's second paragraph defines the product name by an enforcement mechanism: > Read "warded" as a protective circle - **the deny-list and allowlisted verbs bounding its reach**, not "warded off". The skeptic's next click is the container docs, where `docs/container-permissions.md` states the opposite, deliberately (per ward#375): > The container writes **no** `permissions.deny` list. There is no harness-level guard against force-push, history rewrites, or hard resets - the container's isolation … is the **sole** boundary. > The AGENTS.container.md wall (force-push, other repos, data loss out of bounds) **stays a doctrine the agent follows, not an enforced rule.** So for the flagship use (a warded agent in a container): there is no deny-list, and "allowlisted verbs" bound nothing — the agent runs `bypassPermissions` with a full shell, and dev-verb gating applies only when it chooses to route through `ward`. The actual (and defensible!) boundary is container isolation plus a repo-scoped token. But that is not what the front page says the name means. A security evaluator who reads both pages concludes the front page oversells the mechanism — and if the front page oversells the mechanism, they stop trusting the parts they can't verify. This is the definitional-sentence sibling of #452 ("refuse Y and prove it" vs the fail-open hook): same class (front-page enforcement claim contradicted by the project's own honest docs), different sentence, independently fixable. Related: #451 (SECURITY.md scope omits the agent surface), #473 (blast-radius claim vs `--repo` grants), ward#375 (the eng change that made isolation the sole boundary). ## Deliverable Rewrite the "protective circle" sentence to name the real boundary for the container case — ephemeral container isolation + repo-scoped token + doctrine — and reserve "deny-list / allowlisted verbs" language for the surfaces where lists actually enforce (cli-guard dev verbs on the host, `permissions.deny` where users configure it). ## Done condition No front-page sentence attributes to warded agents an enforcement mechanism that `docs/container-permissions.md` says does not exist; a reader of both pages finds one consistent story about what bounds a warded agent. --- **Severity: adoption-fatal** · persona: security-skeptic · angle: front-page Filed by Claude Code during a cold-read release pressure test (run 34).

coilyco-ops added the

pressure-test

label

2026-07-01 22:54:00 +00:00

coilyco-ops referenced this issue

2026-07-01 22:54:42 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops commented

2026-07-01 23:00:05 +00:00

Author

Owner

+1 with a concrete supporting data point, run 20 (agent-power-user / security-posture): docs/agent-credentials.mds codex section confirms the same story from a different angle - the entrypoint writes ~/.codex/config.toml with approval_policy = "never" and sandbox_mode = "danger-full-access" specifically because "the container is the isolation boundary." So not only is there no permissions.deny list per this issue, the codex driver is explicitly configured with zero approval gating and full filesystem access inside the container, betting entirely on isolation. Reasonable design, but it sharpens the point: the READMEs "deny-list and allowlisted verbs" framing is not just incomplete for the container case, its the opposite of how the highest-risk driver (codex, danger-full-access) is actually configured.

+1 with a concrete supporting data point, run 20 (`agent-power-user` / `security-posture`): `docs/agent-credentials.md`s codex section confirms the same story from a different angle - the entrypoint writes `~/.codex/config.toml` with `approval_policy = "never"` and `sandbox_mode = "danger-full-access"` specifically *because* "the container is the isolation boundary." So not only is there no `permissions.deny` list per this issue, the codex driver is explicitly configured with zero approval gating and full filesystem access inside the container, betting entirely on isolation. Reasonable design, but it sharpens the point: the READMEs "deny-list and allowlisted verbs" framing is not just incomplete for the container case, its the opposite of how the highest-risk driver (codex, danger-full-access) is actually configured.

coilyco-ops referenced this issue

2026-07-01 23:00:05 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops added this to the ward launch milestone

2026-07-01 23:29:23 +00:00

coilyco-ops added the

labels

2026-07-01 23:30:44 +00:00

coilyco-ops referenced this issue

2026-07-01 23:58:15 +00:00

README opening buries what ward actually does under four paragraphs of naming lore and unexplained bare issue refs #444

coilyco-ops commented

2026-07-01 23:58:17 +00:00

Author

Owner

DECISION - resolve in favor of container-permissions.md (the truth): container isolation + repo-scoped token is the sole boundary for containerized agents; the 'deny-list / allowlisted verbs' language describes the dev-verb gate only. README definition rewritten inside the #444 epic; closes with that PR. Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

coilyco-ops referenced this issue

2026-07-02 00:01:42 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilysiren referenced this issue

2026-07-02 02:44:32 +00:00

README opening buries what ward actually does under four paragraphs of naming lore and unexplained bare issue refs #444

coilysiren commented

2026-07-02 02:48:15 +00:00

Owner

Verification close from the ward#492 burndown director: the #444 epic commit b0ce6d5 rewrote the README's warded definition per this ticket's DECISION - it now reads 'a protective circle, the container bounding the agent's reach' (README line 71), with the deny-list / allowlisted-verbs language removed from the agent-boundary claim entirely. The remaining deny-list copy describes only the dev-verb gate, which matches docs/container-permissions.md's truth. Closing via the issue API. Recorded by Claude Code (Fable) during the ward#492 burndown session.

Verification close from the ward#492 burndown director: the #444 epic commit `b0ce6d5` rewrote the README's warded definition per this ticket's DECISION - it now reads 'a protective circle, the container bounding the agent's reach' (README line 71), with the deny-list / allowlisted-verbs language removed from the agent-boundary claim entirely. The remaining deny-list copy describes only the dev-verb gate, which matches docs/container-permissions.md's truth. Closing via the issue API. Recorded by Claude Code (Fable) during the ward#492 burndown session.

coilysiren closed this issue

2026-07-02 02:48:15 +00:00

coilysiren referenced this issue

2026-07-02 07:10:55 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilysiren referenced this issue

2026-07-02 08:46:15 +00:00

fix(director): defer dispatch-time infra failures instead of parking them failed (backlog wedge) #524

coilysiren referenced this issue

2026-07-02 08:57:34 +00:00

fix(director): self-heal legacy dispatch-error strandings + give declines a distinct status (ward#524 follow-up) #527

coilysiren referenced this issue