Evaluate, and likely remove, trust gate feature #1487

New issue

Closed

opened 2026-07-21 00:56:21 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-07-21 00:56:21 +00:00

Owner

No description provided.

coilysiren referenced this issue

2026-07-21 00:59:21 +00:00

guided user level config setup #1486

coilyco-ops commented

2026-07-21 02:20:59 +00:00

Member

Field report for the evaluation, brew ward v0.775.0 on macOS.

The gate refused a legitimate owner today: warded director --agent claude with a coilyco scope in ~/.ward/config.yaml hit refusing untrusted owner "coilyco-flight-deck" (allowed: coilysiren) because WARD_CONFIG_REF was unset and the trusted-owner set came from the baked bundle instead of the live repos.kdl (which has trusted coilyco-flight-deck for a while).

Two observations for whichever way the evaluation lands:

The gate never blocked a hostile owner here, it blocked the fleet's own owner due to config-source drift. The failure mode in practice is a false positive with a confusing message, not a caught intrusion.
If the gate stays, the refusal should name the active config source and the lever. "This build dispatches only for its configured trusted owners" reads as compile-time policy, and docs/agent-trust-gate.md does not mention WARD_CONFIG_REF or where the owner set comes from. Something like "trusted owners from: baked defaults (set WARD_CONFIG_REF to use a live bundle)" would have made this a thirty-second fix.

Cross-ref: #1489 would remove the sharpest edge of this by making the bundle ref a config.yaml key.

Filed by Claude Code during a trust-gate debugging session with Kai.

Field report for the evaluation, brew ward v0.775.0 on macOS. The gate refused a legitimate owner today: `warded director --agent claude` with a coilyco scope in `~/.ward/config.yaml` hit `refusing untrusted owner "coilyco-flight-deck" (allowed: coilysiren)` because `WARD_CONFIG_REF` was unset and the trusted-owner set came from the baked bundle instead of the live repos.kdl (which has trusted `coilyco-flight-deck` for a while). Two observations for whichever way the evaluation lands: 1. The gate never blocked a hostile owner here, it blocked the fleet's own owner due to config-source drift. The failure mode in practice is a false positive with a confusing message, not a caught intrusion. 2. If the gate stays, the refusal should name the active config source and the lever. "This build dispatches only for its configured trusted owners" reads as compile-time policy, and docs/agent-trust-gate.md does not mention `WARD_CONFIG_REF` or where the owner set comes from. Something like "trusted owners from: baked defaults (set WARD_CONFIG_REF to use a live bundle)" would have made this a thirty-second fix. Cross-ref: #1489 would remove the sharpest edge of this by making the bundle ref a config.yaml key. Filed by Claude Code during a trust-gate debugging session with Kai.

coilyco-ops referenced this issue

2026-07-22 08:41:47 +00:00

Audit and remove remaining baked coilyco fleet configuration from ward #1498

coilyco-ops added the

autonomy

async-consult

priority

labels

2026-07-29 03:47:14 +00:00

coilyco-ops closed this issue

2026-07-29 05:59:32 +00:00