TL;DR
- The AI poverty line is the gap between security teams that can use AI well, and teams that can’t. Skill alone won’t get you above it; you also need the token budget, organizational authority, and tech stack to put AI to work.
- Cybercriminals crossed the line first, and they pay less to stay there. Running an attack takes fewer tokens than defending against one. AI-assisted reconnaissance, phishing, and exploitation shrink the window between initial access and real damage, which puts teams responding at human speed at a structural disadvantage.
- A security operations center (SOC) that adopts AI well sends more judgment calls to analysts. AI absorbs the routine work and raises the volume the team can handle, and what’s left needs human context.
- Every automation decision is a risk decision. AI automation is less predictable than traditional automation—a model update can change behavior, and the same input can produce different outputs from one run to the next. Weigh the risk of an automated action going wrong against the risk of an attacker moving freely while a human waits to approve a response.
The AI poverty line is the growing divide between security teams that can use AI effectively and security teams that can’t. The cybersecurity poverty line is mostly a budget problem, but the AI poverty line is a skill problem, and a budget problem, and a tool availability problem, which makes it harder to see (and much harder to fix with money).
Wendy Nather coined the term cybersecurity poverty line to name the point below which an organization can’t be effectively secured. Fifteen years later, our CTO Greg Notch thinks a second line is forming above it, and this one will be harder to climb.
“The AI poverty line will be even crazier in some ways because you will either have the ability to understand and wield AI properly or you will not,” he told host Brad LaPorte on a recent episode of The Security Strategist podcast. “That gulf is going to be interesting.”
How the AI poverty line differs from the cybersecurity poverty line
Two teams can buy the same AI-backed tooling in the same quarter. One team knows what alerts to route through it, where its judgment is unreliable, what confident but wrong looks like, and who owns the call when the model gets it wrong. The other team turns it on and hopes for the best.
Six months later, the tools used are identical, but each team has a different judgment system for knowing when AI is correct.
Big tech companies get to solve this with headcount. A CrowdStrike, a Palo Alto, a Microsoft can hire AI-skilled engineers and build tooling around them. Greg’s point is that most security teams can’t hire their way there. “If you can’t hire enough people to run the operation, you end up outsourcing that skill to someone who has it.”
Attackers are already above the line
The reason this matters now—and not in three years—is that adversaries are aware of the line, too. Bad actors use AI to speed up reconnaissance, write phishing lures that read like a real coworker wrote them, and automate the exploitation steps that used to take a person an entire afternoon. The tooling is cheap and the learning curve is short. That shift is why we track AI as its own attack surface, rather than a feature of the others.
As the window between initial access and real damage keeps shrinking, teams that respond at human speed are trying to fight a submarine from a canoe. Automation on its own doesn’t close that gap, because a team that automates without understanding what it automated has just built a faster way to be wrong.
The SOC of the future: Human oversight, not action
There’s a version of this conversation where AI eats the SOC, the analysts go home, and the alerts triage themselves. Greg doesn’t buy it, and neither do we, which is why we think the AI SOC debate keeps missing the point.
When asked what a SOC without analysts would even look like, his answer was short: “I believe we’ll have humans in the loop to oversee it, rather than acting in it.”
That sounds backward until you work through the mechanics. AI raises the volume and complexity of work a team can take on, and the routine work gets absorbed. What’s left is the judgment—and partially. Some of those more predictable calls will be outsourced too, to AI and agents qualified for the job. Instead of reviewing individual incidents one-by-one, people will begin to focus on reviewing and validating the overall loop, looking to improve the system itself, instead of just resolving individual alerts.
LaPorte’s framing on the show stuck with us:
“It’s like a motorcycle with a sidecar. The human is riding the motorcycle, but the AI is along for the ride. It adds additional capability, additional storage and functionality. It’s a new world, but it’s a hybrid world.”
The person is still steering. That’s the whole design of human-led, AI-powered security operations, and it’s why we built Ruxie, our AI SOC manager, as AI in the human loop. Ruxie enriches and triages alerts before an analyst touches them and documents what happened, so analysts make the (educated) calls that carry consequences, faster.
Every automation decision is a risk decision
Most teams stall on automation because they’re asking whether it’s safe. Greg reframes it as the question a security leader can actually take to a board.
“All security leadership decisions should be grounded in risk. What is the risk of not doing a particular task versus the risk of doing it—for instance—with automation? We’re accepting different risks, but we believe the risk of not being able to stop an active attacker in our environment is worth that. That’s the trade-off you have to make.”
Let’s run that math on a compromised laptop. Option one: Automation isolates the host in seconds and, sometimes, it isolates a host it shouldn’t have. Option two: An attacker moves laterally for 40 minutes while a Slack message waits for someone to wake up and approve a containment action. Both options carry risk. One of them is a bad afternoon for one user. The other is an incident report.
Some actions are clear candidates: blocking a known malicious IP, containing a compromised device, or cutting off an infected endpoint before it spreads. The blast radius is well understood and the window is measured in minutes.
Automation buys something quieter too, and it’s just as real. Analysts drowning in alerts that mostly turn out to be nothing burn out, and they leave. Filtering the routine work is one of the most direct ways to improve how a SOC actually performs, because it protects the people you’d struggle to replace.
Trust is the thing you have to earn first
We have some history here. Expel shipped auto remediation seven or eight years ago, built on heuristics, well before anyone in this market was calling it AI.
The hard part was asking customers to let an outside provider take action inside their environment and do things like isolate an infected laptop, shut down a compromised cloud system, or kill a malicious process, all without waiting for someone on their side to click approve.
Nobody hands that over on day one. It got built the slow way, by showing customers exactly what we did and why, every time. Today the posture has flipped. Most enterprises would rather have the attack contained now and read the investigation afterward.
Which is also why we published the Trust vs. Impact framework, which is a way to sort tasks by how much you trust the system to get it right and how bad it is if it doesn’t. Some tasks automate fully. Some keep a human in the loop, and some shouldn’t be automated yet; the point is to decide on purpose instead of by default.
How to get above the AI poverty line
There are a few things worth doing, regardless of the size of your team, to stay above the line:
- Pick your automation candidates by blast radius. Start where the action is reversible and the window to act is short.
- Write down what your AI tooling is bad at. If nobody on the team can answer that, you don’t understand the tool well enough to trust it yet.
- Name the owner for every automated action. AI can’t testify, can’t take responsibility, and can’t explain itself to your board. A person has to.
- Buy the skill you can’t hire. A managed detection and response (MDR) provider that already runs AI operationally, at scale, is a faster path above the line than a hiring plan you won’t fill. Ask them to show you what their automation did last week, on real incidents, with timestamps.
The AI hype has oversold most of this. AI won’t fix a broken process, and false positives aren’t going anywhere. It will make a good team meaningfully faster, and it will leave a team that hasn’t done the work behind.
Watch the full conversation with Greg Notch and Brad LaPorte on The Security Strategist podcast.
Frequently asked questions
What's the difference between the cybersecurity poverty line and the AI poverty line?
The cybersecurity poverty line, coined by Wendy Nather, describes organizations that can’t afford the tools and staff to be effectively secured. It’s a resource problem. The AI poverty line describes organizations that have AI tooling but lack the skill to use it well, which is knowing what to route through it, where its judgment fails, and who owns the decision when it’s wrong. Two teams with identical budgets can land on opposite sides of it.
How do you know if your security team is below the AI poverty line?
Ask your team what your AI tooling is bad at. A team above the line can answer specifically, with examples of alert types where they don’t trust the model’s verdict. A team below the line either can’t answer or says “nothing.” The second answer is the more concerning one, because it means nobody has tested the boundaries of a system that’s already taking action in production.
Which SOC tasks should you automate first?
Start with actions that have a well-understood blast radius, a short window to act, and a reversible outcome, such as blocking a known malicious IP, containing a compromised device, or isolating an infected endpoint. Leave decisions that need business context—like whether an unusual admin login is an incident—with a human. Expel’s Trust vs. Impact Framework sorts tasks along those two axes.
Who's accountable when an automated security response gets it wrong?
A named person on your team, and that has to be decided before the automation ships. AI can’t testify, take responsibility, or explain a decision to a board or a regulator. Every automated action needs a documented owner and a record of what the system did and why, which is why we surface every action Expel takes in Workbench.
