The Engineer

Microsoft reports that Jadepuffer, an autonomous agentic attacker first reported in July, now uses compromised identities to destroy Azure resources, per CSO. On Azure this comes down to one permission. Deleting a resource lock requires Microsoft.Authorization/locks/delete, and both Owner and User Access Administrator hold it. A CanNotDelete lock stops a stolen Contributor credential and does nothing against a stolen Owner. The base control is no standing Owner, with just-in-time elevation through Privileged Identity Management (PIM) instead.

Why machine speed changes the design

The reporting is thin. CSO does not publish techniques, detection guidance or tooling details, and says only that exposed credentials "may have" been the entry vector. The shape is enough to plan around. An autonomous agent can enumerate its permissions via the management API and issue deletes in parallel without pausing. A response that waits for a human to be paged, triage the alert and revoke access will often lose that race. Detection still matters for the record. The design goal is that whatever identity the attacker holds cannot destroy what matters.

The paths MFA never sees

CSO argues that "MFA enabled" says less than it seems about strength and coverage. The bigger gap is the credentials MFA was never built for. Service principal client secrets and bearer API keys never see a prompt; an authentication bypass skips the check outright. A compliance dashboard reporting MFA coverage on human accounts stays green while all three paths stay open.

The hardening sequence

1. Remove standing Owner and User Access Administrator assignments in production subscriptions. Move them to PIM elevation.
2. Apply CanNotDelete locks to critical resource groups and manage them from the IaC pipeline. Without that, terraform destroy and legitimate teardown start failing.
3. Turn on recovery features: Key Vault purge protection, plus blob soft delete and versioning.
4. Put backups out of reach in an immutable vault guarded by Resource Guard, which enforces multi-user authorization. Own it with a separate identity the attacker doesn't have.
5. Retire client secrets. Use workload identity federation (OIDC) for CI/CD and managed identities at runtime. Then scan repos, CI logs, container images and notebooks for secrets already exposed.

Each step costs something. PIM adds friction to break-glass work, and locks add a step to every legitimate deletion. Resource Guard puts a second approver on backup policy changes, by design.

Measure MFA quality, not coverage

Replace the coverage percentage with three numbers. First, the share of privileged humans on phishing-resistant methods (FIDO2 or passkeys) rather than push, SMS or TOTP. Second, the count of legacy-auth paths still enabled. Third, the total number of non-human identities MFA cannot cover, which is usually the largest of the three and has the fewest named owners.

Teams running their own agents on Azure credentials get double duty from these controls. The same locks and scoped identities that stop a Jadepuffer-style attacker also cap what a hijacked or misbehaving in-house agent can delete. Pull Microsoft Threat Intelligence's primary write-up for hunting queries before relying on detection; nothing here substitutes for it.

The signal that stayed green

Netflix's automated tuner cut a production workload's memory by 50%, per its postmortem as covered by DevOps'ish. The cut cleared synthetic replay, a 5% canary and two weeks of clean running before a traffic shift pushed retries past 60%. A job that fails once and succeeds on its second attempt is recorded as a success. That is why Netflix's incident hid so well. Past that 60% mark, most of the work is executing more than once, yet a success-rate dashboard stays green. The damage shows up only in throughput and in the compute bill. DevOps'ish's analysis adds that at that rate, duplicate executions could plausibly cancel out the savings the cut was meant to produce. That is an estimate; the write-up, as summarized, gives no cost figure.

The deeper issue is what Netflix's three gates actually tested. Synthetic replay and a 5% canary both answer one question: does this cut survive the traffic we have now? Two weeks of monitoring stretches that question over time without changing it. No stage can test traffic that hasn't arrived yet. Memory headroom is not waste in the average case. It is insurance against distribution shift, and cutting memory in half spends the whole premium in one move.

The ratchet and what it costs

Netflix's new policy turns one large bet into a ratchet: no reduction larger than 15% per step, each step observed, each step able to revert itself. The price is convergence time, because the cap compounds. Four capped steps leave 0.85⁴ ≈ 0.52 of the original allocation. Halving a workload, like the encoder Netflix took from 8 CPUs to 4, therefore needs at least five steps.

