Multi-agent AI intrusions are already showing up in incident response investigations. Fast inference is the piece we are watching next.
Two weeks ago, in Inside the Breaches AI Is Already Shaping, we showed machine-speed attacker activity rising from about one in six of our investigations in the fourth quarter of 2025 to more than six in ten by the third quarter of 2026. It is still climbing, and a second pattern has started to show up alongside it. Instead of one fast line of attack, we are seeing many running at once.
This post is about that pattern and what we expect to come after it. The next piece is fast inference, models that write more than 1,000 tokens per second, powering single agents and multi-agent attacks alike. Each piece takes a different brake off an AI-run intrusion. Abliterated models removed the refusal. Parallel agents are removing the queue. Fast inference removes the wait, and when it reaches intrusions we expect it to set their pace.
The change now under way is concurrency, many AI agents working the same intrusion at once.
There are two common ways to organize that. With sub-agents, a lead agent splits the job and hands each piece to a sub-agent that runs in its own context and reports back only to the lead. A swarm has no fixed lead. Peer agents pick up work and share what they find with each other directly. We call both multi-agent intrusions. The ones that concern us run dozens or hundreds of agents on one intrusion, which is not special. Existing harnesses can already put hundreds of agents on a single job.
In intrusions we investigated attackers have stopped working one step at a time. Inside the victim's environment, they run many fronts at once, pulling data, minting new credentials, creating accounts and changing permissions in the same minutes, with requests from different addresses interleaved within single seconds. That pattern grew stronger in October, and we expect it to become the norm. In larger, more complex environments, we are starting to see intrusions running many dozens of workstreams at once.
Scale matters because most of an intrusion is dead ends. A single agent tries them one at a time. Parallel agents try them all at once and share whatever works, so the clock runs only as long as the one path that succeeds. That makes an attack wider. It does not make any single agent move faster.
A language model produces its output one token at a time. A token is roughly three quarters of a word, and leading hosted models stream about 60 to 240 tokens per second, with the most capable ones near the bottom of that range. That feels instant to a person reading a reply, which is why speed rarely comes up in conversations about AI risk.
An attacking agent is not reading a reply. It works in a loop. It reads what it has found, reasons about what to try next, writes a command, runs it and reads the result. Every pass begins with the model writing, a few hundred tokens for a simple step and thousands when it works out an exploit or writes a script.
That writing time is now shrinking fast. Until recently, 1,000 tokens per second meant specialized chips and smaller models. In October 2026, Fireworks, one of the largest inference providers for open models, announced an Ultrafast tier, now in private preview, that it says runs DeepSeek V4.1 Flash, a strong open-weight model, at more than 1,500 tokens per second. Independent benchmarks measure the fastest other providers serving the same model at roughly 850 to 1,100 tokens per second, against about 170 on DeepSeek's own service. The providers that have published details run ordinary data-center GPUs. The speed comes from software, mainly speculative decoding, where a small draft model guesses several tokens ahead and the large model checks them in one step.
The model labs are moving the same way, though not yet as far. OpenAI now offers an Ultrafast tier for GPT-6 Astra, rated at up to 300 tokens per second (about 400 in one independent test), roughly three times its standard speed. At the fastest speeds, the writing in an average pass drops from 8 seconds to under one, while the rest of the loop stays the same.
Attackers can get fast inference the same ways anyone else can. They can buy a provider's fast tier, or use access stolen from someone who already pays for it. They already go after that access in the environments we investigate, searching compromised systems for OpenAI, Anthropic and Bedrock keys, testing stolen cloud keys against hosted models and running up charges on victims' AI infrastructure. In one case, an attacker pointed a business application's AI feature at their own server to capture its model provider key, then switched it back seconds later.
Stolen inference comes in two kinds. Access taken from a provider itself, through internal clusters, service accounts or staff credentials, sits under the provider's own controls and could reach capacity no customer can buy. We have investigated one such intrusion, in which the attacker reached the control plane of a provider's GPU cluster. A customer's stolen API key, LLMjacking in its usual form, carries that customer's rate limits and monitoring. What it changes is who pays.
We re-timed several of the multi-agent cloud intrusions behind this post at the 1,075 tokens a second measured above. The decision chains shrank sharply. A run from a hijacked developer account to production secrets fell from about 11 minutes to as little as 2. Where other work filled the intrusion, the gain was small, and more than 80 minutes of bulk downloads and idle time would have lost only a few minutes. The model sets the pace of the decisions, not of moving data.
We started from the second-by-second timelines in our investigations and looked only at gaps where the next step used the result of the one before. We counted a gap as the agent deciding only when nothing else in the logs explains it. If a download was still running, a machine was rebooting, a script was looping, a person had to approve a sign-in or the attacker simply went quiet, we kept that time exactly as observed. Gaps of a few seconds count as the command running, not thinking. Logs show when each step happened, not what the model was doing in between, so where we were unsure we left the time alone. Each result is a range. At the low end only the agent's last response gets faster, and at the high end the whole gap was the agent writing at today's speed.
We expect fast inference to show up first where speed is the whole point, such as a state actor's smash-and-grab or a disruptive attack on infrastructure, where staying hidden no longer matters.
Defenders are already squeezed. In the third quarter of 2026, more than four in ten of our machine-speed cloud cases reached impact within the first hour. Fast parallel agents would compress both the thinking time and the trial and error that still sit between an attacker's steps.
The technology defenders rely on was built for a slower attacker. Most detection in the cloud runs through a pipeline. The provider writes the audit log, a collector picks it up, the security platform ingests and normalizes it, and a detection rule runs against it. Every stage adds time. Cloud audit logs often take around five minutes just to arrive, and with batch collection and scheduled detections, five to fifteen minutes from action to alert is common. That has been fast enough for intruders who needed many minutes or hours between steps. Against an attack that finishes in a minute or two, which is where fast inference points, the first alert would describe something that has already happened.
An alert is also not an investigation. It only says that something may be worth a look, and someone, or something, still has to work out what happened. AI SOC platforms are a real step forward here. They can work an alert far faster than a human queue, and against today's intrusions, containing within minutes can stop an attacker before they spread deeper. When fast inference reaches intrusions, the slowest part of the response will be the pipeline in front of the AI SOC, not the analysis. We expect that to change how security tooling is built. For now, this is the infrastructure defenders have.
That makes one decision matter most today. Many organizations still hesitate to let containment run without a person, for fear of disrupting the business. Our advice is that when an AI SOC has investigated an alert and concluded it is an attack, it should contain without waiting for someone to sign off. That does not mean auto-containing every alert a security product raises. It means a confident verdict should not sit in a queue, even if acting on it causes a short disruption. If you cannot contain quickly, or have no way to contain in your cloud control plane or on your endpoints, an attacker who gets past the first foothold becomes far harder to remove, and the disruption ends up far larger than the one you were trying to avoid.
Multi-agent attacks already change investigation too. A multi-agent intrusion sends thousands of requests across many workstreams. Working out which requests were the attacker's, and what each workstream was after, doesn't scale by hand, which is part of why we run our investigations through an AI harness built for it.
The known ways in are not going anywhere. Phishing, vishing calls to the help desk, stolen tokens and malware planted on one person's machine will keep opening the door, and AI already makes all of them more convincing. What you can change is how many of your systems an attacker can reach. A faster attacker gets more out of every exposed system, so the cheapest defense against speed is having fewer of them.
That is why we advise clients to put an identity-aware edge in front of everything they expose publicly. That means a sign-in run by a cloud-scale provider, such as Cloudflare, Zscaler or Akamai, in front of your application, so nobody reaches your app, not even its login page, until they have signed in there first. Your application connects out to the provider and has no public address to scan. A firewall, VPN appliance or self-hosted login gateway is not the same thing. Each is one more system to probe, and edge appliances have long been among the most exploited ways in.
This works for customer-facing applications too. The edge can use the customer identity platform you already run so customers keep their accounts and do not log in twice.
This will not fit every application, and it moves the risk rather than removing it. The edge becomes your front door, so its sign-in, MFA and session handling have to be strong.
Fast inference is already for sale. We do not expect it to stay out of our cases for long.
When it reaches them, the limit on an intrusion will be the systems it runs through, not the attacker's thinking. The decisions that matter, such as which applications stay on the open internet and which containment steps can run without waiting for a person, have to be made before that day, not during it.
We will keep reporting what our investigations show, including the first time we suspect fast inference in one.
Until then, plan as if the last brake is already gone. We will be watching alongside you.
MOXFIVE provides the clarity and peace of mind needed for attack victims during the incident response process. Our platform approach enables victims of attacks to work with a Technical Advisor who provides the expertise and guidance needed in a time of crisis, and facilitates the delivery of all technical needs required, consistently and efficiently.
Learn More
With experience on the front lines responding to incidents daily, MOXFIVE Technical Advisors have the unique ability to connect the dots between business, information technology, and security objectives to help you quickly identify the gaps and build a more resilient environment.
