SECURITY.md's vulnerability scope never mentions the ward agent/container/credential surface at all

coilyco-ops commented

2026-07-01 22:08:13 +00:00

Member

Why

Persona: security-skeptic, angle docs-ia (cross-checking the security-relevant doc set for gaps and contradictions). SECURITY.md's entire "What counts as a vulnerability" section is scoped to one surface:

ward verbs that bypass the cli-guard policy gate they claim to install

audit log entries written by ward that are unparseable, truncatable, or omittable

.ward/ward.yaml parse paths that execute shell or import host state in ways the README does not describe

on Linux, a descendant of a sandboxed ward verb... invoking a wrapped tool without re-entering the gate

Every bullet is about the ward exec/dev-verb gate. I grepped the full file for "agent", "container", and "credential" - zero hits. Yet the products headline feature, per the README's first sentence, is driving an agent harness into a container - and the docs elsewhere are explicit that this surface handles real secrets: docs/agent-credentials.md (host credential seeding into containers), docs/agent-host-net.md, docs/container-permissions.md, docs/agent-observability.md (opt-in telemetry). A security-skeptic "evaluating whether to let an agent loose with this" is evaluating exactly this surface, and SECURITY.md is silent on it: no statement of what counts as a vulnerability there, no threat-model boundary, no "what this does NOT protect against" for the credential-seeding or container-escape case specifically.

docs/comparison-openshell.md (linked from README, not SECURITY.md) does discuss the verb-vs-kernel boundary honestly, but it's a positioning doc, not a vulnerability-scope statement, and a reader following SECURITY.md's own "Reporting a vulnerability" flow has no reason to find it.

Deliverable

Extend SECURITY.md's "What counts as a vulnerability" section to explicitly cover the agent/container surface: credential leakage from the container, container escape, cross-repo credential bleed, telemetry/audit gaps in ward agent runs (parallel to the existing ward exec audit-log bullet). Link docs/comparison-openshell.md from SECURITY.md as the threat-model reference for what the verb-level gate does and does not defend against.

Done condition

SECURITY.md's vulnerability scope names the agent/container surface explicitly, with the same level of specificity it already gives the dev-verb gate.

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

## Why Persona: `security-skeptic`, angle `docs-ia` (cross-checking the security-relevant doc set for gaps and contradictions). SECURITY.md's entire "What counts as a vulnerability" section is scoped to one surface: > - ward verbs that bypass the cli-guard policy gate they claim to install > - audit log entries written by ward that are unparseable, truncatable, or omittable > - `.ward/ward.yaml` parse paths that execute shell or import host state in ways the README does not describe > - on Linux, a descendant of a sandboxed ward verb... invoking a wrapped tool without re-entering the gate Every bullet is about the `ward exec`/dev-verb gate. I grepped the full file for "agent", "container", and "credential" - zero hits. Yet the products headline feature, per the README's first sentence, is driving an agent harness into a container - and the docs elsewhere are explicit that this surface handles real secrets: `docs/agent-credentials.md` (host credential seeding into containers), `docs/agent-host-net.md`, `docs/container-permissions.md`, `docs/agent-observability.md` (opt-in telemetry). A `security-skeptic` "evaluating whether to let an agent loose with this" is evaluating *exactly* this surface, and SECURITY.md is silent on it: no statement of what counts as a vulnerability there, no threat-model boundary, no "what this does NOT protect against" for the credential-seeding or container-escape case specifically. `docs/comparison-openshell.md` (linked from README, not SECURITY.md) does discuss the verb-vs-kernel boundary honestly, but it's a positioning doc, not a vulnerability-scope statement, and a reader following SECURITY.md's own "Reporting a vulnerability" flow has no reason to find it. ## Deliverable Extend SECURITY.md's "What counts as a vulnerability" section to explicitly cover the agent/container surface: credential leakage from the container, container escape, cross-repo credential bleed, telemetry/audit gaps in `ward agent` runs (parallel to the existing `ward exec` audit-log bullet). Link `docs/comparison-openshell.md` from SECURITY.md as the threat-model reference for what the verb-level gate does and does not defend against. ## Done condition SECURITY.md's vulnerability scope names the agent/container surface explicitly, with the same level of specificity it already gives the dev-verb gate. --- **Severity: adoption-fatal** · persona: security-skeptic · angle: docs-ia Filed by Claude Code during a cold-read release pressure test (run 9).

coilyco-ops added the

pressure-test

label

2026-07-01 22:08:13 +00:00

coilyco-ops referenced this issue

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

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

coilyco-ops commented

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

Author

Member

+1 — independently hit via security-skeptic/docs-ia, this run. SECURITY.md does not mention the agent/container/credential surface, so the vulnerability scope is narrower than the public attack surface.

coilyco-ops referenced this issue

2026-07-01 22:24:36 +00:00

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

coilyco-ops referenced this issue

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

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 #482

coilyco-ops commented

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

Author

Member

+1 — independently hit via security-skeptic/front-page, run 34: the vuln-scope list still covers only dev-verb/audit/yaml/jail surfaces; nothing on agent, container, bypassPermissions, or credential seeding.

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 added this to the ward launch milestone

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

coilyco-ops added the

P1

headless

labels

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

coilyco-ops commented

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

Author

Member

