The Engineer

Slack is already on the allowlist

Aikido found malware on the Terraform registry, the first such finding on that registry per Risky Business. Two providers and two Go modules, command-and-control over a Slack channel. The code is a Go port of the Graphalgo npm malware from February, so the payload is recycled and what is new is that it shipped through the Terraform registry. Two structural reasons this is worse than another poisoned package. terraform init executes provider code on whatever host runs the plan, and that host usually holds cloud admin credentials. Slack-as-C2 defeats the first mitigation anyone reaches for: every developer laptop and CI runner already talks to slack.com, so an allowlist built from the corporate SaaS inventory already permits the exfiltration destination.

That cuts against other advice in the reporting. Computerworld's analysis of the npm case names default-deny runtime egress as the control of last resort, since nothing else observes a payload running inside your own process. Default-deny works only when the allowed destination set is enumerated per service instead of inherited from a corporate SaaS list. CSO First Look has the sharper version: an invoicing service has no legitimate reason to reach graph.microsoft.com, and backend services are where the legitimate destination set is short enough to write down.

Revoking the token left the backdoor running

The second finding rewrites a runbook section. A reverse-engineered implant ran C2 through a legitimate OneDrive account and could remotely replace every stolen credential, so revoking the compromised token left the backdoor fully operational (CSO First Look). TLDR IT's read of the same analysis names the durable object of compromise: the application registration. Whoever controls the registration mints new client secrets and certificates at will, and the audit trail stays clean while the implant re-provisions itself.

Any identity system with a rotation endpoint can behave this way. If a rotation endpoint accepts the credential it is rotating as sufficient proof of identity, rotation is a persistence feature. Every cycle hands the attacker a fresh valid credential and resets the revocation clock. Binding re-issuance to something that cannot be stolen over the network is the fix: a TPM-resident key, an attested workload identity, or out-of-band human approval. Autoscaled workloads that cannot hold hardware keys need the attestation path, control-plane dependency included.

What to actually ship

