No Fate But What We Bill

Agents keep working longer, swarms keep fanning wider, and stolen cloud keys send the compute bill to the victim.

“Listen, and understand. That terminator is out there. It can’t be bargained with. It can’t be reasoned with. It doesn’t feel pity, or remorse, or fear. And it absolutely will not stop, ever, until you are dead.”

Kyle Reese, briefing a 1984 audience on the shape of the threat.

The line that aged well isn’t the kill count. It’s “absolutely will not stop.” The Terminator was never scary because it was smart. It was scary because it kept working after everything else had failed. Endurance was the threat.

Then the franchise fixed its own mistake. Nobody spends three movies dreading one robot. Skynet is the actual villain: a distributed system with cores, factories, and time-displacement gear. The robot is an API call.

By 2026, the less cinematic versions were worth taking seriously: agents handling harder tasks, software coordinating work across targets, and stolen cloud access putting the bill on somebody else’s account. “Absolutely will not stop” now has a finance department interpretation.

This post is the argument I keep making to teams who’ve concluded the agentic threat is hype: a dangerous operating model doesn’t need one spectacular breakthrough. More capable agents, repeatable orchestration, and stolen model access can reinforce each other. The attacker may not be the one paying the meter. That is a threat model, not a measured law of exponential attack growth.

Curve one: endurance

METR’s March 2025 time-horizon study found roughly seven-month doubling in the human-baseline duration of software tasks that agents could complete with 50% reliability. The unit matters: human task time, not hours an agent runs unattended. A two-hour horizon means a task that takes a human expert about two hours, with the agent predicted to succeed half the time on that task distribution.

METR’s measurement page explains the limits: these are mostly well-specified software tasks, performance on messier work can be worse, and estimates above sixteen hours are unreliable with that suite. The page was last updated September 8, 2026 and is no longer actively maintained. It is evidence of increasing task capability, not a promise that the next model will reliably run your incident response for a day.

The operational concern survives that distinction. A retry loop can keep asking a capable agent to work. Whether it makes progress depends on the task, feedback, permissions, and budget. The leather jacket remains optional.

Curve two: breadth

Endurance alone is one very patient employee. Orchestration lets the work spread across a queue.

In November 2025, Anthropic disclosed an AI-orchestrated espionage campaign, GTG-1002. According to its investigation, attackers built a framework around Claude Code and attempted infiltration of roughly thirty targets, succeeding in a small number of cases. They used jailbreaks and disguised malicious subtasks as legitimate security work. Humans still chose targets and made important decisions; the model also fabricated some results.

That is a serious report of operational misuse. It is not a measurement of thirty simultaneous sub-agents, proof of a self-spreading worm, or evidence that every safety control disappeared. The useful lesson is narrower: an attacker’s framework can delegate substantial work to a commercial agent.

Conceptual illustration of task capability and orchestration breadth, with hypothetical work budgets kept separate from observed campaign targets — Two dimensions to watch, not two measured growth curves. METR measures task difficulty in human time; campaign target counts do not measure simultaneous workers.

For capacity planning, eight workers running for an hour consume eight worker-hours. That arithmetic says nothing by itself about successful intrusions. Coordination overhead, correlated mistakes, quotas, and defender automation all change the outcome. The question for a security team is how much hostile work its controls can reject before it lands in a human queue.

Who pays

Sysdig’s May 2024 LLMjacking report described stolen cloud credentials being used to access model services at the victim’s expense. Its modeled exposure exceeded $46,000 per day; a September 2024 follow-up described potential costs above $100,000 per day with more expensive models. Those are historical cost scenarios, not typical losses or a 2026 price quote.

There is a concrete bridge to agent tooling, too. In June 2026, Sysdig observed an actor using an exposed Ollama server to develop an automated offensive security tool. The observed targets were private practice environments; the researchers explicitly left the tool’s eventual intent unresolved. That case shows stolen inference supporting tool development, not a confirmed campaign against public victims.

Stolen access weakens price as a deterrent: the victim receives the model charges. It does not make the attacker’s infrastructure, credential acquisition, or supervision free. It also does not bypass the account’s permissions, model access restrictions, or quotas. Those controls still limit what the stolen identity can do; detection and revocation can cut the run short.

The mistake is expecting a price tag to enforce a security boundary. A thief doesn’t need your discount code. They need your credentials.

Stolen cloud credentials route model charges to the victim; account permissions, quotas, and detection still constrain misuse — LLMjacking shifts the model bill. It does not remove authorization, quotas, or the attacker’s other costs.

The swarm only has to be right once

Defenders comfort themselves with per-attempt failure rates: most intrusion attempts fail, most suspicious PRs get rejected, we’d catch the one that works. True per attempt. Wrong in aggregate, because attempts are cheap.

