flex-auth/workplans/FLEX-WP-0025-fact-versus-assertion.md

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	depends_on_workplans	related_workplans	created	updated	state_hub_workstream_id
FLEX-WP-0025	workplan	A policy cannot tell a registry fact from a caller assertion	infotech	flex-auth	ready	claude	netkingdom	P1	250	FLEX-WP-0021	FLEX-WP-0022 FLEX-WP-0024	2026-09-07	2026-09-07	f9a657ce-67b4-5d25-9933-e0fcb2c20b1c

FLEX-WP-0025 — A policy cannot tell a registry fact from a caller assertion

Opened by FLEX-DEC-2026-012. That decision closed three verified privilege escalations by making registry facts win over caller-supplied attributes. It did not close the shape that produced them.

input.resource.attributes.max_ttl_hours reaches a Rego rule as one value in one map. Nothing in that input says whether the registry asserted it or the caller did. Precedence decides which value survives; it does not let a policy author require that a ceiling came from the registry at all.

The two residuals precedence did not close

1. A key the manifest omits is caller input. Registry facts win only where the registry has a value. A package branching on an attribute its manifest does not declare is reading the caller, and a manifest that stops declaring a key silently hands that key back. Registering the resource is not sufficient — the specific key must be present.

2. subject.type is two fields sharing a name. The registry's type is CARING vocabulary (Human, Agent, Automation, Service); the request's is the protected system's actor vocabulary (service, adm, agt, atm). Policies compare against the latter. Making the registry win here denied every secrets-engine allow, because "Service" is not "service", so the exception stands — and a caller can still assert its own subject.type while packages branch on it.

Note how the second surfaced: the registry's type had been dead data since the field existed, because the caller's value always won. A defect is invisible while the value it produces is never read.

1. Decide the shape

id: FLEX-WP-0025-T01
status: todo
priority: high
state_hub_task_id: "05c6a85d-ee3d-5875-bea4-e9a9c5382e2e"

Owner: flex-auth.

The obvious move is separate namespaces — input.resource.registry.* for facts and input.resource.asserted.* for caller input, with attributes retained as the merged view. That breaks no package on day one and lets a rule that enforces a ceiling opt into the fact side.

Weigh against it: a third view invites a package to read the merged one by habit, which is the status quo with extra steps. A stricter alternative is to stop merging at all and require packages to name a side, accepting a breaking change across six published packages.

Do not decide this from the shape alone. Read what the six packages actually branch on first, and write down which of their reads are ceilings or allowlists (must be facts), which are genuinely caller-proposed (ttl_hours, purpose), and which are ambiguous. The ambiguous set is the real design input.

Gate: the chosen shape is written down with the vocabulary collision addressed, before any package changes.

2. Audit every package for ceilings read from undeclared keys

id: FLEX-WP-0025-T02
status: todo
priority: high
state_hub_task_id: "fc61c8a7-347b-59d2-b6a6-a72c5c1cdb08"

Owner: flex-auth.

Mechanical and worth doing before T01 lands, because it is the live residual. For each published package, list every input.*.attributes.<key> read, and check the key is declared in the manifest for every resource that package can be asked about.

Any ceiling or allowlist read from a key the manifest does not declare is a live escalation of the FLEX-DEC-2026-012 shape. Fix by declaring the key, not by changing the rule.

Gate: a table of package × key × declared-in-manifest, with no ceiling or allowlist unbacked. Add it to docs/request-enrichment.md.

3. Make the review obligation enforceable rather than written

id: FLEX-WP-0025-T03
status: wait
priority: medium
state_hub_task_id: "8ee5baf9-b364-5d3e-9c49-d0c9eb014c10"

Owner: flex-auth.

docs/request-enrichment.md now says a policy enforcing a ceiling MUST read a key its manifest declares. A review obligation nothing checks is the shape FLEX-DEC-2026-008 was about.

Extend flex-auth validate to report attribute keys a package reads that its fixtures' registry never supplies. It cannot prove intent — it does not know which reads are ceilings — but it can surface every read that resolves only from caller input, which is the set a reviewer must look at.

Gate: the check runs in validate and flags a package whose ceiling key is undeclared, demonstrated against a deliberately broken fixture package.