AI Changed the Economics of External Attacks

For years, the smartest thing a security team could do was decide what not to test.

It was never laziness. It was arithmetic. An external attack surface can span hundreds or thousands of reachable assets, depending on the organization and how you count them. A deep test of one of them, by a person who knows what they're doing, costs days. The budget for that work is measured in weeks per year, and the team that owns it has a whole other day job. You can't walk every path. So you rank: what's internet-facing, what's critical, what touches money or customer data, what would an attacker  plausibly want. Then you work down the list until the quarter ends.

The ranking rested on a simple assumption: attackers could scan broadly, but deep investigation was expensive. Port scans, subdomain enumeration, banner grabbing and mass exploitation of a newly disclosed bug were cheap. Understanding an unfamiliar system, finding an undocumented endpoint, or adapting an exploit to a specific version and configuration took skilled hours. Attackers spent those hours where the payoff looked highest, so they scanned broadly and investigated selectively.

That didn’t make the bottom of the list safe. The quiet corners of the perimeter were only less likely to receive expensive attention. Selective testing was a way to allocate scarce expertise and limited budget, not a judgment that peripheral systems carried little risk.

The prioritization was happening in two places: determining where the testing hours went and deciding which findings got fixed first. They were bundled because the same scarcity drove both. Now they're coming apart.

How AI Makes Targeted Cyberattacks Cheaper

"AI" is too broad to be an argument, so let me be specific about which costs fell. Not scanning the external surface; that was already close to free. What got cheaper is the investigation that used to require  a person: interpreting unusual application behavior, reading reachable JavaScript or source for the endpoint that isn't in the docs, forming a hypothesis about a weakness, adjusting the next request based on the last response, and connecting three unremarkable observations into one path, for example. That's the work that made deep testing scarce, and it's the work language-model agents have turned out to be reasonably good at. And they are only going to get better.

We build offensive agents for a living, and this is what that looks like from our side of it. Enumeration and correlation that took a skilled human a week now runs unattended. Reading an unfamiliar codebase or a minified bundle takes minutes instead of days. Turning a known-but-unexploited CVE into working code against a specific stack, your version, your configuration, your WAF, dropped from weeks to hours. Mass exploitation used to favor generic exploits: when a bug dropped (Hello PHP2Shell), the whole internet got scanned for it, and exploits that needed knowledge of the target got used far less. AI removes that discount. Adapting an attack to your version and your configuration is now cheap.

So coverage stopped being the thing we ration. When investigating one more asset costs a fraction of what it used to, the trade between going broad and going deep loosens. It doesn't vanish. Testing still consumes compute, time and operational capacity, and a production perimeter imposes rate limits and safety boundaries that no amount of intelligence removes. But the frontier moved a long way.

It’s now economically sensible to investigate most of a perimeter and pursue most of the plausible leads, including the ones nobody would have assigned a person to, which is exactly the set prioritization was designed to defer. Our exploits  show what's feasible, not that every adversary has built the same thing. But the economics that protected the bottom of the list are gone.

‍

Every defense assumes some attacks are too costly to pursue. Prioritization bet that the bottom of the list would be left alone, or wouldn't lead anywhere. That bet is losing, not because attackers suddenly want your staging server, but because looking at it no longer costs them anything they care about.

Attackers can afford to investigate far more of your perimeter. Many security programs still operate as though they can't.

Existing Security Testing Tools: What They Find and What They Miss

The industry turned each step of an attack into a product category, and most organizations run several against the perimeter at once. Each is good at its step. The issue is in how they work together, so it's worth being precise about what each one answers.

Discovery and external attack surface management tell you what exists: exposed assets, change over time, ownership and attribution signals, exposed services and likely weaknesses. That's valuable, but not enough. Attribution is hard: cloud infrastructure, vendors, acquisitions, and shared hosting can blur which assets belong to you. But even when an asset is clearly yours, discovery only tells you it exists. It doesn't tell you whether an attacker can exploit it. Visibility gives you a list of places to investigate; it doesn’t answer the security question.

Vulnerability management tells you which known issues match what you're running. It's added context over the years, from misconfiguration checks to reachability analysis and, in some products, a degree of validation, but the output is still a ranked list of things that might be wrong, most of them never tried against your environment. Ask the teams who own that list and most will tell you the same thing: it's mostly noise, and clearing it costs more effort than the findings turn out to be worth. A backlog that grows faster than anyone can close it is actually a risk, not a security control.

Bug bounty comes closest to proof: a researcher has to demonstrate the exploit to get paid. What you can't control is where researcher attention goes. It follows payout, novelty and personal interest, so you can't guarantee that a given system gets looked at, on a cadence you choose. The "cost collapse" that this article is about has reached researchers too. In early 2026 the curl project stopped paying bounties after a flood of low-quality, often AI-generated reports pushed its confirmed-vulnerability rate below five percent and made triage the dominant cost of the program. More submissions is not more coverage.

The annual pentest asks the right question properly, with proof, and a skilled tester's judgment about what matters is still worth paying for. The limit is economic: engagements are scoped in advance, run periodically, and can't apply that depth evenly across a perimeter that changed between the kickoff call and the report.

Each of these solutions answers a legitimate question. The problem is assuming their answers add up to coverage.  They overlap heavily where visibility is easy and leave the same gap where it isn't: is there a route from outside into something that matters, does it work right now, and can you show it rather than infer it from a version number?

Exploitation testing isn't new; the pentest does it, bug bounty does it, a growing set of validation products attempt it. What has been hard is doing it continuously, with real depth, across the whole of a perimeter that keeps changing. Until recently that wasn't a question of will. It wasn't economically possible.

