Walk the floor at Black Hat this year, and you’ll no doubt hear similar themes on repeat: offensive vs. defensive AI, AI-driven vulnerability discovery, AI-driven automated exploit development, and the rise of identity and authorization attacks exploiting user credentials and access permissions. There is no doubt we are headed towards the eye of the AI hype storm. It will make for a great show.
But here’s what we wish was better understood across our cybersecurity industry, especially about network abuse management: AI didn’t just make attacks faster, it made them wider. And “wider” is efficiently breaking the model most network operators use to handle abuse.
Your attackers stopped scaling up and started scaling out
Let’s start with a number many will quote and quiver from at Black Hat. CrowdStrike’s 2026 Global Threat Report put average attacker breakout time at 29 minutes, down from 48 minutes a year earlier. The fastest case? 27 seconds. Yes, the attackers are moving terrifyingly fast.
But look at what else recent research says, and a second story appears.
Check Point’s AI Security Report 2026 documented a single operator who breached nine government agencies. Roughly 1,100 typed prompts became more than 5,000 AI-executed commands across hundreds of servers. One person, running commands that used to take a full team to execute. In parallel, no less. KELA’s 2026 threat research shows the same shift across the whole attacker ecosystem: self-hosted open-source models have made machine-speed intrusion a commodity, and the gap between a vulnerability being disclosed and a working exploit has shrunk from months to minutes.
The identity layer tells the same story from the other side. Palo Alto Networks’ 2026 Identity Security Landscape found machine identities now outnumber humans 109 to 1 in the average enterprise — up from 82 to 1 just a year ago. Ninety percent of organizations reported at least one identity-related breach in the past year. Every one of those API keys, service accounts, and AI agents is a credential that can be stolen and operated at machine speed, without ever tripping the anomaly detection built around human logins.
Take a moment and think about what that means if you run a network, a carrier, a hosting estate, or a cloud platform.
Every hijacked machine identity, every autonomous agent probing your address space, every AI-generated phishing run pushed through a customer’s server — each one lands on your infrastructure as an abuse event, an outbound spam burst, an IP range drifting toward a blocklist, and a complaint queue that grows while your team sleeps.
Attackers scaled out. The abuse signal hitting your network scaled with the number of them.
And for you trying to fend off network abuse, that signal has a unit of measurement: engineering hours. The parsers, the ticket scripts, the internal tooling your team maintains reluctantly — all of it was sized for human-speed abuse, but none of it was sized for adversaries who went wide.
Why can’t a SOC model run an abuse desk?
The security industry’s answer to machine-speed attacks is depth. Blue teams live by breakout time — the window between first compromise and lateral movement — and race to detect and contain it. Platforms from vendors like CrowdStrike and Palo Alto Networks are built for exactly this: take a thousand alerts, surface the five that threaten the crown jewels, investigate those five exhaustively. For defending a single enterprise, that model is right.
For a network, it’s the wrong model.
A SOC can rationally ignore 995 alerts, because its job is protecting one organization’s assets. Your abuse team can’t.
Every one of those thousand signals is a real event on infrastructure you’re responsible for:
- A customer compromised
- An IP range sliding onto a blocklist
- A spam run damaging your ASN’s reputation with every mailbox provider that sees it.
Triage down to five, and the other 995 don’t disappear. They compound into reputation damage, peering friction, compliance exposure, and a backlog someone inherits at 2 a.m.
This is why one of the most common mistakes we see is running your abuse teams like a SOC team. Very skilled, but it comes with the wrong mental model. SOC teams are trained to go deep on a few signals, but the abuse teams’ job is to resolve all. The instinct becomes to produce predictable architecture: more investigation tooling, more analyst headcount, deeper queues. But the queue still ends up growing.
And you have to ask yourself: Would you accept a monitoring system that watched 0.5% of your links, as long as it watched them very closely? You wouldn’t. You’d never run your NOC that way. There’s no reason to run abuse handling that way either.
What you want to do is find the signals that matter across everything, instead of maximizing the depth of a few investigations. Breadth over depth, with automation. You no longer have to make the compromise on that. Today, it’s entirely possible to properly handle every alert that needs handling. Depth is what your humans add on the rare event that genuinely needs judgment and intervention.
Building the blueprint to architect abuse handling for breadth
There are five easy steps you can take to help you close the gap in your network abuse management automation. It is not a hiring plan, it’s an engineering program fueled by automation:
- Measure coverage, not investigation depth. Change the primary metric from “how thoroughly did we handle our top incidents” to “what percentage of abuse events on our network were detected, attributed, and resolved.” If you make coverage your breakout time, you will have the one number that tells you if and how the architecture works.
- Audit the engineering load of your current tooling. List every parser, script, and ticket workflow your team maintains for abuse handling. Price it in engineer-hours per quarter. That’s your honest build-versus-buy baseline, and in most estates we see, it’s the line item nobody has ever totaled.
- Automate ingestion end to end. Abuse reports arrive as ARF, X-ARF, unstructured email, and feed data. Turning that mess into structured, attributed events is a solved problem. It should cost you zero ongoing engineering capacity. If your team still writes parsers, that’s capacity taken straight off your roadmap.
- Resolve by policy, not by analyst. Define remediation policies per event class — notify the customer, throttle the port, suspend the resource, escalate — and let automation execute them. Machine identities attack at machine speed. Policy execution is how you answer at the same speed, across every event instead of just your top five.
- Reserve your engineers for what differentiates you. Ingestion, enrichment, threat intelligence, policy execution. Every operator needs these layers, and nobody wins by building them in-house. Adopt them as a platform that plugs into your stack through APIs, and keep your engineering capacity for the network itself.
Breadth over depth, automated
Every trend line points the same way: more autonomous attackers, more machine identities, more simultaneous events across every estate. The operators who re-architect for breadth now will absorb that curve. The ones who keep scaling triage will learn that no amount of analyst depth outruns an adversary who went wide.
The red team side of this story will be everywhere at Black Hat. If you want to talk about the operator’s side — the breadth problem, and what it means for your stack — our Director of Corporate Development, Larry Ellis will be at Seabreeze Cafe during the event, and he’d genuinely like to hear how your team is handling it. He’ll buy the coffee. Let him know you’re coming here: Book a Meeting with Larry.
