docs(security): record Loki's unbounded volume, and test the control (#189)

[Gerrrt]

Closes #189 via its option 3, and adds the test that option 3 turns out to depend on.

Why this option

The issue's own conclusion, followed through: option 1 (authenticate the ingest ports) is the real answer, and it is #182's entire scope — both ports, every pushing Alloy agent, a credential to distribute and rotate. Doing it here would close #182 by accident with #189's narrower framing as the record of why. Option 2 bounds the blast radius without bounding the volume, and it is a host/LVM change that buys more of the thing there is most of: 53 GiB free against ~22 MB/day.

So: record it, and make #182's second justification explicit.

What SECURITY.md gains

A row in the exposure table beside the existing Prometheus/Loki residual, and a section carrying the part that was only ever in the issue:

Rate limits are the obvious response and they do not solve it. The lab produces roughly 0.012 MB/s of logs, so even a deliberately tight 0.5 MB/s ingestion_rate_mb is 40x headroom — and 0.5 MB/s still fills 59 GiB inside a day and a half. Any limit loose enough not to drop real logs is loose enough to fill the disk.

That is the durable half. Without it the next person notices the gap, reaches for ingestion_rate_mb, and calls it fixed.

The measured position is recorded too — 461 MB on 2026-08-31, 549 MB on 2026-09-04 — so drift is distinguishable from noise later without re-deriving the rate. Unbounded is a different property from close.

The control had no test

HostDiskWillFillIn24h is the whole control under this option. host.rules.yaml had no test file at all, so it was as unverified as ContainerCpuThrottled was in #185 — and for the same reason nobody noticed.

It is not in #185's position, though: node_filesystem_avail_bytes and node_filesystem_size_bytes report for prometheus, oracle and Saruman right now, so the input exists and the only question was whether the expression handles it.

host.test.yaml answers that with three cases and mutation testing:

Mutation	Caught by
Drop the predictive half (becomes a static <30% threshold)	the full-but-stable case
Drop the 30% guard (predictive half alone)	the roomy-but-filling case
Invert the prediction's sign	the firing case

Two corrections from doing it

• My first mutation run reported two of the three "not caught", and it was wrong. The replacement text did not match the file verbatim, so promtool ran against an unmodified rule and passed. A mutation test that does not mutate looks exactly like a rule that cannot be broken — worth knowing, since that is the failure mode this whole class of test exists to prevent.
• Once applied properly, the 30%-guard mutation genuinely was not caught. The roomy-but-filling case evaluated at 2h, which is precisely when the alert would first fire without the guard, so it reported silence either way. Moved to 4h, and the comment in the file says why so nobody "tidies" it back.

Checks

validate.sh — 48 PASS, 0 FAIL, 2 SKIP. promtool test rules now covers 10 files in observability, up from 9. yamllint caught a 162-char annotation line, and check_docs.py caught the coverage counts moving (28→29 tested, 28→27 not) — the third time that sentence has shifted this week, and the third time the guard from #212 caught it rather than a person.

🤖 Generated with Claude Code