The latest buzzword debate on cyber-social media is about the term “machine speed,” and it’s caught my attention in a big way. I’ve never been one to just go along with what everyone else is saying. I’d rather take an idea back to first principles and make up my own mind. So, contrary to popular opinion: I love the term “machine speed.” If it’s properly defined and used in context, it shows exactly how and why AI demands a complete rethink of cybersecurity. Let’s get into the meat and potatoes of why I find myself the voice of dissent.
The Cyber Why Sponsor
Stop trying to control AI agents. Control the data instead.
Most vendors police agent behavior at runtime. That’s betting the agent behaves. Control the data and it doesn’t matter.
The Virtru Data Harbor Platform cryptographically binds policy to the data itself, using the Trusted Data Format, an open standard. Keys go only to agents entitled to them. No entitlement, no key, no data. Protect what matters most, wherever it goes.
Watch live online, on November 17 at 3:00 PM ET.
Register now for the Data Harbor Platform launch →
The BUZZ Surrounding “Machine Speed”
My co-host Adrian Sanabria and I have debated the legitimacy of the term “machine speed” many times on the Enterprise Security Weekly podcast. Aligning more Adrian’s view, several notable voices have also gone to social media to complain about the term, essentially asking, “Isn’t all code execution done at machine speed?”
Here’s Mark Kraynak, founding partner at Acrew Capital, on the term (original post):
Okay so my newly forming pet peeve is with the use of the term “machine speed” to describe these agentic swarm attacks. Everything that runs on computers is “machine speed.” I guess there are human mediated processes that slow this down, but the real problem is the swarm and lack of human mediation. The speed of any single agent isn’t really the problem...it’s the massive parallelization that is the real problem. Your defense doesn’t just require speed, it requires the ability to deal with 10s 100s or even 1000s or more of attack components at the same time.
The great Ross Haleliuk, author of Venture In Security chimed in with this comment:
Definitely agree. Even pre-AI, attackers already had automation to avoid doing as much manual work as possible. AI agents take it to the next level, but parallelized attacks are a better way to put it than “machine speed”.
I hold both of these gentlemen in the highest regard, and I can firmly say they are both WRONG. (Kidding, gents. You aren’t wrong. I just have a more nuanced, and apparently different, view of the term.) The more people I talk to, the more complaints I hear about these two words, and the objections behind them don’t hold up for me.
The Nuance is in the Definition
Set aside the literal words for a moment. I think the definition is where the disagreement really lives, and it’s why people react so strongly when they hear someone say “machine speed.” Here’s mine:
Machine speed is what you get when you go from a specifically designed task to an open-ended, goal-directed system that makes its own decisions, and you remove the human from the decision-making loop at the same time.
That’s a mouthful, so let me make it concrete.
Traditional programs follow a single path, built from specific instructions, to reach a defined end state. Input goes into the system, compute and analysis happen on that input, and output comes out the other end. Mark and Ross are right on this point: by definition, code written and executed this way already runs at “machine speed.” No human is involved, and the output arrives as fast as the system can compute it.
So what’s different today? Before AI, the fastest we could go was a single process, or a group of processes, carrying out a predetermined activity to reach a predetermined outcome. The moment we defined the outcome as a general goal instead of a set of specific instructions, the system needed a human to break that goal into tasks, choose a path, and execute it. At that point it was no longer running at machine speed, because it was no longer all machine. The human in the loop was the speed limit.
Enter the Agent
In the agentic era, we can define an overarching goal and, with no human intervention, have an agentic system spin up as many “paths to completion” as it can find. The human part of the puzzle (thinking, deciding, choosing a path) has been automated. We’re emulating human decision-making with AI, and the decision making process runs far faster than any human can in isolation. The part of the system that used to be limited by humans now runs at machine speed too.
Why Isn’t This Just a Scale Problem
Some will argue this is really a problem of scale. But you could always scale traditional code by parallelizing the workload. That gets deterministic tasks done faster. It doesn’t solve the problem of a human taking time to decide which path to take when they’re handed a general goal.
Here’s an example. I could write a program that follows a very large number of attack paths when trying to break into a target enterprise. Given enough time, I could build an extremely complex attack model with lots of options for how to attack you. And yes, that would run at machine speed and could be highly scalable. But if I told that same system the goal was “hack Company X,” it couldn’t pursue every viable attack vector without a human deciding what those paths are. It’s human-limited. Replace that human with AI, and the number of paths explored is limited only by compute and budget. The AI looks for any way to achieve its goal, with no human slowing it down.
This is where I think Mark and I actually agree. The massive parallelization he’s worried about is real, but it’s a consequence, not the cause. The human was the bottleneck that kept every decision in single file. Remove the human, and you can run decisions in parallel, not just tasks.
The short version:
Point something deterministic at an objective, and it needs either a predefined path or a human to guide its decisions. Point an AI agent at the same objective, and you’ve removed the thing that kept it from running at machine speed: the human.
Machine speed doesn’t come from running 100x the processes. It comes from removing the bottleneck, in this case the human, so the system can make decisions at machine speed across every path it chooses to pursue. Add the ability to spin up as many compute threads as you’re willing to pay for, and it’s easy to see how machine speed completely changes both offensive and defensive cybersecurity capabilities and requirements.
What This Means for Cyber Defenders
If machine speed means moving humans from the attackers decision loop, the very uncomfortable question that becomes clear is where are the humans currently in my defensive decision loop?
Take a look at how cybersecurity actually works today. An alert fires, lands in a queue, and waits for an analyst to respond. The analyst investigates, decides if it’s real, how much risk exists, and opens a ticket for remediation. The ticket might go to some other team, who schedules a patch or an infrastructure modification for the next change window. Every one of those steps requires a human in the loop today. The actions are measure in minutes, hours, or days. That was fine when attackers on the other side also had similar human making decision loops. Both sides moved at roughly human pace, and the defender maybe stood a chance of staying ahead of the attacker.
Machine speed breaks this balance. When an attacker’s decisions take seconds, every human approval and decision point on the other side becomes the weak point. It doesn’t matter how good your detection is if your response waits in a queue to be completed.
To stand a chance to win against agentic offensive security models, defenders must get ahead of the problem by figuring out which decisions really need a human and take the human out of all of the rest.
At a foundational level, and by my definition, I love the term “machine speed.” Other people define it more loosely or weigh other factors. At the end of the day, what I (or any other armchair quarterback) want to call it won’t decide whether it sticks. Whatever enters the public lexicon wins and I won’t truely be able to influence that.
But whatever we end up calling it, here’s my ask - when you hear “machine speed,” don’t hear “fast code.” Hear “no human in the decision loop.” That’s the shift that matters, for attackers and defenders alike.
AI disclosure: The ideas and argument in this piece are my own. I used Claude (Anthropic) for peer review and copy editing and to steel man my argument as I thought it through.
Love the definition, but it makes me hate the term even more. If the definition describes "autonomous AI operations", fine, but "machine speed" definitely does not make me think "autonomous". The term only references speed, not scale or the means of operation.
Surely we can do better than "machine speed" to describe this?
You helped more than one marketer with this, Tyler.