A policy gate caches allow decisions keyed on listener name and port. Why did a listener that dropped to TLS 1.0 still get an allow?

## What a decision cache actually assumes Caching a policy decision is memoisation, and memoisation is only valid for a **pure function**. The function here is: `decide(input, rules, external data) -> allow | deny + reasons` A cache entry is a claim that if you call `decide` again with the same arguments you will get the same answer. That claim is only true if the key covers *all three* arguments. Almost every stale-decision incident is a key that covers fewer than three. ## The defect in this scenario Keying on listener name and port keys on **identity**, not on **content**. The identity of a listener is exactly the thing that does not change when someone weakens its TLS configuration — that is what identity means. So the gate looked up `public-api-443`, found an allow recorded earlier, and returned it without evaluating a single rule. The rule set was correct, the engine was healthy, the gate reported an excellent p99 (a cache hit is fast), and a non-compliant listener sailed through. From the on-call chair this is a particularly unpleasant shape of incident: nothing is red, nothing is slow, and nothing is alerting. The same defect appears in a subtler form when the key *is* a content digest but is computed over a **projection** — the trimmed input someone introduced to cut latency. If the projection was built for the key rather than derived from what the rules read, any field outside it is invisible. The lesson is to derive one projection, feed it to the engine, and hash *that same projected document*. Never hash a hand-written subset. ## The three parts of a sound key 1. **The exact input the engine evaluated.** Hash the bytes you actually sent, after projection, in a canonical form (stable key ordering, stable number formatting) so that a semantically identical document does not produce two different keys. 2. **The policy revision.** Rules change. If the revision is not in the key, tightening a rule leaves every previously cached allow valid, and the new rule takes effect only as old entries expire — which is precisely when nobody is watching. Putting the revision in the key means publishing a new one makes all prior entries unreachable, and rolling back reuses them. That is far more reliable than trying to enumerate and purge affected entries. 3. **The version of any external data.** If rules consult a list of approved settings or an ownership table, that data is an argument to the function. Version it and include the version. ## When you should not cache at all If the decision reads anything the key cannot see, it is not cacheable. The classic cases are a rule that consults the current time (an expiring exception, a change-freeze window) and a rule that performs a live lookup during evaluation. Both make `decide` impure: the same arguments legitimately yield different answers at different moments, and a cache turns that from a feature into a bug. Either remove the impurity — pass the time or the lookup result *in* as part of the input, so it becomes part of the key — or do not cache those decisions. ## Allow and deny are not symmetric A stale **allow** is a control failure. Something that your policy forbids passed the gate, and if the gate is the evidence that the control operated, that evidence is now false for the affected window. A stale **deny** is an availability failure: somebody fixed their listener and the gate keeps refusing it, which is infuriating but visible, self-reported within minutes, and harmless to your security posture. That asymmetry should show up in the design: shorter TTLs on allows than on denies, or caching only the expensive negative path, or not caching allows at all when the decision guards something exposed. It also decides your incident severity — the two look identical in a dashboard and are not remotely the same problem. ## TTL is a bound on damage, not a fix A tempting response to this incident is "we will shorten the TTL to five minutes". That does not fix a wrong key; it means a non-compliant listener is allowed for up to five minutes instead of forever, and it makes the defect look self-healing so nobody chases it. Fix the key. Keep a TTL afterwards as a bound on the things a correct key genuinely cannot observe — clock drift, an external data source you version imperfectly, an operator change nobody told you about. ## Catching this before an auditor does The cheap control is **out-of-band sampling**: periodically take a small random slice of cached allows, re-evaluate them fresh away from the request path, and alert on any disagreement between the fresh answer and the cached one. It costs a fraction of full evaluation, it is not on anyone's latency budget, and it catches key defects, stale external data and policy-version bugs as a single class. Sizing the exposure window afterwards is then a question your logs can answer, which is the difference between a two-line incident note and a very bad conversation.