DECISION - the agent/container/credential surface is IN scope as vulnerabilities: container escape, seeded-credential leakage, push-token scope violations, and audit-log gaps on the agent path. Agent drafts the new SECURITY.md bullets; Kai reviews at PR. Pairs with #483 (platform-qualified enforcement) and #452 (claim scoping). 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

coilyco-ops commented

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

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-451 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T02:50:40Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-451` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T02:50:40Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 02:56:14 +00:00

docs(security): scope the agent/container surface in vulnerability policy

coilysiren closed this issue

2026-07-02 02:56:14 +00:00

coilysiren commented

2026-07-02 02:57:18 +00:00

Owner

WARD-OUTCOME: done - SECURITY.md now scopes the ward agent/container surface (credential leakage, container escape, cross-repo credential bleed, telemetry/audit gaps) with an openshell threat-model link.

This one read bigger than it was. The framing sounded like threat-modeling, but the real job was matching the tone and specificity SECURITY.md already gave the dev-verb gate and mirroring it onto the agent surface. Front-loading the credentials, container-permissions, and observability docs paid off: the four attack categories nearly wrote themselves once I had the seeding, isolation, and redaction details in hand.

The one thing that actually fought back was the 4000-char markdown size cap. My first draft ran to ~4960 chars, so I trimmed it twice to fit while keeping all four bullets and the doc links. Terse-but-specific beat thorough-but-long, which is probably the honest house style for a root doc anyway.

Confidence is high: it is docs, not code, so there is no runtime to exercise, and the done condition (agent surface named with dev-verb-level specificity plus the openshell link) is met with a green pre-commit suite. One rough edge: SECURITY.md now sits at ~3994 chars, right against the cap, so the next addition will force another trim or a split into a docs/security-*.md file. If the scope grows again, splitting is the right call and worth a follow-up then.

WARD-OUTCOME: done - SECURITY.md now scopes the ward agent/container surface (credential leakage, container escape, cross-repo credential bleed, telemetry/audit gaps) with an openshell threat-model link. This one read bigger than it was. The framing sounded like threat-modeling, but the real job was matching the tone and specificity SECURITY.md already gave the dev-verb gate and mirroring it onto the agent surface. Front-loading the credentials, container-permissions, and observability docs paid off: the four attack categories nearly wrote themselves once I had the seeding, isolation, and redaction details in hand. The one thing that actually fought back was the 4000-char markdown size cap. My first draft ran to ~4960 chars, so I trimmed it twice to fit while keeping all four bullets and the doc links. Terse-but-specific beat thorough-but-long, which is probably the honest house style for a root doc anyway. Confidence is high: it is docs, not code, so there is no runtime to exercise, and the done condition (agent surface named with dev-verb-level specificity plus the openshell link) is met with a green pre-commit suite. One rough edge: SECURITY.md now sits at ~3994 chars, right against the cap, so the next addition will force another trim or a split into a docs/security-*.md file. If the scope grows again, splitting is the right call and worth a follow-up then.

coilyco-ops commented

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

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-451 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:55:16Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-451` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:55:16Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

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

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-451 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:55:16Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-451` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:55:16Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

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

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-451 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T07:55:16Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-451` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T07:55:16Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren commented

2026-07-02 07:56:56 +00:00

Owner

WARD-OUTCOME: done - SECURITY.md already scopes the ward agent/container surface (commit 90679b3 on main, closes #451); this run was a re-dispatch onto an already-closed issue and made no new changes.

Honest retro: there was nothing left to do. A prior run landed the exact deliverable in 90679b3 and closed this at 02:56 — SECURITY.md's vuln scope already names the agent/container surface with dev-verb-level specificity (credential leakage, container escape, cross-repo credential bleed, telemetry/audit gaps) and links docs/comparison-openshell.md as the threat-model reference. My container came up around 07:55 (reservation race in the burndown queue), found the tree clean with HEAD == origin/main and the done-condition fully met, so I deliberately did not manufacture a redundant commit. No rough edges beyond the one the prior run already flagged: SECURITY.md is sitting right against the ~4000-char markdown cap, so the next security-scope addition will force a trim or a split into docs/security-*.md. Worth a follow-up if the scope grows again.

WARD-OUTCOME: done - SECURITY.md already scopes the ward agent/container surface (commit 90679b3 on main, closes #451); this run was a re-dispatch onto an already-closed issue and made no new changes. Honest retro: there was nothing left to do. A prior run landed the exact deliverable in `90679b3` and closed this at 02:56 — SECURITY.md's vuln scope already names the agent/container surface with dev-verb-level specificity (credential leakage, container escape, cross-repo credential bleed, telemetry/audit gaps) and links `docs/comparison-openshell.md` as the threat-model reference. My container came up around 07:55 (reservation race in the burndown queue), found the tree clean with `HEAD == origin/main` and the done-condition fully met, so I deliberately did not manufacture a redundant commit. No rough edges beyond the one the prior run already flagged: SECURITY.md is sitting right against the ~4000-char markdown cap, so the next security-scope addition will force a trim or a split into `docs/security-*.md`. Worth a follow-up if the scope grows again.

Rows
Columns

SECURITY.md's vulnerability scope never mentions the ward agent/container/credential surface at all #451

Why

Deliverable

Done condition