A little over a year ago, I wrote a blog called The Robots Are (Definitely) Coming.
It was deliberately tongue-in-cheek. At the time, AI was moving quickly enough that it was difficult to work out which predictions were genuinely concerning and which belonged somewhere between science fiction and a particularly bad episode of Black Mirror.
The argument was fairly simple. AI was going to make cybercrime easier to scale.
It could write convincing messages, generate code, analyse information, identify weaknesses and produce synthetic content at a speed and volume that humans simply couldn’t match. Put those capabilities in the hands of someone who wasn’t terribly interested in following the rules and, well, things were likely to get interesting.
Looking back from 2026, quite a lot of that prediction aged reasonably well.
Some of it was even a little obvious, but there was one thing I underestimated.
I was thinking primarily about attackers using AI.
The bigger change has been organisations putting AI into their own environments.
And that changes the security problem rather considerably.
The phishing problem became a much bigger problem
AI-generated phishing was probably the easiest prediction to make.
The interesting part wasn’t really that AI could write an email. We’ve had tools capable of producing perfectly serviceable prose for years.
The real change was the reduction in effort required to make something convincing.
The old warning signs of phishing — terrible spelling, awkward grammar, strange phrasing and messages that looked as though they’d been written by somebody operating a keyboard for the first time — are becoming less useful.
An attacker can generate a message, tailor it to the recipient, change the tone, try another version and move on to the next target without spending much human time doing any of it.
Voice cloning and synthetic video have extended the same problem beyond email. The technology doesn’t need to produce a perfect replica. It only needs to be convincing for long enough to make somebody do the wrong thing.
That matters because most successful attacks aren’t really competitions in technical brilliance.
They’re competitions in probability.
If an attacker can make ten thousand attempts for roughly the effort it once took to make a hundred, they don’t necessarily need a better attack.
They just need more opportunities.
AI is very good at creating opportunities.
I may have been a little dramatic about shape-shifting malware
This is probably the prediction where I got carried away.
The original article talked about malware changing its behaviour and appearance in real time, adapting to the environment and generally behaving like something that had escaped from a Hollywood script.
That isn’t quite how the world turned out.
Attackers still have plenty of success with remarkably traditional techniques. Unpatched systems. Stolen credentials. Poor configuration. Exposed services. Social engineering. Legitimate administration tools being abused for illegitimate purposes.
The interesting change is less about malware becoming some sort of digital shapeshifter and more about friction disappearing from the attack chain.
AI can accelerate reconnaissance, explain unfamiliar technologies, generate and modify code, analyse technical documentation, investigate vulnerabilities and help somebody move between stages of an attack much more quickly.
It doesn’t necessarily make the attacker smarter.
It makes the attacker more productive.
Which, frankly, is probably plenty.
Vulnerability research was an easier prediction
AI-assisted vulnerability discovery was another area where the direction of travel was fairly easy to see.
Code analysis, test generation, vulnerability research and attack-path exploration are all areas where AI can reduce the amount of human effort involved.
Again, the important issue isn’t necessarily some miraculous new hacking capability.
It’s economics.
Security research has always been constrained by time. Someone has to understand the system, examine the code, form a hypothesis, test it, reject it, try another approach and repeat the process.
Make those experiments cheaper and faster and activities that previously weren’t economically attractive become much more interesting.
That applies equally to defenders, of course.
The same capability that helps somebody find a vulnerability can help somebody find it before an attacker does.
Which brings us to the part of the original article I didn’t really see coming.
The bigger change was happening on our side of the fence
When I wrote the original article, I was mostly thinking about AI as another tool in the attacker’s toolbox.
The much more significant development has been AI becoming part of the systems we’re building ourselves.
We’ve moved rather quickly from the idea of a chatbot answering questions to systems that can retrieve internal information, interact with databases, call APIs, invoke tools and perform multi-step tasks.
A model connected to a pile of public information is one thing.
A model connected to company data, internal systems, credentials and operational tooling is something else entirely.At that point, the security problem isn’t really the model anymore.
The model is one component of a larger system.
And that system has identities, permissions, data stores, APIs, dependencies, trust relationships and all the other things we’ve spent decades learning how to secure.
We’ve simply added a probabilistic reasoning system into the middle of it.
That is where things get interesting.
Welcome to the agentic problem
Agentic systems bring together a collection of problems that will already be familiar to anybody who has spent time doing application or infrastructure security.
Identity,Access control,Secrets,APIs,Third-party dependencies,Data,Untrusted input,Trust relationships.
The difference is that we’re now allowing a system capable of interpreting information and making decisions to sit between those things.
Give an agent an objective and it may decide which tool to use, what information to retrieve, what to do with the result and what action should happen next.
That creates a rather uncomfortable security property.
The agent may encounter information that was never intended to influence its behaviour.
A document retrieved from a knowledge base can contain instructions.
A web page can contain instructions.
A tool response can contain instructions.
Data that looks perfectly legitimate to the application can still contain content designed to manipulate the model processing it.
We’ve spent years telling developers not to trust input.
We’re now building systems where the input can influence the reasoning process itself.
Sure look. What could possibly go wrong?
The attack surface has moved
This is why I think the cybersecurity conversation around AI has sometimes become too focused on the model.
Jailbreaks matter.Prompt injection matters.Model manipulation matters.
But they’re only part of the problem.
Once an AI system has access to useful information and useful capabilities, the security boundary extends well beyond the model itself.
Where did the data come from?Can it be trusted?
Who can modify it?What happens to the embeddings?
Who can access the vector store?Are tenants properly isolated?
Which tools can the model call?Under whose identity?
What permissions does that identity have? What happens when a tool returns something unexpected?Can an agent make a change to a production system?Can we see that it happened?
Can we explain why it happened?And, perhaps most importantly, can we stop it?
These aren’t particularly weird questions.
They’re the sort of questions security engineers have been asking about ordinary systems for years.
The difference is that we’ve traditionally expected software to behave according to deterministic logic.
With AI systems, we also have to account for behaviour emerging from data, models, prompts, retrieved content and interactions between components.
That makes runtime visibility considerably more important.
A log saying that the application was running normally isn’t much use if the application has just allowed an agent to retrieve sensitive information, invoke a privileged tool and make a production change.
At that point, “the application was running normally” isn’t much of an incident report.
And then along came MCP
The arrival of protocols such as MCP makes this even more interesting.
The attraction is obvious. Instead of every AI application inventing its own way of connecting models to external tools and information, we can create more consistent interfaces for doing it.
Standardisation is useful.
It is also very good at making things easier to connect.
And whenever we make things easier to connect, we need to think carefully about what we’ve just connected.
An MCP server can expose tools or information to an AI system. That creates another relationship between the model, the client, the server, the tools, the identity and the underlying data.
None of that makes MCP inherently insecure.
It simply means the security problem is now a systems problem.
Credentials still matter.
Permissions still matter.
The provenance of information still matters.
Compromised or malicious components still matter.
An overly powerful tool is still an overly powerful tool, even if the thing calling it happens to communicate in natural language.AI doesn’t get a free pass because the interface happens to be conversational.
My “fight AI with AI” prediction also turned out to be true
The other part of the original article that has aged reasonably well is the idea that defenders would respond with AI of their own.
They are.
AI is being used to help analyse alerts, investigate incidents, identify anomalies, summarise large volumes of information and automate parts of the response process.
That makes sense.
Defenders have the same problem as attackers: scale.
There is simply too much data, too many alerts and too many potential relationships for humans to examine everything manually.
But there is an interesting catch.
The moment we allow AI to make or influence security decisions, the AI becomes part of the thing we need to secure.
It needs monitoring.
It needs meaningful telemetry.
We need to know what it accessed, which identity it used, which tools it called, what decisions it made and whether its behaviour is consistent with what we expected.
Performance metrics such as P50 and P95 response times might tell us that something has changed.
They don’t necessarily tell us whether the thing that changed is a security problem.
A sudden increase in privileged tool calls might be considerably more interesting than a few milliseconds of additional latency.
And yes, that probably means another dashboard.
Because apparently we didn’t have enough already.
The human is still in the loop — for now
There is an obvious temptation here to automate everything.
And, to be fair, AI is very good at repetitive cognitive work.
If a system can investigate a low-risk event in seconds rather than waiting for somebody to get around to it, there is an obvious benefit.
However autonomy has a price.
The more authority we give a system, the greater the consequences when that system is manipulated, misconfigured or simply wrong.
That doesn’t mean putting a human approval box in front of every AI decision.
It means being deliberate about what an AI system is actually allowed to do.
Reading a document is not the same as deleting a database.
Creating a draft response is not the same as sending money.
Investigating an alert is not the same as disabling an identity.
The principle of least privilege hasn’t suddenly become obsolete because we’ve put an LLM in front of the API.
If anything, it has become more important, the Human needs to be in control and not a ceremonial button pusher
So what actually needs securing?
This is where I think the conversation needs to mature.
AI security cannot simply mean testing the model and declaring victory because somebody failed to make it say something rude.
The model is part of the security boundary, but it isn’t the whole boundary.The system around it matters just as much.
We need to know what an AI system can see, what it can access, what it can change and which identities and tools sit behind those capabilities.
We need confidence in the provenance of the data it relies upon and some understanding of how that data, the models and the surrounding components have changed over time.
We need runtime monitoring that tells us what the system is actually doing rather than simply telling us that it is alive.
And we need intervention mechanisms.Permissions can be constrained.Transactions can be limited.High-impact actions can require approval.Tools can be sandboxed.Credentials can be revoked.Capabilities can be disabled.
The system should have somewhere to go when things stop looking right other than “carry on and hope for the best.”
Most importantly, these controls need to exist before something goes wrong.
Because once an autonomous system is operating at speed, discovering that nobody quite knows what permissions it inherited is a particularly poor time to begin designing the security model.
So, was the original article right?
Looking back, I think the central argument was right.
AI has become a force multiplier for cybercrime. It has improved social engineering, accelerated technical research, lowered the barrier to sophisticated activity and given defenders new capabilities of their own.
But the part I underestimated was the direction of travel.
I was thinking about criminals using AI against organisations.
The bigger story is organisations putting AI inside their own infrastructure.
We’re giving these systems identities, access to information, APIs and tools. We’re allowing them to interact with other systems and, increasingly, to make decisions and take actions on our behalf.
That changes the security problem.
We’re no longer simply defending against somebody else’s AI.
We’re securing our own.
And that means AI security needs to become an engineering and operational discipline rather than a collection of interesting demonstrations involving jailbreaks and prompt injection.
The robots don’t need to rise
When I wrote the original article, the robots and Skynet were deliberately ridiculous ways of talking about the future.A year later, I’m less interested in whether the robots are coming.The more interesting observation is that we’ve already started putting them to work.
We’ve connected reasoning systems to our data, identities, APIs and applications. We’ve given them permissions and, in some cases, the ability to act without somebody approving every step.
That makes the practical security question remarkably straightforward.
Can we explain what an AI system can access, what it can do, what it’s doing at runtime and how we stop it when something goes wrong?
If the answer is yes, we’re beginning to build something we can actually secure.
If the answer is no, we’re relying on optimism.
The robots aren’t coming.
We’ve started deploying them.
Before we worry about Skynet, we should probably sort out least privilege.
Sure look. It’s usually the boring stuff that gets us in the end.