The Watch

The NetScaler hunt window

Sequence decides the workload. Attack details leaked, exploitation began, and some organizations took NetScaler gateways offline before Citrix had a fix to install, Risky Business reports. Any appliance that stayed internet-facing through that stretch was exposed with nothing to apply. The weekend build closes new exploitation on those boxes; anything planted before it landed is still resident.

Hence the recommended order: patch first, then hunt. The hunt looks for rogue sessions, configuration changes and webshells on every ADC and Gateway appliance that was exposed and unpatched. Risky Business published no indicators of compromise and no attribution. That puts the hunt on behavior and baselines rather than signatures.

Mitigations that stayed in place

Oracle PeopleSoft is the case study. Oracle patched a June zero-day. Some customers deployed firewall-rule mitigations instead of the patch. ShinyHunters has resumed attacks by getting around those rules. A firewall rule covers the path the defender expected. The vulnerable code is still reachable by other paths, and ShinyHunters found one.

SRE Weekly arrives at the same conclusion from the reliability side. Rolling back a deploy does not erase state that has already spread into caches, queues and downstream consumers. The piece cites a CircleCI example and the Skyliner essay “You Can't Have a Rollback Button.” Substitute “malicious deploy” for “bad deploy” and the security reading is direct: reverting the code leaves stolen secrets, issued tokens and queued jobs alive.

Applying the rollback lesson to intrusions is our inference. The reliability authors wrote about outages. The logic carries over cleanly. A rollback and a patch both act on the next request, not on the tokens already issued.

Risky Business's recommended order is patch first, then hunt for rogue sessions, configuration changes and webshells.

What changes in the vulnerability program

Most vulnerability programs accept “patched” or “mitigated” as a closed status. That is how WAF and ACL exceptions survive for quarters. It is also how a gateway compromised on Saturday shows green on Monday. Two rules close that gap.

First, any period in which an asset was exposed and unpatched should open a hunt ticket alongside the patch ticket. Second, containment ends with eviction rather than with the fix. SRE Weekly's checklist is the template:

• Rotate secrets the affected system could reach.
• Revoke sessions and OAuth grants.
• Purge caches.
• Drain or quarantine queues.
• Notify downstream consumers.

Exposure length sets the order. Internet-facing NetScaler appliances left unpatched over the weekend carry the longest window. PeopleSoft instances still protected only by firewall rules come next. Then every other register entry whose status reads “blocked at the WAF.”

One step now carries the whole burden

TheSequence's editorial on the Opus 5.5 launch includes its own caveat. Overnight codebase migrations work “as long as the results survive review.” That clause puts the entire security burden on one step. A job that runs overnight runs with nobody watching, so the reviewer the next morning is the only control left. Simplifying AI reads the launch the same way. It predicts more AI-written code per reviewer hour and names review capacity as the new bottleneck.

Architecture Notes shows practitioners designing around that bottleneck rather than fixing it. Fatih Arslan's pattern keeps Markdown plans in a shared Git repo, sorted into draft, queued, active and completed folders. Long-running coordinator agents maintain the index. That makes the plan repo an instruction channel: anyone who can write to the queued folder can give your agents tasks.

Agent Substrate, one of the agent runtimes the same issue profiles, adds a related trap. It keeps agent memory and filesystem state when an agent is suspended and resumed, so poisoned context survives a restart. Restarting a compromised agent is the same stand-in as rolling back a compromised deploy.

Your code is the hard case

Vendor benchmarks overstate how well agents handle code they haven't memorized. TheSequence reports that human checks found leakage in more than 65% of SWE-bench Verified instances. Researchers also tested functionality-preserving transforms, which are rewrites that keep behavior the same but change names and layout. Pass@1 fell by 6.0 to 14.4 points. Input tokens rose more than 2.5x, because agents spent most of their extra actions exploring. Your proprietary repository is, by definition, the transformed case.

Judgment lags even further behind. Taste-Bench tests long-horizon decision points, and its best score is 59.7%, from GPT-5.6 Sol. Longer horizons score worse, and a bigger reasoning budget doesn't help. An overnight migration is exactly that long-horizon case, run unattended against unfamiliar code. These are research benchmarks, not incident data. None of the reporting reviewed here describes a breach caused by an unreviewed agent change.

An approval on a pull request that no human read is change management on paper only.

What changes for your program

The realistic failure isn't a dramatic exploit. It is a prompt-injected or confused agent landing a change that no human ever reads, in a repo your SOC 2 CC8.1 evidence says is under change control.

A second drift makes it worse. Simplifying AI reports that HarnessRouter puts Codex, Claude Code, Hermes and DeepSeek Harness behind one OpenAI Responses-compatible API. The vendor that sees your source code becomes a configuration setting that procurement never reviews.

Architecture Notes doesn't argue for reviewing everything. It argues for tiered review: human approval on paths where one bad line is a breach, and free agent merges everywhere else. Brad Murry's orchestration work adds a quieter control through three features of his reactive-reducer design:

• Declared transitions act as an allow-list for an agent's next move.
• Retry budgets cap runaway loops.
• Durable typed state gives incident responders a record to reconstruct from.

Start by measuring. Most teams can't say what share of production merges an agent wrote and nobody read. Until you have that number, your change-control attestation is a guess.