How AI Is Expanding Your External Attack Surface

AI didn't only lower the attacker's costs. It lowered the cost of building things, and a lot of what gets built is reachable from the internet.

The set of people at a company who can put something online has widened. It used to be engineering, through a pipeline, with a review somewhere in it. Now a product manager builds an internal tool with a coding assistant over an afternoon and deploys it to collect feedback. Sales ops wires an agent into the CRM. A designer publishes a prototype with a live API key in it. Not every organization allows that, and not everything built this way is insecure. But the rate of creation has outrun the processes that depend on someone telling security what exists.

Much of what's being built is also a kind of system the inventory process was never designed for: agent endpoints, MCP servers, LLM-backed customer-facing applications, SaaS-to-SaaS integrations holding long-lived tokens. An endpoint that accepts requests isn't a vulnerability. The concern is that these systems are reachable while holding permissions, credentials, tool access and the ability to trigger downstream actions, so a weakness in authentication, authorization, isolation or configuration converts directly into an attacker acting with the system's own privileges. An agent's purpose is to take instructions from outside and act on them. Reachability is the feature, and it raises the stakes of every control around it.

The surface also turns over faster than it's measured: preview environments per pull request, infrastructure that lives for the length of a job, DNS left pointing at a vendor after a campaign. A monthly snapshot captures what persists and misses what doesn't. Refreshing discovery more often narrows that blind spot without closing it, because no fixed cadence catches everything; the useful direction is discovery that refreshes often, listens to change signals where infrastructure telemetry provides them, and retests when something relevant moves. The exposure that mattered may have lived for six hours on a Tuesday, and there's no reason to believe an attacker's interest correlates with longevity.

How to Modernize Security Testing in the AI Era

There are three critical things that must change.

Continuous, not periodic. Continuous doesn't mean scanning a static inventory more often. It means refreshing what you know exists, not just what you know about the things already listed, and testing often enough, and responsively enough to relevant change, that the blind spots of periodic assessment shrink to something you can live with. Infrastructure changes asynchronously and no cadence guarantees visibility. That's a reason to be driven by change rather than the calendar, not an argument for giving up. The adversary isn't running on a schedule, and there's no good reason your testing should be the only thing that is.

Proven, not scored. Proven means the exploit ran, against your live environment, under control, and you can see where the path ends. Only exploitation, not just mapping, tells you whether it opens. Proof changes what a finding means: exploited, here's the chain, here's where it ends outranks a hundred criticals behind a service nothing can route to. But proof establishes what worked, under specific conditions, at a specific moment. It doesn't tell you the full business impact, the complete set of ways in, or that nothing else is wrong. Use exploitation to establish whether a meaningful path works; use risk and business context to rank the fixes.

Revalidated, not resolved. A ticket marked resolved doesn't actually prove anything about the system. Revalidated means the same exploit was run again after the fix and the path no longer succeeds under the conditions tested. That's narrower than "the weakness is gone": a different path may exist, a related flaw may remain. But it answers the question that matters operationally, whether the change altered the system's exploitable behavior, and it requires the ability to attack on demand, a different capability from the ability to detect. Detection was the hard part when investigation was expensive. The bottleneck has moved to the unglamorous end: finding the owner, making the change, and confirming the path is gone rather than relocated.

Which brings the earlier distinction back. Remediation should still be prioritized; nobody can fix everything at once. What should change is the assumption that testing has to be rationed the same way. You only tested a shortlist because testing was expensive. It isn't anymore. The new approach should be broad, continually refreshed testing feeding risk-ranked remediation. And none of it stops at the edge of the external surface: an attacker doesn't re-scope at your perimeter, they walk from the external asset into whatever it connects to.

Real-World Security Testing: A Healthcare Attack Chain

Here is one chain from a recent campaign, against a healthcare services company.

The entry. A debug script left on a fax server. Any triage queue would close it as informational, if it got there at all: it leaked some internal file paths and a handful of filenames.

The overlooked detail. The filenames belonged to a document store that would hand a patient's fax PDF to anyone who asked for it by name, and hundreds of thousands of documents sat behind it. The same debug output pointed at a neighboring prior-authorization API, which turned out to paste one of its input fields straight into a database query.

The proof. Through that one field, the agents confirmed read access to a production database with hundreds of tables and more than a million rows of patient, claims and authentication data. And the fax service's upload path would store a file and run it: the agents uploaded a harmless script that computed 6 × 7 and got 42 back from the production host. No login, no phishing. No records were bulk-extracted and no documents were downloaded; the point was made without that.

The lesson. Every piece of this would have sat near the bottom of a priority list: a debug page rated medium, a document store nobody had catalogued, an API only partners were supposed to call. None of them was going to get a person's time, because none of them looked worth it. Together they ran from a forgotten script to production data and code execution. Noticing that they connect used to be the expensive part. It isn't anymore.

What we built

This is why we built our new Continuous External Infrastructure Testing solution. Give it a domain, or a set of domains, IPs and ranges, and our agents expand from there to find the internet-facing infrastructure associated with the organization. Then, within the scope and guardrails you've authorized, they attack it: web applications, APIs, mail and file-transfer servers, VPN gateways, management consoles. Where an attack succeeds, your team gets the finding with the chain and the evidence, not a theoretical exposure dressed up as a result. Where it doesn't, you get a record of what was tested. When a fix lands, the agents run the exploit again to confirm the path is gone. As the perimeter changes, discovery and testing continue.

It isn't a discovery tool with exploitation bolted on. We map the surface because we're about to attack it, not to catalogue it in case someone wants to later.

Interested in seeing it in action? Get a demo today.

‍