AI Cybersecurity: How Attacks Are Changing and What to Do
AI is lowering the cost of cyberattacks and speeding up exploitation. Learn what’s changing and how to strengthen security without handing control to bots.
AI Has Changed the Economics of Cybersecurity. Here's the Response
For decades, cybersecurity teams have dealt with a lopsided game: attackers only need one opening, while defenders have to cover a lot of ground. AI is tilting that balance by speeding up and cheapening parts of the attack process. It can help spot vulnerabilities, draft exploit code, and investigate targets faster than many attackers could manage before.
That doesn't mean every organization is one breach away from doom. The more immediate issue is simpler - and less cinematic: attackers can automate more of the work, while many companies still rely on slow patch cycles, understaffed security teams, and approval processes built for a different threat environment. As Alex Stamos has argued, we're likely in for a rough transition, not a neat future where security is "solved."
This piece looks at what AI changes in the attack chain, why the old economics of defense are under pressure, and what organizations can do right now. This is not a call to hand control to autonomous agents. The point is to lower the cost of defense, cut response times, and make security decisions that hold up in real operations.
How is AI changing the cyberattack process?
A traditional cyberattack typically follows a set of steps: identify a target, research how its systems work, find a weakness, develop a way to exploit it, then use the access to reach a goal. People often call this an attack chain (or kill chain). AI doesn't invent every step, but it can make several of them faster and easier to scale.
The impact shows up because attackers have historically needed scarce expertise to turn a general tool into a repeatable operation. A researcher might uncover a vulnerability, while another team handles deploying it across many targets. AI can reduce the specialized time and knowledge required for some of that work. As Stamos described in an interview with The Verge, systems can inspect targets and try to find and exploit weaknesses in a more continuous way.
Automation matters more than the word "agent"
It's tempting to imagine hundreds of autonomous bots swarming a network. Reality is usually less dramatic. Even a small number of automated processes can be enough to create real pressure. A system that checks exposed services, tests common weaknesses, and adjusts what it tries next can increase the number of attempts an attacker can make without growing the human team.
For planning, that distinction matters. You don't need to assume every attack is a self-directed, AI-run operation. But you do need to assume that parts of reconnaissance, vulnerability discovery, and even exploit development may become faster and more accessible. In many cases, humans still choose targets, make key decisions, and monetize access.
The attack chain can become more continuous
Older operating models often separated "research" from "execution." An attacker might develop a tool, then deploy it later against a chosen set of targets. With AI-assisted systems, discovery and exploitation can happen closer together: the tool examines a target, tests what it finds, and tries to act while the opportunity is still there.
That shortens the window defenders have to respond. A patch only helps if an organization can (1) notice the vulnerability affects it, (2) apply the fix, and (3) verify that the exposed service is no longer exploitable. If exploitation speeds ahead of those steps, even a reasonable patching plan may not be fast enough in practice.
So the takeaway isn't "AI guarantees attacks." It's that organizations should plan for more attempts, faster discovery, and less warning between exposure and exploitation. Security programs built for a low volume of expert attackers may struggle with the volume and pace they now face.
Why does AI disrupt the economics of cybersecurity?
Security has always been both a technical and an economic problem. Companies have to decide what to spend on prevention, monitoring, incident response, and recovery. Attackers, meanwhile, try to make each attempt cheaper - and more profitable. AI adds pressure to that equation by making some offensive tasks easier to scale.
The gap is especially tough for mid-sized organizations. A company with a small IT team may be defending complex infrastructure against attackers who can share tools, specialize in one part of the chain, and pursue many targets. Stamos has highlighted what ransomware can do to less visible suppliers: an incident at one company can ripple into downstream services like medical and dental supply distribution. The victim may not be a household name, but the disruption can still hit customers well beyond the victim's own network.
Defense still has substantial operating costs
On the attacker side, AI can mean cheaper compute and easier repeat testing. On the defender side, it means wading through logs, investigating alerts, confirming which systems are actually affected, and doing all of that without breaking normal business operations. People and infrastructure still matter, and the choices still have to be careful.
That's why "just use a more powerful model" doesn't solve the real problem. Stamos has noted that continuously analyzing huge streams of operational data with frontier models can be too expensive. Teams need cost-effective systems that can do high-volume filtering first, then send the strongest signals to more capable models or to human analysts.
The same logic applies to vulnerability management. Running a costly model against a small set of critical code may help - but many organizations also depend on large, less visible software footprints. If AI security tools are affordable only for a narrow slice of high-profile code, they won't cover the full exposure.
A lower attacker cost does not make defense impossible
There's no moment where every vulnerability disappears. Incidents come from stolen credentials, human error, misconfigured services, compromised suppliers, and other failure modes - not just software bugs. Even "perfect" code can't close every route into an organization.
What the economics can change is the balance in the defender's favor where it makes sense: reduce the odds that routine attacks work, shorten the time an attacker can stay undetected, and make recovery less damaging. That points toward prioritizing controls that prevent repeatable failures, not flashy one-off demonstrations of sophistication.
Key takeaways
- AI can increase the volume and speed of attacks without every attacker becoming an expert.
- Monitoring and response costs still limit what defenders can do.
- Security spending should be measured against operational risk, not just how many vulnerabilities show up in reports.
- Smaller suppliers and unremarkable internal systems can have outsized business impact.
What should organizations do to defend themselves?
First, stop treating vulnerability scanning like the entire security strategy. Yes, finding and fixing code defects matters - but it's only part of the job. Organizations also need to understand what assets they have, detect suspicious activity, respond quickly, and test whether controls actually work under realistic conditions.
A solid place to start is a simple operating loop: inventory, prioritize, test, fix, verify. It's not magic, and it's not new - but each step closes a gap between a security report and real risk reduction.
1. Build an inventory that reflects reality
If you can't account for a system, you can't protect it. Include cloud accounts, internet-facing applications, APIs, software repositories, service accounts, vendor connections, and temporary sites created for campaigns or events. The forgotten test environment - or the long-neglected marketing site - can be easier for an attacker to reach than a carefully maintained production setup.
Assign an owner to each asset and note what business function it supports. That helps you decide what to investigate first. A vulnerability on a system that can interrupt payroll, patient care, or production should trigger a different response than an issue in a low-impact internal tool.
2. Prioritize exposure and consequence
A long list of reported bugs isn't a risk plan. Prioritize by looking at at least three things: whether the system is exposed, whether the weakness is being actively exploited (or is straightforward to exploit), and what happens to the business if it's compromised.
Pay extra attention to identity systems, cloud control planes, software build pipelines, and third-party integrations. A stolen API key or vendor credential can bypass your assumptions about how "safe" your own application is. Rotate exposed secrets, tighten permissions, and remove credentials that no longer have a clear owner or purpose.
3. Test your defenses before an attacker does
AI-assisted red teaming and penetration testing can uncover weaknesses, but testing itself can cause damage if it's handled badly. A tool with the wrong scope can lead to downtime, alter data, or trigger incident procedures. Before you run anything, define what systems are in scope, what actions are allowed, time windows, data handling rules, escalation contacts, and stop conditions. Also make sure the vendor contract matches what the sales team promised.
If a vendor's controls or liability terms are unclear, start small in an isolated environment or a tightly limited test. You want to learn where defenses fail without turning the test into an outage. Don't let procurement delays stop you from testing - but don't confuse urgency with permission to try unknown tools on production.
4. Fix the underlying system, not just the latest finding
Constantly patching fragile, outdated software can end up costing more than replacing or refactoring it. If a codebase keeps generating a recurring backlog of serious defects, compare the ongoing cost of patching with the cost of rebuilding a defined component - with strong tests and clear requirements.
That's not a blanket "rewrite everything" recommendation. Rewrites create their own risks: migration failures, missed behavior, and new defects. They make sense when the scope is bounded, the system can be tested, and long-term maintenance cost is clearly higher. Memory-safe languages, stronger types, and better automated tests can reduce certain classes of defects - but they still don't remove the need for secure design and solid operational controls.
How can companies use defensive AI without losing control?
AI can help security teams handle more signals than people can review manually. But giving a model unrestricted authority over identity, cloud infrastructure, or production systems creates a different risk. A defensive system that mistakenly locks out staff or disables critical services can still cause real damage, even if its intent is protective.
A safer approach is layered automation: low-cost, predictable systems filter high-volume data; more capable models investigate a smaller set of alerts; and human operators review high-impact decisions. Traditional classifiers and other lightweight techniques can handle first-pass log analysis. Then a language model can summarize evidence, correlate activity, and recommend next steps when context actually matters.
Give automation a defined permission boundary
Avoid the "autonomous or nothing" framing. Spell out what actions the system can take, which assets it can touch, and what limits apply. For example, an automated tool might disable a small number of suspicious accounts, but require human approval before it blocks an entire department or changes production infrastructure.
Useful guardrails include:
- Least privilege: Give the tool only the permissions required for its defined task.
- Action limits: Cap how many accounts, machines, or services it can affect without approval.
- Auditable decisions: Record the evidence, action, and system identity for each intervention.
- A stop mechanism: Ensure operators can pause automation without relying on the model to comply.
- Escalation rules: Require human review when confidence is low or potential impact is high.
These controls aren't just paperwork. They let you test automation without betting the business on a model behaving correctly in every odd corner case.
Design for the cost of investigation
An alert isn't useful just because a model can generate it. Security teams need to know what an investigation costs, how often it leads to a real finding, and how long it takes to get from alert to action. If every alert triggers a pricey model call, the system won't scale.
Track false positives, investigation time, cost per confirmed incident, and time to contain. Use that data to decide what to automate and what should stay with analysts. A cheaper model that handles initial triage well can be more valuable than a larger model that looks impressive but can't run across the organization's full workload.
Make red teaming operational, not performative
Testing matters, but it doesn't help if the outcome can't be used. Assign findings to named owners, set deadlines, and verify the fix. If a test uncovers a weakness, confirm the fix in the affected environment and check whether the same pattern shows up elsewhere.
The principle is simple: automate repetitive analysis when the action is bounded, and involve humans when the decision carries real consequences. That gives teams speed without pretending a model can safely make every call on its own.
What does the AI security transition mean for trust and technology?
AI's security impact goes beyond code and corporate networks. Synthetic voices, images, and text can make impersonation more convincing, while ordinary phishing still works because it targets trust and urgency rather than a technical flaw. A message that looks like it came from a coworker, supplier, or family member can pressure someone into sharing credentials or approving a payment.
That creates a verification problem. Detecting fake media after the fact is hard - especially as generation quality improves. In some settings, it may be more reliable to verify where trusted content came from than to assume that all synthetic content can be reliably identified. For instance, a platform could keep provenance for media captured and edited in a controlled workflow. It won't solve every case, but it's a stronger signal than an "AI detector" label that often misses the mark.
For businesses, the equivalent is setting up trusted channels and solid approval procedures. Confirm unusual payment instructions through a second channel. Use phishing-resistant authentication for high-impact accounts. Require extra verification before changing supplier bank details or granting access to sensitive systems. These controls work even when a message sounds natural or a video looks convincing.
Avoid both panic and false confidence
Stamos's "dark age" framing points to a gap between capability growth and how quickly institutions can adapt. It's a warning, not a prophecy that every organization will fail. Better tools can also help defenders fix defects, analyze incidents, and improve systems that were previously too expensive to upgrade.
Measure progress in operational terms: fewer severe incidents, shorter exposure windows, faster containment, and fewer recurring defects in critical software. An initial spike in patches or AI findings can also reflect better detection - not necessarily worse security. The real question is whether organizations are reducing underlying risk faster than new exposure is piling up.
Longer-term, this is as much organizational as technical. Leaders have to fund prevention before a breach makes the cost obvious. Security teams need authority to test systems safely. And AI developers have to plan for misuse - not just intended product use. No single model, regulation, or rewrite will carry that burden by itself.
Conclusion
AI is changing cybersecurity by lowering the cost of some offensive work and increasing the pressure on organizations that already struggle to monitor, patch, and respond quickly. The right response isn't to assume attackers have unlimited autonomous swarms, and it's not to hand over unrestricted control to defensive bots. It's to improve the economics and execution of defense.
That means building a reliable asset inventory, prioritizing issues based on exposure and business impact, testing within clear boundaries, and using automation with explicit limits. If old software keeps producing serious risk, compare the cost of rebuilding it with the cost of patching forever.
Security won't become perfect. The goal is more grounded: reduce the opportunities attackers can exploit and recover faster when something slips through. Start by identifying what your business can't afford to lose, then make sure each critical system has an owner, a tested response plan, and a realistic path to remediation.