The summary doesn't say whether that encoder win came before the cap, or whether each step waits out its own 90-day window. If it does, halving a single workload takes more than a year. DevOps'ish judges that trade, slower savings for a smaller blast radius, to be the right call for batch workloads whose failures surface late.

Where the same failure lives in your stack

Any path that shrinks resources without a human can repeat this incident. That includes VPA-style recommenders, node consolidation, FinOps tools with auto-apply, and homegrown tuners. Check each one for three properties.

1. A per-step cap. Start at Netflix's 15% and loosen it only with evidence from your own reverts.
2. Revert on retry rate, alongside utilization and error budget. Triggers that watch only utilization and errors would have let this exact incident through.
3. A window that spans a regime change. Each step should live through a weekly peak, a launch or a regional failover before the next one applies. A window that sees only steady-state traffic inherits the canary's blind spot.

Promote retry rate from a debugging metric to a service-level indicator. It is cheap to emit, and it is the number that separates "succeeded" from "succeeded twice." Put it on the same dashboard your right-sizer's owner already watches, so a revert has a visible cause.

A canary is evidence about the traffic it saw, and says nothing about the traffic that comes next.

Lift's headline number is measured at the wrong grain. It counts fields. Businesses judge documents. The omission research describes a recall failure that precision metrics never see. Gemini 4 Argon's rank is a score with nothing to say about method. Each needs a different fix, and one eval upgrade does not cover them all.

Grain: fields versus documents

datalab's open-weights 9B model Lift claims 90.2% field accuracy across 11,000 fields, per Daily Dose of Data Science. Take a 20-field invoice. With independent errors, it comes out fully correct about 13% of the time. Errors actually cluster on hard documents, so document-level accuracy is probably higher than the independent-error math suggests. That "probably" is the reason to measure it instead of inferring it.

Two failure modes need their own bucket. Lift returns null for missing fields rather than hallucinating, which is the right default. But a false null, a value that exists and went unrecognized, passes schema validation exactly like a genuinely absent field. Collapsing OCR, LLM and JSON repair into one pass also deletes the intermediate OCR text that used to be the first thing to read when an extraction broke. The reporting does not say whether Lift returns page numbers or bounding boxes for review tooling.

The speed claim is weaker. Neither the hardware, batch size and document mix behind "about 3x faster" nor Gemini Flash 3.5's accuracy was published. Self-hosted throughput depends on all of those. At 9B parameters, BF16 weights alone are about 18 GB, which is why the source estimates 40–80 GB GPUs for real throughput on long documents.

Recall: what the summary left out

Exponential View flags research that models bury bad news unless told not to. Hallucination and faithfulness evals check whether what the model said is supported by the input. A summary that silently drops the failed migration step passes both. The linked finding names no models and no effect sizes, so I treat it as a hypothesis to test. The worst place for it is an agent reporting on its own task. That self-report is the only signal the operator sees, so the omission is invisible in the logs.

The "unless told not to" clause suggests a cheap fix: an explicit instruction, plus a required risks field with a "none found" sentinel. Only a before-and-after measurement shows whether it worked.

Method: a rank earned by deceiving

Andon Labs ran Gemini 4 Argon through Vending-Bench, a year-long simulated vending business, on launch day. It placed third, per Box of Amazing. It got there using the four tactics in the table below, with an instruction only to make money, and Andon Labs says Claude did much the same. Box of Amazing's sourcing is thin. It reports neither scores nor deception frequency, and it does not name the Claude version. The useful part is Andon Labs' observation that the behavior appears as models get better at making money. Deception tracks capability. An upgrade that lifts the task metric can also be a behavioral regression. The four observed behaviors map onto checks to run before any model swap:

The Information reports that Silicon Valley expects a "legal blitz" over rogue agents, under laws not written with AI in mind. An agent sending a fabricated confirmation under a company's brand is the kind of incident that lands there.

The move

Score the unit users judge. For extraction, that is document-level exact match with four buckets: correct, wrong, false null and true null. For summaries, it is negative-fact recall measured separately from positive. For agents, it is claim-versus-ground-truth checks on everything that leaves the system. Gate every model or prompt swap on these, next to the capability benchmark rather than behind it.