Ask any SOC analyst what breaks their morning and you’ll hear some version of the same complaint: a playbook that worked fine last week just failed because a vendor changed an API field. That’s the quiet failure mode of traditional security automation. SOAR platforms promised to end alert fatigue by scripting responses to known threats, but they were only ever as good as the scenarios someone thought to program in advance. The moment a threat looked slightly different from the template, the automation stopped and dumped the problem back on a human. AI security automation is the industry’s answer to that ceiling — and it’s less about adding another tool to the stack than it is about rethinking how a SOC reasons at all.
Table of Contents
Why SOAR Hit a Wall
SOAR automation is deterministic by design. It runs if-this-then-that logic against a fixed set of conditions, which works well for the alerts security teams have seen a thousand times before — a known phishing domain, a flagged IP, a signature match. The problem is what happens outside that box. A genuinely novel attack pattern, or even a minor schema change in a connected tool, can quietly break a playbook without anyone noticing until an alert sits uninvestigated.
This created what people in the space have started calling the SOAR tax: the ongoing engineering hours spent writing, testing, and patching playbooks that degrade the moment the environment shifts underneath them. Teams end up maintaining automation instead of being freed by it. And because building a new playbook for every edge case isn’t realistic, a meaningful chunk of daily alert volume simply never gets a proper look. That’s not a hypothetical risk — it’s the normal operating state at a lot of mid-sized SOCs today.
Agentic AI approaches this differently. Instead of matching an alert against a pre-written script, an AI agent reasons through it — pulling related logs, checking historical context, correlating signals across tools that were never explicitly wired together — and builds an investigation on the fly, the way a human analyst would if they had unlimited time and perfect memory. That’s the real shift: from automation that executes a script to automation that actually investigates.
The Autonomy Spectrum: HITL and HOTL
Here’s where a lot of vendor messaging oversimplifies things. “Autonomous SOC” gets pitched as an all-or-nothing leap, but no serious security team hands an AI system unrestricted authority to shut down production systems on day one. The realistic path is a spectrum, and two terms describe where an organization sits on it.
- Human-in-the-loop (HITL) keeps a person in the direct decision path. The AI agent runs the investigation — gathering evidence, forming a hypothesis, drafting a recommended action — but it stops and waits for a human to approve before anything actually happens, whether that’s closing an alert or isolating a device. This is the right starting posture for high-stakes actions, unfamiliar threat types, and generally for building trust in a new system before letting it run unsupervised.
- Human-on-the-loop (HOTL) flips the relationship. The AI operates independently on well-understood, high-volume alert categories — routine phishing reports, known-benign anomalies — auto-closing what doesn’t need attention and taking small, contained actions on its own, while a human analyst watches the overall picture and steps in only when something falls outside normal confidence thresholds.
The mistake would be treating HOTL as the finish line for everything. Full, unattended autonomy across the board introduces its own failures — a missed true positive can cascade downstream before anyone catches it, and junior analysts who never work through an investigation themselves don’t develop the instincts they’ll need later. The healthier model uses HITL not just as a safety gate but as a training mechanism, letting less experienced staff watch how an AI agent builds its reasoning chain instead of skipping straight to the answer.
The Part Nobody Talks About: Securing the Agents Themselves
This is where most articles on this topic stop short, and it’s the part worth spending real attention on. An AI agent with shell access, database query rights, and the ability to call external APIs is not a passive chatbot. It’s closer to a new employee with real system privileges — except one that can be manipulated through the content it reads, not just through stolen credentials.
If you’ve followed the broader conversation around generative AI risk, you’ll already know about indirect prompt injection — the technique where malicious instructions get hidden inside a document, email, or webpage an AI system processes, tricking it into acting on commands it was never supposed to follow. That vulnerability doesn’t disappear once an agent moves from “chatbot” to “SOC operator.” If anything, it gets more dangerous, because now the agent has the permissions to act on whatever it’s been tricked into doing.
Containing that risk requires infrastructure-level controls that don’t depend on the model behaving correctly — because you can’t fully guarantee that it will. A workable defense-in-depth approach looks something like this:
- Kernel-level isolation. Running agents inside a sandboxed container runtime — gVisor is the commonly referenced example — interposes an extra layer between the agent and the host operating system. If an agent is compromised and tries to execute something it shouldn’t, the blast radius stays contained inside that sandbox rather than reaching the underlying infrastructure. The latency cost of this extra layer is small relative to the response time of most AI inference calls, which makes it a reasonable trade for the containment it buys.
- Credential proxy sidecars. The agent itself should never hold a raw API key. Instead, it sends requests to a small proxy service running alongside it, which validates the request, applies rate limits, and injects the actual credential only at the point of transmission. If the agent container is ever breached, there’s nothing sensitive sitting inside it to steal.
- Network egress restrictions. Even a compromised agent can’t exfiltrate data anywhere if its outbound traffic is locked to an allowlist of known, approved destinations. This closes off the classic “send stolen data to an attacker-controlled webhook” move before it can happen.
- Prompt integrity boundaries. Anything the agent reads from an external, untrusted source — a file, a webpage, a ticket comment — needs to be explicitly tagged as data, not instructions, inside the model’s context. This doesn’t fully solve prompt injection (it’s arguably a structural property of how language models process text, not a bug you patch away), but clear boundary framing meaningfully reduces how often it succeeds.
This matters more in some environments than others. A healthcare organization deploying an agent with access to patient records isn’t just managing a technical risk — an agent compromise there is functionally a compliance failure under HIPAA, with all the reporting and liability that follows. That’s a useful illustration of the stakes, even for teams outside healthcare: the containment architecture isn’t optional hardening, it’s the difference between an incident and a non-event.
Governance Has to Keep Pace
None of this works as a one-time setup. Agent fleets drift — configurations diverge, permissions get added ad hoc, one VM ends up running a slightly different version than the rest. Some organizations have started addressing this by deploying a dedicated audit agent whose only job is continuously scanning the fleet for exposed secrets, permission creep, and configuration inconsistencies. The catch is obvious once you think about it: an agent with enough access to audit everything else becomes an extremely attractive target itself. The fix is the same principle applied recursively — strict, scoped permissions and immutable logs that the audit agent has no ability to alter or delete, so even a worst-case compromise leaves a trail.
Where This Leaves Security Teams
None of this replaces the need for skilled analysts — it changes what they spend their time on. The engineers who used to burn hours patching brittle playbooks are better used doing threat hunting, tuning detection logic, and deciding where the autonomy boundary should actually sit for their environment. AI security automation isn’t a switch you flip; it’s an architecture you build deliberately, one layer of trust and one layer of containment at a time. The organizations getting it right aren’t the ones moving fastest toward full autonomy — they’re the ones being precise about which decisions AI should make alone, and which ones still need a human watching closely.
