We keep connecting software and giving AI agents more room to act. I think that changes how attacks can spread.
October has been a rough month for anyone trying to keep software secure.
PHP disclosed critical vulnerabilities. Node.js released security fixes, with the most serious rated High. Zeabur reported an intrusion involving leaked internal credentials, and LiteLLM's official release pipeline published a compromised package and container images.
By the end of the month, Polymarket had reported a third-party compromise affecting its international platform, and Binance had disclosed a theft of about $6.3 billion.
These are separate incidents. Some are vulnerability disclosures, and some are actual breaches. I haven't seen evidence that they were coordinated, or that AI agents caused all of them.
Looking at them together, though, I keep noticing how much of our security depends on other people's systems staying trustworthy. A package comes through the official release channel. A cloud platform holds credentials for infrastructure we run. A third-party script runs on a page where people manage money. Most days those connections work, so we stop thinking about them.
Now, we're adding AI agents that read across those systems and act on what they find. I'm less worried about whether an agent can be tricked once. I'm more worried about whether it can pass the trick on.
We've Seen This Before
In 2017, WannaCry spread through vulnerable computers and disrupted hospitals, businesses, and public services. NotPetya started with a compromised software update and spread through corporate networks, causing damage far beyond its first targets.
Neither attack had to reach every victim on its own. They moved through connections that already existed.
Modern software has a lot of those. Even a small application can rely on hundreds of packages, an outside login provider, several APIs, cloud infrastructure, and an automated deployment pipeline. A developer may depend on a package they have never read because some other package needs it.
That isn't necessarily careless. No team can build and audit everything it uses, and shared software is a big reason small teams can ship anything at all.
The cost is that when a trusted component fails, the damage can reach systems whose owners never chose to trust the original source.
AI didn't create this problem. It does change how much software we produce, how fast we connect it, and how much those connections are allowed to do.
More Software to Secure
Someone with little programming experience can now describe an application to a coding agent and have something working in an afternoon. I get why people are excited. An idea that used to stay in a notebook can turn into a working tool before dinner.
Trouble starts when "it works" gets treated as "I understand what was built."
An agent can pick dependencies, write authentication logic, configure database access, and set deployment permissions along with the parts you can see. Those choices still need review, even if the person accepting them didn't realize they were choices.
A missing authorization check won't show up on any screen. A credential can have far more access than the app needs. An unnecessary dependency won't make a single test fail.
Experienced engineers miss these things too, and handwritten code isn't automatically safer. What's different now is volume. We can produce a lot more code, and the attention available to review it hasn't grown at the same rate.
Put simply, writing software is getting cheaper faster than understanding, securing, and maintaining it.
For a prototype that never leaves a laptop, that may be fine. For an app holding customer data, or a tool wired into a company's internal systems, somebody inherits the gap, usually whoever has to run it later.
Attackers get the same discount. AI can help them generate variations of malicious code, adapt scripts to different environments, and automate parts of their research. Most attempts will still fail, but each one costs less, so they can try more.
It's tempting to compare this to biological mutation, where more variations mean more chances that one survives. The comparison only goes so far, and a generated variation is often worse than the original. My point is narrower. If experimenting gets cheaper for attackers while careful review stays expensive for defenders, defense gets harder.
An Agent Can Use the Access We Give It
Writing code is only part of the change. We're also giving agents terminals, browsers, repositories, cloud dashboards, and production credentials.
An assistant that explains an error is useful. One that investigates the error, changes a configuration, and deploys a fix is more useful, and it's now working with authority that used to belong to a person.
Take a hypothetical cloud operations assistant. It reads logs, checks deployments, and can make a limited set of changes to restore service. One day, an attacker plants text in a log entry, written to look like an operational instruction.
The log is meant to be evidence. If the agent reads that line as an instruction, the attacker has gotten something done without ever logging into the dashboard.
How bad that is depends on the assistant's permissions. If it can only read logs, not much happens. If it can pull secrets, change firewall rules, or trigger deployments, the same mistake gets serious quickly.
The agent doesn't need to want anything harmful. It can be doing its best to finish the task it was given and still use legitimate access for something nobody approved.
This reaches beyond software companies. Hospitals, logistics providers, banks, and manufacturers all rely on software for everyday work. An outage in a scheduling or dispatch system can affect people who have never heard of the agent that changed it.
Access to a business application isn't automatically access to a factory's control systems, and those boundaries matter. But nobody needs to imagine an agent taking over a power plant. Breaking the systems people use to coordinate their work can already cause real harm.
How an Attack Could Move Between Agents
Prompt injection happens when an agent treats untrusted content as instructions instead of as material to work on. The content might sit in an email, a document, a web page, or a tool response.
What gets less attention is that agents also write content other agents will read.
Imagine a support assistant reading a malicious email. It creates an internal ticket summarizing the issue and carries the malicious instruction into that ticket. A second assistant reads the ticket to investigate it. If that assistant makes the same trust mistake, the attack has reached another system through normal work.
That example is hypothetical, but the idea has been tested. In Morris II, researchers built self-replicating malicious prompts that spread between experimental AI email assistants. The experiments ran in a lab, and they don't show that anything like this is spreading in real applications.
Copying a prompt doesn't make it a worm. For an attack to keep moving, the receiving agent has to follow it, has to have somewhere to write, and has to pass along something that still works on the next reader. Tight permissions or a well-enforced trust boundary can break that chain at any step.
What makes this kind of carrier unusual is that the email or ticket may contain no executable malware at all. It's an ordinary object moving through an ordinary workflow, and the harm only shows up when a reader gives part of it more authority than it deserves.
The compromised agent might keep doing most of its job well. It answers questions, summarizes documents, and closes routine tickets. One bad action among a hundred good ones doesn't look much like a system that has been taken over.
If the instruction ends up in a shared document or in an agent's saved context, it can be picked up again later. A summary might drop it, or it might keep exactly the part the attacker cared about. Rewriting doesn't reliably make it stronger, and it doesn't reliably make it safe either.
I'm honestly not sure we would notice this kind of compromise while the work still looked productive.
Do We Have an Immune System for This?
We've spent decades building the digital equivalent of an immune system.
Antivirus software, firewalls, endpoint detection, sandboxing, access controls, vulnerability scanners, and incident response procedures all grew out of earlier generations of threats.
We still need all of it. AI agents just bring a problem these tools weren't really built for.
A document can be perfectly safe to open and still contain instructions that steer an AI assistant. A tool response can contain no malicious code and still try to redirect an agent's decisions.
So on top of spotting dangerous software, we now have to notice when untrusted information starts being treated as authority.
Telling an agent not to follow instructions found in documents helps, but it isn't a security boundary, and the model shouldn't be the only thing making that call.
Most of our existing immune system learns from infections that have already happened. Someone catches a piece of malware, pulls out a signature or a behavior pattern, and defenses get updated to recognize it next time. Then it's detect, quarantine, and clean up.
That works when malicious code looks similar from one attack to the next. It works much less well when the attack is a sentence that can be phrased differently every time and tucked into an ordinary email or ticket. There may be no stable pattern to match.
I think agents will need something closer to reactive armor, meaning defensive agents that watch other agents while they work. They would flag an assistant that suddenly asks for credentials it has never needed, tries to send data somewhere new, or starts repeating the same odd instruction across tickets. Then they would act on their own, by pausing the agent, revoking its access, isolating its outputs, or pulling in a human before anything else happens.
Basically, AI defending against AI. When agents are constantly reading and acting on each other's output, no person can review every step, so some of the defense has to move as fast as the attack.
The armor has a weak spot of its own. A defensive agent also reads what the attacker wrote, and if it can be talked out of raising the alarm, it's one more target. It can't rely on judgment alone. Underneath it, there still have to be hard limits on what each agent is allowed to do, a record of where each instruction came from, and a list of actions that always need a separate check.
Most of those limits are ordinary engineering. An assistant that summarizes tickets shouldn't be able to change production infrastructure. An assistant that deploys fixes should only reach the systems it actually needs. Sending data outside the organization or expanding access should require a separate check, not just a convincing explanation from the agent asking for it.
These controls add friction, and some automation will look less impressive in a demo. I think that's a fair price, because the more an agent can do, the further its mistakes can travel.
Then there's recovery, which I think matters even more.
If a traditional server is compromised, we can rebuild it from a trusted image, rotate its credentials, and restore verified data.
But what happens when an AI agent has spent weeks writing documents, updating databases, talking to other agents, and making decisions based on compromised information?
Cleaning up the original agent may not be enough, because the effects of its work may already be spread across the organization.
Some documents may need to be checked again. Some decisions may need to be reversed. Other agents may have pulled the compromised information into their own workflows.
Without records of what the agent read, whose authority it was acting under, and what it changed, recovery turns into guesswork.
Recovering from an infected agent might take more than deleting the malicious instruction. We may have to rebuild the whole chain of trust around it.
What Actually Worries Me
I don't expect millions of agents to suddenly turn against us. What worries me is millions of useful agents doing ordinary work with more access than they need, and with less separation between information and authority than we would accept anywhere else.
Meanwhile, apps keep getting cheaper to build and workflows keep getting easier to automate. Each new connection is useful on its own. Added together, they give one bad act of trust more ways to become someone else's problem.
This doesn't mean a digital pandemic is coming. A lab demonstration is not a forecast. An agent that reads malicious content isn't automatically compromised, and a compromised agent can't necessarily spread anything.
Still, we are actively building the conditions that would make that kind of spread possible. Our systems read each other's output, keep context around, hand off tasks, and act without a person checking each step.
If an outbreak like this happens, it probably won't look like computers crashing all at once. An assistant reads a normal-looking document, makes a change nobody asked for, and writes the same instruction into a ticket for the next assistant. The apps stay online while the damage moves through the work itself.
October already gave us plenty of examples of what misplaced trust can cost.
Before we connect agents to everything, I'd like to have a good answer for what happens when one of them trusts the wrong thing, and how we stop that mistake from turning into the next agent's instructions.