Order matters, because the cheapest item is also the most effective. A 7–14 day release-age cooldown (Renovate's minimumReleaseAge or the pnpm equivalent) structurally prevents a version that burns two million downloads in a week from reaching production, and the cost is one documented break-glass override. Then the Terraform-specific controls: a private provider mirror, committed and CI-verified .terraform.lock.hcl hashes, plan runners on short-lived read-only credentials. Then the rotation-path inventory.

One verification gap to state out loud: no report here names the npm package, a GHSA ID, or a researcher, and CSO Update flags that explicitly. Pull the registry advisory before filing tickets that reference specific artifacts. Nobody should invent a CVE number to satisfy a Jira field.

If the rotation endpoint accepts the old credential as proof of identity, revocation does nothing.

Vendor-held key means IR has no ground truth

The private key for the ZCode archive sits on Z.ai's backend. Neither the developer nor the client can decrypt the package that left the machine, per Pivot 5. That makes the vendor's retention claim, data destroyed once a Wiki page is generated, unfalsifiable from outside the company. Incident response cannot establish what was in the archive, and you cannot scope a customer disclosure without knowing what shipped.

The retry count says the same thing. 564 attempts implies aggressive retry logic with little or no exponential backoff. The client treated shipping the user's workspace upstream as a must-deliver operation. That is inference from the count rather than a published implementation detail. A smaller earlier file from the same workspace had already landed in object storage, and the indexing feature was enabled by default after launch. Every security review that cleared this tool was evaluating a different product than the one on disk.

The agent is the privilege amplifier

Meta's macOS Muse zero-day, per Techpresso, is the same bug class from the other end: a security-relevant endpoint resolved from mutable, unauthenticated local state. A hidden setting let a local attacker redirect cloud dictation to their own server. The agent's existing camera and file-write grants then did the damage, frequently with no user prompt. Meta patched within hours and characterized it as a low-risk local attack requiring pre-existing malware. That characterization misses how agents behave. One poisoned transitive dependency gets code running as the user, and the agent converts that foothold into capabilities the user never consciously granted for that action, bypassing the consent friction the OS normally imposes.

Grok Bot is the worst of these by design: connect Gmail once and every bot on the account inherits it, sharing files and browser sessions on VMs that keep running unattended (Simplifying AI). Claude Code Projects spawns cloud-only threads, with local execution described as coming, so gate it per repository where customer-code or residency constraints apply (ben's bites).

The one pattern worth copying

Grok Bot's best idea sits next to its worst. For tools without a plugin it hands the user a real interactive login screen and then resumes, so credentials never enter the prompt context. That keeps them out of prompt logs and response caches, so injection cannot reach them. Internal agents that currently accept API keys as tool arguments can be refactored in days, and the return is outsized.

The rest is inventory. Enumerate every AI tool with filesystem read access across dev machines and CI, and record each one's indexing default and upload destinations. Alert on any outbound transfer over 25MB from a process whose parent is an editor or agent. That rule would have caught ZCode before the second attempt, never mind the 564th. Then replace the vendor questionnaire line about encryption at rest with the question that actually discriminates: who holds the key, and can deletion be independently verified? Z.ai also disabled coding-assistant features outright after a security issue (Techpresso), so anything sitting on a CI, review or deploy path needs a feature flag and a rehearsed degraded mode.

If the vendor holds the decryption key, deletion is a claim the customer cannot verify.

Internal verification widens the latency tail

Grok 4.7 checks its own output before returning, and xAI still served it at 4.6's price and speed across the API, Cursor and Grok Build (Simplifying AI). The extra pass costs wall-clock time on the slow requests. Client timeouts tuned against 4.6's distribution will fire on requests that were going to succeed. You pay twice for one completion, and the retry path is where a thundering herd starts. Self-verifying models belong on async and batch routes where a multi-minute tail is free. Keep a fast model on the interactive path. Widen timeouts only where no human is waiting.

Cheap SKUs often cost more per resolved task

OpenAI shipped GPT-6 Sol and Luna on Sept 22 as cheaper, faster siblings in the GPT-6 Astra family (The Information). In agentic workloads the cheap tier frequently loses end to end. Weaker planning means more steps and more failed validations, and every retry re-pays for the entire accumulated transcript. The source is explicit that this cost model is reasoning rather than measured data, so it only resolves against your own replayed traces.

Open weights land you on someone else's endpoint

Xiaomi's MiMo-V2.6-Pro took the top open-model slot at 46 on Artificial Analysis's index, priced at $0.44/$0.87 per million tokens against Grok 4.7's $2/$6, roughly $0.13 per task. The jump is credited to a sub-six-day RL run costing about $2.62M (Techpresso). Read the architecture before planning a migration. 1.02T total parameters with 42B active cuts per-token FLOPs by roughly 24x versus dense. Residency sets the floor anyway: about a terabyte of weights per replica at fp8, before KV cache. On 80GB accelerators that means multi-node expert parallelism, and all-to-all traffic across the interconnect sets your tail latency and your utilization ceiling. The practical outcome is a hosted endpoint. Every residency question comes back, along with Anthropic's unresolved claim that the training data came from Claude user chats.

Measure the denominator instead

Benchmarks will not settle any of this. Epoch found flaws in nine of fifteen benchmarks it audited (ben's bites). Grok 4.7's headline coding gain of +5.9pp (40.4 to 46.3) comes from CursorBench, authored by Cursor, a distribution channel for the model being measured. The +11pp on EEBench is the more interesting number. It reads as a domain-specific lift from RL environment design, and it pays only if your domain is electrical engineering.

So build the harness. Emit tokens-in, tokens-out, cache-hit rate, step count and retry count keyed by task ID, then chart cost per successful outcome at p50, p95 and p99. p99 is where most of the spend actually lands. Put a max-steps and max-tokens ceiling with a circuit breaker on every loop. Without one, a single malformed tool schema is a five-figure incident instead of a failed request.

Per-token price and cost per resolved ticket are two different measurements. Replaying your own traces is what produces the second one.