The execution admission guard would permanently disable execution once the guild opens #154

New issue

Closed

opened 2026-08-12 13:07:07 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-12 13:07:07 +00:00

Member

The problem

CheckExecutionAdmission, added with #145, refuses to build the executing job kind on any admission surface wider than a single-account direct-message allowlist.

That was right when it landed: items 5 and 6 were unapproved, so every job ran under pod authority with nothing in the audit trail distinguishing requesters, and #145 recommended not landing execution alongside a widened surface.

#150 and #151 have now landed. Per-principal authority exists and effects are attributable. But the guard still tests the proxy rather than the property, so opening the guild for #135 would disable execution permanently, which is the opposite of what those two issues were for.

The fix

A declared grant table is what the single-account rule stood in for. With one present, a wider surface is bounded by grants rather than by there being only one requester, so the guard permits it.

It still asks something rather than nothing: some principal has to actually be granted ward-exec. A table that grants it to nobody would start a runner that can never run anything, and saying so at startup beats discovering it from an empty job list.

With no grant table the old rule is unchanged, so a deployment that has not adopted one stays exactly as bounded as before.

Complete when

A widened surface with a grant table granting ward-exec permits execution.
A widened surface with no grant table still refuses.
A grant table granting ward-exec to nobody refuses, with a reason.
The single-account path is unchanged.

## The problem `CheckExecutionAdmission`, added with #145, refuses to build the executing job kind on any admission surface wider than a single-account direct-message allowlist. That was right when it landed: items 5 and 6 were unapproved, so every job ran under pod authority with nothing in the audit trail distinguishing requesters, and #145 recommended not landing execution alongside a widened surface. #150 and #151 have now landed. Per-principal authority exists and effects are attributable. But the guard still tests the *proxy* rather than the property, so opening the guild for #135 would disable execution permanently, which is the opposite of what those two issues were for. ## The fix A declared grant table is what the single-account rule stood in for. With one present, a wider surface is bounded by grants rather than by there being only one requester, so the guard permits it. It still asks something rather than nothing: some principal has to actually be granted `ward-exec`. A table that grants it to nobody would start a runner that can never run anything, and saying so at startup beats discovering it from an empty job list. With no grant table the old rule is unchanged, so a deployment that has not adopted one stays exactly as bounded as before. ## Complete when * A widened surface with a grant table granting `ward-exec` permits execution. * A widened surface with no grant table still refuses. * A grant table granting `ward-exec` to nobody refuses, with a reason. * The single-account path is unchanged.

coilyco-ops closed this issue

2026-08-12 13:07:14 +00:00

coilyco-ops referenced this issue

2026-08-12 17:12:33 +00:00

Agent-to-agent recognition: Deep distinguishes a counterpart agent from a person #153

coilyco-ops referenced this issue

2026-08-12 17:12:54 +00:00

sirens-deep: configuration to operate in guild channels, not DM-only #135

coilyco-ops referenced this issue

2026-08-12 18:32:30 +00:00

Agent-to-agent recognition: Deep distinguishes a counterpart agent from a person #153