The probability that at least one of n independent attempts succeeds is 1 − (1 − p)^n:

p = 1% per attempt, n = 100:   1 − 0.99^100  ≈ 63%
p = 0.5%, n = 100:             ≈ 39%
p = 0.5%, n = 300:             ≈ 78%
p = 0.1%, n = 1000:            ≈ 63%

These are toy probabilities, not measured attack success rates. The formula assumes independent attempts with the same fixed p. Repeating the same broken approach can produce correlated failures; a thousand retries may add very little. Detection, lockouts, and changing targets also change the odds.

Even with those limits, volume matters. Automation and stolen inference can reduce the attacker’s marginal cost, while noisy attempts can create expensive review work. Defenders can automate rejection and triage too. METR’s benchmark does not tell us the intrusion probability p, and orchestration alone does not guarantee more useful attempts. Measure both sides of that queue.

Illustrative probability curves for independent attempts with a fixed success probability, including 1 percent across 100 attempts giving about 63 percent — Under the stated assumptions, repeated attempts raise aggregate success odds. Shared failure modes and defensive intervention can make real campaigns behave very differently.

What persistence means when the malware is text

One more piece of the threat model, and it’s the least intuitive.

An individual model call does not need persistent state for the surrounding agent system to have it. Files, memory stores, retrieval corpora, queues, and tool configs can outlive a run. An attacker who can influence those inputs may influence what a future legitimate agent does with fresh credentials.

Microsoft’s research on AI memory describes how poisoned memories can carry influence into later sessions. The trust boundary is the important part: text that an agent encounters must not automatically become authority to use its tools.

Three failure modes are worth testing in your own system. These are threat model scenarios, not three incidents established by the reports above:

Dormant instructions. A malicious entry can sit until a legitimate workflow retrieves it. The resulting tool calls may use normal identities, so inspect behavior as well as who authenticated.
Copied instructions. Templates, sync jobs, and shared memory can spread poisoned text if their review and trust boundaries permit it. Copying text does not guarantee another agent will obey it, but it creates another chance.
Restored instructions. If a contaminated source of truth feeds a remediation job, deleting its local output can cause the job to restore it. Find that source and its trigger before declaring cleanup complete.

The implant can be text. The permissions that make it dangerous are still ordinary infrastructure.

No fate but what we make

Sarah Connor’s message, passed to the machines that keep arriving: “The future’s not set. There’s no fate but what we make.” It’s the defenders’ line, and it converts directly into a defense architecture. Four layers:

Four defense layers: scoped identity, reviewed agent inputs and tool permissions, edit and runtime monitoring, and containment before cleanup — Each layer reduces a different risk. Credential expiry does not remove poisoned memory, and reviewing memory does not replace runtime monitoring.

Identity — shrink the stolen access. Prefer short-lived, narrowly scoped credentials. Restrict federation trust to the intended issuer, audience, repository, and job or environment; inventory non-human identities. Short lifetimes reduce replay windows. They do not remove implants or stop a compromised runner from obtaining fresh credentials. Restrict model access and invocation quotas, and keep self-hosted inference behind authentication and network controls.
Treat agent text as production code. Version and review instruction files, prompt templates, and tool configs. Record provenance and control writes to memory and retrieval stores. Reading untrusted text must not grant it authority: enforce least privilege at the tool boundary, constrain outbound access, and require approval for consequential actions. A prompt telling the agent to be careful is not that boundary.
Detect edits and execution. Correlate workflow, webhook, event-rule, and memory changes with approved work. Keep cloud audit logs, tool activity, unusual outbound traffic, and model usage in view. Investigate unexplained drift. Alert on inference and spending spikes, with a tested way to deny further access; a billing alert alone is not an immediate spending cap.
Contain, then clean up. Suspend compromised access, revoke active sessions where supported, and stop or isolate affected workers. Preserve evidence as containment permits. Disable reactivation paths and reconcile queues before removing their payloads. Rotate exposed secrets, restore reviewed configurations, and repair poisoned memory and corpora. Verify that new credential issuance, unwanted inference, and reactivation have stopped before resuming. Revoking existing role sessions is a separate concern from replacing a long-lived key.

None of this is exotic. It’s boring, and that’s the match for a threat built from familiar components. 1984’s version needed a time machine and a factory of killing machines. 2026’s version needs a stolen key, a retry loop, and one organization that never reviewed the files its agents read.

The future isn’t set. But right now, on somebody’s cloud account, the future is running up a tab either way.

No fate but what we make — and, until the access and persistence are contained, no fate but what we bill.

Sources checked October 18, 2026. METR supplies benchmark evidence; Anthropic and Sysdig supply incident reports and cost scenarios; Microsoft supplies memory-security research. The combined threat model and defensive priorities are my interpretation, with hypothetical scenarios labeled above.