SRI Can't Pin the Adform Ad Tag Rewriting Wallet Addresses

The removal ladder, and what each rung costs

Of the four, the static pod removal has the cleanest rationale. Static pods start before the API server is necessarily reachable. Referencing API-server-sourced config from them was always an ordering race, and the kubelet papered over it. Removing it forces the honest design: config on disk, delivered by the node provisioning path. The cgroup item is the one that hurts quietly. CPU throttling and memory accounting behave differently after the switch, so migrate one node pool in staging and measure p99 latency and OOM-kill rate before and after, not after a customer notices.

Reconciler reads never touch the API server

The other item in the same reporting is a bug class, not a deadline. Here is what actually happens when the controller-runtime manager starts: it fills a local store with list calls, then keeps it fresh with watches. These are the same Reflector, DeltaFIFO and Indexer primitives that run Kubernetes itself. Reads go to that store. Writes go straight to the API server. So r.Get() and r.List() are eventually consistent, and the sequence create child → list to confirm it exists → create again because it does not is a documented way to duplicate resources in production.

The levers are unglamorous and cheap. Register field indexes through GetFieldIndexer().IndexField and query with MatchingFields. Scope the cache by namespace or label selector. Strip managedFields in a DefaultTransform. Then drop read-after-write verification entirely and use requeue-based level reconciliation, which is what the framework was designed around anyway.

Cache scope is a blast-radius decision, not a default

One lever deserves separating out, because it connects to the day's other thread. Disabling the cache for Secrets stops an operator holding every Secret in the cluster in its heap. That is a memory bill and a credential blast radius, closed in one line of manager config. It is the identical mistake the day's security reporting flags in agent runtimes: a long-lived process holding far more credential material than any single task needs. An operator that caches all Secrets does exactly that, with none of the attention.

Cache scope and index choice are your controller's memory bill and its credential blast radius at the same time; treat both as a capacity decision, not a framework default.

Neither failure announces itself as a cache problem. Unindexed list calls surface as mystery memory growth and rising reconcile latency. Read-after-write surfaces as duplicate child objects. Teams misattribute both to the API server for months before anyone reads the manager options.

The variant that is worse than a refusal

A flat refusal at least leaves an artifact in the response body. You can grep for it. The behaviour that actually breaks forensics work is silent sanitization: the model paraphrases the payload, drops the offending bytes, and summarizes around the evidence. The output is well-formed and plausible. It has also quietly lost chain of custody with the artifact. That is not degraded analysis. It is corrupted analysis, and nobody finds out until someone re-derives the finding by hand. Every log-triage, crash-dump summarization, abuse-review and user-upload pipeline that treats model output as evidence rather than as a hint inherits this.

The second problem is dependency control. Refusal thresholds live in the weights and in the provider's policy layer, and both move when a provider swaps the model behind a stable alias. The code did not change. The prompts did not change. The pipeline broke anyway, on the provider's release schedule, with no changelog anyone is entitled to. A production config that still reads -latest is an unreviewed third-party dependency upgrade landing in a critical path.

Picking a tier for adversarial content

Read what the table does not claim. Open-weight models are not better. They are less likely to refuse, and for security and abuse workloads that single property outranks raw capability. A slightly worse answer beats a courteous non-answer at 3am.

Where two sources land on the same architecture for different reasons

The resilience argument says self-host because you own the refusal policy and the evidence path. The separate portability argument in the same reporting arrives at an identical build for an unrelated reason. Mirror open-weight artifacts to internal object storage. Keep an OpenAI-compatible inference seam. Treat the eval suite as a contract test, so regulatory noise around a specific model family becomes a config change rather than a quarter of work. Same seam, two independent drivers. That convergence is the strongest reason to fund it. The investment pays off whether the trigger is a mid-incident refusal or a provider you can no longer ship.

Implementation is days, not a research program. Classify responses for refusal patterns and emit that as a distinct metric, not an error count. Alert on rate change, because refusal rate drifting up is the only visible signal that a provider changed the model. Use the trip as the fallback routing condition. Then build a refusal regression corpus: obfuscated JavaScript, base64 and hex payloads, ransom-note text, exploit strings, PII-dense log samples. Gate model version promotions on it in CI. Run shadow traffic through the fallback so it is never cold when you need it.

Retries fire on 5xx, backoff fires on 429, circuit breakers trip on timeouts, and a refusal trips none of them. It is the one failure the platform has to be taught to see.