What an AI Agent Actually Does to Your Attack Surface
The claim that AI changes security is usually made badly. It is not that models invent new vulnerability classes. Mostly they do not. The change is economic, and the economics are what your security program was implicitly sized against.
What actually got cheaper
Reconnaissance and exploitation used to be gated by skilled human hours. That gate is what made most organizations safe: not that they were hard targets, but that they were not worth a specialist's week.
An autonomous agent removes the gate. It reads your dependency manifests, your public commits, your job postings, your error pages, your subdomain records. It drafts phishing content tuned to individual staff. It fuzzes endpoints and iterates on what comes back. It does this for weeks without fatigue, and it does it against every company on a list at the same time.
Nothing in that sequence is novel. All of it used to be expensive.
The arithmetic this breaks
Defensive programs are built around an implicit assumption: the attacker allocates finite effort, so raising cost above their budget makes you safe enough.
Collapse the cost and the assumption stops holding:
- The defender must be correct on every endpoint, dependency, release, and employee, every day.
- The attacker needs one opening, once.
- Attempts are now effectively unbounded.
An unbounded number of attempts against a system that has to be perfect has one outcome on a long enough timeline. This is not pessimism about your team. It is what the arithmetic says.
The wrong response
The instinct is to add layers: more monitoring, more segmentation, more training, more scanning. All of that is worth doing, and none of it changes the shape of the problem. Each layer raises the number of attempts required. None of them makes the required number infinite.
Worse, the layered approach quietly assumes the thing it is trying to guarantee. Every layer is justified by "this makes a breach less likely," and the whole stack is justified by "so a breach will not happen." That conclusion does not follow from the premises.
The response that holds
Stop asking how to prevent every intrusion. Start asking what the attacker holds after a successful one.
If the answer is "a complete encrypted archive," you have deferred the loss rather than prevented it. See why that archive is a standing liability.
If the answer is "one shard of a threshold-split file, which is information-theoretically meaningless on its own," the intrusion succeeded and cost you nothing. To get the file, the attacker has to repeat the success against K independent providers, in different jurisdictions, running different software, at the same time, and also obtain your signing key.
That is a bar that does not fall to cheap, patient, automated attempts, because it is not one target being attempted repeatedly. It is K unrelated targets that must fall together.
The uncomfortable part
This framing requires accepting that you will be breached. Security programs are not usually written that way, because it reads as defeat.
It is the opposite. Assuming the breach is what lets you design for the case that actually occurs, instead of optimizing the probability of a case you cannot drive to zero.
Further reading: Why Encryption Is Not Enough.