[ViperJuice]

Planning artifact only — no src/ or test change. Plans the remainder of #231 (see #231); S-09 is already fixed in #281 and is untouched.

The S-10 decision inverts the obvious fix, and that is the point

The obvious remedy is "make the metadata route call _host_rejected like handle_mcp does." That fails open in the default configuration. _host_rejected returns False when allowed_origins is None — the local-first default — so rejecting-outright would still reflect an attacker-supplied Host in exactly the deployment most users run. I verified this against transport/http.py.

The plan instead returns a non-Host-derived resource: the operator-configured audience when set, else the metadata-URL origin. That fixes it unconditionally rather than only when an allowlist happens to be configured.

On the #211 constraint I asked the planner to check: #211 (56a555c, "stop vouching for URLs a downstream server supplied") did not touch this handler — the Host-derived value predates it. #211 is a principle: never advertise an attacker-supplied value as vouched-for, remedied there by relay-but-mark-unverified. This fix is stronger, because the untrusted Host is never emitted at all, so no "verified" implication can be reintroduced.

One characterisation I'd soften: the plan says the metadata path "violated" the existing SECURITY.md claim. That sentence is specifically about the audience being bound to the operator-configured canonical resource and never Host-derived; the metadata resource field is a related but distinct value. The fix aligns them, which is good — but I'd call it an inconsistency in spirit rather than a claim violation.

S-07 — why not the two obvious options

• Not a per-kid negative cache: random kids defeat it, since every new one is unknown by construction. That is precisely the attacker's input.
• Not "move rate limiting ahead of auth": rate limiting is per-IP and only active when rate_limit_rpm > 0, so it bounds nothing in the default config.

Instead: a global forced-refresh cooldown (default 10 s). The first unknown kid per window still forces one refresh, so a legitimate key rotation is picked up within one window (10 s ≪ the 300 s TTL) and can never be locked out — that was the fail-closed-in-the-wrong-direction risk I asked about. A kid unknown during an active window gets a transient, self-healing 401.

S-08 — the timeout is the lock-hold bound

A total ClientTimeout (default 5 s), not connect-only, because a slow-drip body under the size cap must also be bounded. _fetch runs entirely inside get()'s _refresh_lock, so bounding _fetch bounds every waiter. On timeout the cache is untouched: waiters serve stale-valid keys if present, else 503.

All three measured red on the current tree

Finding	Measured failure
S-07	"unknown kids each forced a fetch: calls=3"
S-08	hung to the 8 s outer bound (wall-time 8.20 s) — no internal timeout
S-10	resource='http://evil.example/mcp' — the forged Host reflected

Each has a named post-fix mutation for the implementer. The probe was deleted and the tree left clean.

Stated as unconfirmed

No SECURITY.md ledger claim ID covers the metadata resource field; the relevant prose is uncited. The plan instructs the implementer to run check_security_claims.py after any SECURITY.md edit and to add a [C-NN] citation only alongside a matching real test node.

check_security_claims.py OK (129 cited ids); check_plan_consistency.py 0 blocking.

🤖 Generated with Claude Code

https://claude.ai/code/session_013G8iK4noj1iNbSTqJVFEX6

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}