What SOC Automation Actually Means Today, Plus How to Do It In Your Organization
A practical guide to SOC automation — what it means today, why it often fails, and how Legion helps teams automate without integrations.
TL;DR: SOC automation is designed to help organizations automate manual, repetitive tasks, but it’s not always straightforward to implement said automation. SOC automation projects can stall for reasons including teams lacking the skills or time needed to build workflows, automation tools not having the required integrations, and analysts not trusting the output they can’t inspect. Legion automates your SOC by learning your workflows, watching how your analysts actually investigate, combining those insights with logs, cases, and more, then running proven workflows with autonomous operations.
SOC automation is on every security leader’s agenda. In a recent report, 61% of CISOs said they are currently investing in automation. Our experience is that the true proportion of CISOs thinking about automation as a solution to problems like growing MTTRs or alert overwhelm right now is closer to 100%.
But deciding to invest in (and even getting a budget for) SOC automation is the easy part.
This guide covers what comes after you get the go-ahead to push for automation. It includes the automation approaches available today, which workflows are worth automating, the reasons SOC automation programs stall, and a practical sequence for implementing one. It also covers how and where Legion fits into a SOC automation project.
>> Short on time and want to see what SOC automation looks like in practice? Watch a 3-minute demo of Legion in action.
What Is SOC Automation?
Modern SOC teams look for agentic automation tools like Legion to actually learn how your team works, pull in context from outside the SOC, and recommend and perform automations that improve how SOCs function.
Of course, automation is not new to the SOC.
At a high level, SOC automation uses technology (including, but not limited to, AI) to perform security operations work that an analyst would otherwise have to do manually. A SOC might want to automate work like gathering context on an alert, running an indicator lookup, opening a ticket, blocking a domain, isolating an endpoint, and writing up the record afterward.
And security teams have been creating their own scripts to automate routine processes and relying on deterministic SIEM automations since at least the late 1990s. Security Orchestration, Automation and Response (SOAR) tools, which automates predetermined playbooks, have been heavily leveraged in SOCs for over a decade now.
But agentic automation is the present and future of SOC automation. It's what enterprises like Virgin Money are using right now to cut alert volumes and support overwhelmed SOC teams.
Learn more about how SOC automation helped Virgin Money reduce its alert backlog by more than 60% in less than two months.
Why Automate in the SOC?
The business case for SOC automation is simple.
Analysts can’t keep up with the number of tasks they have to do on a day-to-day basis, particularly now with the Hugging Face / OpenAI incident indicating fully agentic attacks with tens of thousands of uncorrelated alerts portending that real incidents are getting missed (or spotted too slowly), and breaches happen that should have been stopped.
NIST's incident response guidance (SP 800-61 Rev. 3) notes that the volume of potentially adverse events is generally too high for analysts to review manually, while response speed has to reflect how time-critical an incident is.
Automation helps address both problems by:
- Reducing the amount of routine work analysts have to handle themselves. 35% of security teams say they feel overwhelmed with repetitive manual tasks.
- Allowing investigations and response actions to happen faster. In one study, organizations using AI and automation extensively across security operations shortened the breach lifecycle by an average of 80 days and reduced breach costs by an average of $1.9 million.
But speed and volume are not the only reasons for SOC automation. Automation can also make SOC processes more consistent. With an automation layer in place, the same investigation steps can be followed each time an alert occurs, rather than the process varying depending on which analyst handles it.
This aligns with the broader emphasis on repeatability in NIST CSF 2.0, which describes cybersecurity risk management progressing from “irregular, case-by-case basis” at CSF Tier 1 to “Repeatable” practices at CSF Tier 3.
Does SOC automation replace people?
The short answer is no. The long answer is that SOC automation does change the day-to-day for people who work in security operations. It saves the SOC’s best people from burning out on routine tasks and lets them do the interesting investigative work that requires human insights as well as leading them to become less analyst and more orchestrator, so you can retain them for longer and reduce staff churn.
As MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center puts it: “Automation assists, but does not fully replace, the judgment of advanced human analysts.”
7 Automation Technologies SOCs Use
SOC automation ideally is a collection of technologies that, over time, automate more and more of what security analysts do.
Below are some of the most common approaches to SOC automation.
- Scripts and APIs. Scripting tools like Python and PowerShell can be used to automate tasks that are repetitive. This can be things like looking up an IP address, collecting information from an endpoint, updating a blocklist, or passing information between different security products. These automations can save time, but they also take time upfront because they need to be built and continuous time to be maintained.
- EDR automations. Endpoint detection and response (EDR) is security software that monitors devices like laptops, desktops, and servers for suspicious activity and helps security teams investigate and respond to threats, largely by pattern matching.
- Built-in SIEM automations. Security information and event management (SIEM) platforms collect security data from different systems, compare activity across them, and surface an alert when something matches a predefined rule. Security teams can view and analyze that data in one central place rather than having to check every system (e.g., firewalls, endpoints, servers, etc.) individually. Some modern SIEMs can also automatically take certain actions after they detect a threat.
- SOAR. SOAR platforms take automation even further than SIEMs. They connect different security tools and run predefined workflows (usually called playbooks).
- XDR. Extended Detection and Response (XDR) brings together security data from multiple areas, such as endpoints, email, networks, cloud systems, and identities, to detect and respond to threats across an organization.
- Security data pipelines. Security data pipelines manage security data before it reaches the SIEM. They can automatically collect, parse, normalize, enrich, filter, and route telemetry, helping teams control the volume and quality of data reaching their downstream security tools.
- AI and security agents (Agentic Security Operations platforms). Artificial intelligence (AI) and security agents automate more complex SOC work that previously needed a human analyst to think through and decide what to do. For example, instead of just following a fixed rule, an AI agent might investigate an alert, gather information from different security tools, work out what likely happened, suggest what to do next, and sometimes take action itself.
See how Legion makes SOC workflows repeatable and consistent.
Agentic Security Operations platforms like Legion don’t necessarily replace SIEM, SOAR, EDR, or similar tools but rather work on top of or within those tools, using their data and capabilities to automate more of the analyst’s job.
In one study, three in four analysts reported that AI tools have already made their work more satisfying by reducing alert fatigue and automating repetitive triage.
57% of organizations report success using AI for alert triage and risk scoring, and 26% report success automating incident response.
Tier 1, 2 and 3 SOC Automation Use Cases
A common way to think about automation is by SOC tier.
Tier 1 (triage)
Tier 1 SOC work is where automation pays back the fastest, because the work is repetitive and the cost of an error is relatively low. Learn more about how Legion automates tier 1 SOC tasks.
Common tier-1 and alert triage workflows include:
- Alert enrichment.
- Indicator and reputation lookups.
- Phishing analysis.
- Identity and system context gathering
- Duplicate alert identification
- Alert classification and prioritization.
- Ticket creation.
- Initial false-positive handling.
Automating this type of work also broadens the scope of what can be categorized as Tier 1, because with agents running triage and investigation, security operations centers can take on more noise, more alerts, and worry less about false-positive-burnout.
Tier 2 (investigation and response)
Tier 2 is where analysts move from routine alert handling into deeper investigation and potentially disruptive response actions, so automation needs tighter controls.
An example is rule tuning. Analysts see which detections generate repeat noise, trace it back to the benign activity behind it, and narrow the logic so the rule stops firing on it.
Tier 3 (threat hunting and advanced investigations)
Tier 3 tasks can include running threat-hunting queries, IOC sweeps, cross-environment investigations, hypothesis generation, and advanced forensic analysis.
This is particularly interesting for AI and agentic automation because these investigations do not always follow exactly the same path.
An analyst investigating suspicious authentication activity, for example, may change direction depending on what each query reveals. An agent capable of reasoning across the investigation can potentially do the same rather than relying on one fixed playbook.
But SOC Automation Use Cases Don’t Have to Be Defined By Tier
SOC tiers are a useful way to categorize SOC automation use cases, but the same types of work often appear across different tiers.
A better question is: “What makes a workflow a good fit for automation?”
In our experience, a SOC task is generally a good candidate for automation when it:
- Repeats. Analysts keep doing essentially the same task over and over again.
- Happens across different tools. Analysts work in SaaS consoles, EDR dashboards, legacy systems, cloud panels, and internal portals.
- Needs security context to answer. Someone has to know what the system does, who owns it, and whether the activity is expected or unusual (i.e., judgment that is hard to script).
Why SOC Automation Projects Fail
One of the most common reasons why SOC automation projects fail to deliver value in the enterprise is a lack of skills or time to build workflows.
More than half (52.6%) of organizations cite skills gaps as a barrier to automation, 44% say automation and AI roles are difficult to hire for, and 35% report not having the internal skills needed to build or maintain workflows at all.
Another reason is integration problems. 31% point out integration gaps between tools. If an automation can't access or correctly interpret the information an analyst uses, then it can't reliably replicate the investigation.
Then there’s trust, or lack of it. 47.1% of security leaders distrust automated results. Teams need to be able to see what an automation did and why before they are comfortable with giving it more control.
How Legion Automates The SOC
Legion is the agentic security operations platform that automates enterprise SOC work.
What we’ve found is that most SOC work is repetitive but not yet standardized. Or it might be the case that playbooks exist, but they are likely to have been written by engineers who don’t run the workflow themselves, and they go out of date as soon as a tool or an interface changes.
That’s why Legion doesn’t rely on written process documentation. Instead, we work by learning from what your analysts actually do and combine that with wider context (including documented processes, logs, cases, and more).
We uses vision models to observe how and why experienced people investigate the way that they do, then turn that into a visual workflow the team can inspect and edit. This means there’s no need for you to build API integrations or set up connectors, and Legion can also work with internal tools that have no existing integration.
Every action Legion takes is recorded with the evidence behind it, including screenshots of the actual screens it reads, so you can check how it reached the conclusion instead of trusting that it is correct.
As Neil Robinson, CISO at Virgin Money, put it: "Legion has just completely transformed the way I think about automation. You take your existing operation and really just 10x it."
How to Implement SOC Automation
If we were to advise an organization on how to get automation working (and keep it working) within their SOC, we would suggest the following steps.
1. Decide who owns SOC automation
Traditionally, security engineering teams would build SOC automations for analysts.
The problem with this is that engineers don’t necessarily do those investigations themselves, which means that the automation may or may not reflect how investigations happen in real life. Plus, it leaves analysts dependent on engineering when something needs to be fixed or updated, which creates a bottleneck (this has been a longstanding issue with SOAR tools). It is further exacerbated by the fact that most automation systems require clean APIs, which, particularly for homegrown or legacy systems, simply don’t exist.
There’s also the risk of important knowledge leaving with the person who built the automation. Other people may know what the automation does, but not why it was designed the way that it was. Then, when a security process or tool changes, nobody will know how to update it, and the automation will be abandoned.
The solution is automation owned by analysts. The people who run the investigations should be able to build and update their own automations, they should incorporate ALL tools in the enterprise, and be able to document the reasoning behind each one so that knowledge stays with the organization even when people leave.
Legion is built specifically for this. Analysts create workflows by doing investigations they normally would, without writing any code or integrations, and what comes out is a visual map they can inspect and edit themselves, so updating it doesn’t mean going back to engineering.
2. Record how SOC work is done now
Before you automate your SOC tasks, you first need to understand how analysts actually perform them.
One way to do this is to ask analysts to write down each step they take. We don’t recommend it because what analysts write and what analysts do might be different:
- Small steps can be forgotten.
- Two analysts can describe the same workflow differently.
- The document goes out of date as soon as a tool or interface changes.
A far better approach is to record analysts in real time. That’s what Legion does. It observes analysts while they work, capturing how they investigate alerts, which tools they use, what steps they take, and the decisions they make, then turns these into a workflow diagram that also incorporates best practices and optimal processes that the AI creates so you can reduce inefficiencies created by the ‘duct tape and thumbtack’ approach that is often the status quo.
You get two things at the end of this: a) the actual sequence of steps analysts follow, which you can then automate, and b) a view of how the team works, i.e., which tasks are most time-consuming, where investigations get stuck, and where analysts approach the same situation differently.
3. Choose the first SOC automation candidate
Once you know how your team works, you can then decide which workflow to automate first.
Choose one workflow to begin with, ideally something that analysts deal with frequently and investigate roughly the same way each time.
A good example is phishing alerts. Security teams typically receive a lot of phishing alerts, and the investigation usually follows a fairly standard process, i.e., check the email, inspect links and attachments, look at the sender, determine whether it’s malicious, and decide what to do next.
Leave the more complex cases that depend heavily on human judgment until you’ve built up confidence in your automation process.
4. Map where the context lives
Identify which systems have the information analysts need for their investigations.
For instance, an analyst investigating a suspicious activity might need to check the user’s identity and permissions, information about the affected device, previous incidents, or email records. This information could be spread across several different systems.
Then, make sure that automation can actually retrieve and use this information when it needs to. Traditional SOC automation usually connects to tools via APIs, which can exclude internal or legacy systems that don’t have them, so analysts might still have to perform missing steps manually.
On the other hand, a browser-based automation platform like Legion can access the exact same information that analysts can.
5. Baseline the workflow before you automate it
Measuring how much time a workflow takes before you automate it allows you to later prove that the automation actually saved time.
The calculation is simple:
Time spent = alert volume x handling time per alert.
For example, if your team gets 100 phishing alerts a week and each alert takes 10 minutes to investigate on average, that’s about 1,000 minutes of analyst work. After automation, you can measure that exact same workflow again and compare the number.
6. Whitebox auditability is key
Legion is fully white box, so you can deploy it right away. There’s no supervised on-ramp required, because you can see exactly how it thinks from the start. Every action, every piece of context, and every conclusion is fully visible and editable, never a black box you're asked to trust blindly. That's what makes it predictable immediately: you know why it reached a verdict, you can correct it on the spot, and it'll apply that correction consistently from then on.
7. Expand to other SOC workflows
Once you get one workflow running successfully, start automating another one by taking it through the same process - observing how analysts do it, building the automation, supervising it, and only then considering making it autonomous.
Automate Your SOC with Legion
Ready to automate your SOC? Get a demo of Legion today.
Legion’s agentic security platform is built on a simple idea: your team knows how to investigate, but it is knowledge that is one of the most valuable and unique things your SOC has. Legion captures how your analysts work, all the way from an alert, to the steps they take to the evidence they gather and the reasoning behind each verdict, and turns it into agentic investigations that run the same way every time.
But that context should not stay locked inside a single console for knowing analysts. Security teams increasingly do their thinking in AI assistants like Claude and ChatGPT, whether they're drafting an incident summary, preparing for a leadership update or trying to remember whether they've seen an indicator before. That's why we offer our customers the Legion MCP server, which connects those assistants directly to your Legion data through the Model Context Protocol. With this, security teams can ask questions about their investigations in plain language, from the tools they already use every day, and get answers grounded in what Legion actually did.
What your team can ask
Once Legion is connected, an analyst or security leader can pull up the full story of an investigation without leaving their conversation. They can find sessions by title, summary or entity, filter them by status, decision, workflow, analyst or date, and walk through each step along with the verdict it reached. They can also see which workflows and use cases are running, check how much of their monthly action allowance has gone to guided versus autonomous runs, and get answers about Legion itself from our documentation, with links back to the source pages.
In practice, that means questions like these:
- "Summarize our Legion sessions from the last 24 hours: what failed, what's still active, and which were decided true positive."
- "Open our most recent phishing investigation and walk me through each step, the entities it found, and why it reached its verdict."
- "Have we investigated 203.0.113.42 before? List every session that mentions it, with dates and outcomes."
- "Which workflows ran most last month, and what use case does each belong to?"
- "How close are we to our action limit this month? Split it by guided and autonomous runs."
- "How do I set up a Jira poller so new tickets trigger a workflow? Cite the docs."
Because the answers come from your own investigations, the assistant isn't guessing at how your SOC handles an alert. It's reporting what your team's process actually found, which makes it far more useful for shift handoffs, executive briefings and the everyday question of "have we seen this before?"
Built with security teams in mind
We know that connecting security data to an AI assistant raises fair questions, which is why our MCP server starts by being conservative, gaining your trust as it goes. It's read-only, which means it can't create, change or delete anything in Legion, and it can't run workflows, skills or agents. Each person connects from their own assistant and signs in with their own Legion account, so every request runs as that user and is checked against their Legion role. Nobody sees more through Claude or ChatGPT than they could already see in Legion.
Admins stay in as much control as they want, throughout deployments. MCP access is turned off until an admin enables it for the organization, and it can be switched off again at any time. Individual users can disconnect Legion from their assistant whenever they like, and admins can revoke a specific user's sessions, which ends that person's MCP access within about a minute.
Getting started
Setup takes just a few minutes. Legion has always been about capturing the way your team investigates so that expertise can scale. With MCP, that expertise travels with your team, into the assistants where more and more of their work already happens. If you’d like help in configuring this or to learn more, please reach out to [email protected].
Connect Claude and ChatGPT to Legion via MCP and ask about your investigations in plain language, with read-only access scoped to each user’s role
TL;DR: In an agentic SOC, AI agents investigate alerts, decide what to check next, and can take action. Unlike SOAR playbooks or AI assistants, agents run the investigation themselves. They’re already handling phishing, triage and DLP alerts for teams like Virgin Money. The risks are real, but most come down to how much you let the agent do without checking, and that’s something you can control.
If you work in or manage a SOC, the appeal of AI agents helping your team is clear. They’re already being put to work too with 58% of cybersecurity leaders reporting that AI agents are taking actions within organizational workflows.
Broader SOC automation challenges haven’t disappeared, though and 52.6% of organizations cite skills gaps and a lack of expertise as barriers to SOC automation.
Below, we help you clear away some of those barriers and explain what an agentic SOC is and how agents work in the modern SOC, as well as limitations of their use.
What An “Agentic SOC” Is
Before we define what an agentic SOC is, there are three points that we think are worth clarifying:
- “Agentic” isn't a universally precise technical category.
- Not every product marketed as an “AI agent” has the same degree of autonomy.
- Agentic behavior exists on a spectrum.
However, it's reasonable to fundamentally say that an agentic SOC is a security operations environment in which AI agents can autonomously perform security tasks.
The tasks done by an agentic SOC (which in practice involves the deployment of an agentic layer like Legion) can include investigating alerts, gathering context, forming hypotheses, querying security systems, coordinating workflows, and executing approved response actions within defined human and technical controls.
We share practical examples of an agentic SOC in action further on in this article.
An agentic SOC solution or workflow involves an agent connected or logged into SOC tools and workflows gathering security data, autonomously investigating threats, reasoning through evidence, and taking action, all the while using organizational context and feedback to guide its decisions.
“Automation” vs “AI-assisted SOC” vs “agentic AI” tools
The three approaches below are often confused, but they differ in how independently they can work within the SOC.
Automation tools like SOAR follow predefined rules and workflows, whether that’s enriching an alert, opening a ticket or blocking an IP. If a case doesn’t fit the playbook, it can’t work out what to do.
AI-assisted SOC are mostly legacy security products with AI bolted on. You get alert summaries or a chat assistant inside one tool. The AI does some of the analysis, but you still run the investigation.
Agentic AI SOC is when AI agents independently plan and execute multi-step investigations, gathering evidence, developing and testing hypotheses, selecting tools, and adapting their approach as new information emerges. They work across multiple security tools, coordinating how those tools are used throughout an investigation.
Levels of AI SOC Agent Autonomy
The last of the approaches above (agentic AI SOC) effectively describes a human-like worker in your SOC. However, AI in the SOC operates at different levels of autonomy, from assisting analysts to independently managing security workflows.
We’ve adapted the levels below from Google Cloud’s Well-Architected Framework, which sets out four levels of security autonomy. Though Google wrote them with cloud security in mind, we think they work well for showing how a SOC moves from manual work to mostly running on its own.
Level 1: Manual (No AI autonomy)
People run every investigation. There may be a few scripts or SOAR playbooks for repetitive jobs, but a human analyst decides what happens next.
Level 2: Assisted (Low autonomy)
AI summarizes alerts and suggests what to look at. It might write queries for you too, but you’re still the one running the investigation.
Level 3: Semi-autonomous (Medium autonomy)
Here the agent does most of the investigating itself. If it gets stuck, isn’t sure, or wants to take a risky action, it asks an analyst.
Level 4: Autonomous (High autonomy)
Agents work through whole cases on their own, from investigation through response. Your team sets the rules and permissions up front and only gets involved in the big decisions.
Agentic SOC Example Use Cases
To show you what agentic AI SOC can look like in practice in 2026, here are four examples, with anonymized customer results where available.
1. Phishing investigation
When a suspicious email is reported, an AI SOC agent can examine the sender, inspect URLs and attachments, check reputation data, identify other recipients, and search for evidence that users interacted with the message.
The agent can then assess whether the email is malicious, document its findings, and recommend or execute approved containment actions.
Legion learns this workflow from how your analysts already investigate phishing, and once your team trusts it, Legion can run the workflow without an analyst directing each step.
A customer of ours uses this approach to handle phishing investigations overnight, reducing the volume of cases waiting for analysts.
2. Threat hunting and complex investigations
An analyst can give an AI SOC agent an objective, such as investigating whether a compromised account is part of a wider attack. The agent can then formulate queries, examine results, investigate related identities and endpoints, and change direction as new evidence emerges.
The agent can assemble its findings into a report for the analyst.
Legion AI Investigator supports these goal-driven investigations where analysts define the objective and permissions, then the agent selects tools and investigates iteratively.
3. High-volume alert triage
An AI SOC agent can collect evidence, check organizational context, determine whether an alert requires escalation, and document the outcome. This means agents can execute established workflows across thousands of alerts.
In our Virgin Money case study, the major bank used Legion to learn and automate its existing investigative processes. Legion processed 30,000 backlogged alerts in under two months, reducing the bank's alert backlog by more than 60%.
Another Legion customer, WELL Health Technologies, reported an 81% reduction in investigation and response time for its most common use case. Similarly, the University of Tulsa used Legion to cut average investigation time in half.
4. Data Loss Prevention (DLP) investigations
DLP alerts are often spurious and can be a big driver of SOC alert fatigue. For example, a file upload might trigger an alert, but investigating it requires checking who uploaded the file, where it went, who has access, and whether the activity was authorized.
An agent can gather this information across identity, cloud, and DLP tools, compare it with past investigations, and identify cases that require human review.
AI SOC agents can check whether the activity is legitimate by verifying the uploader, destination, and access permissions automatically. Legion customer IQ-EQ has reported faster investigations and reduced manual work using the platform, with particular praise for its accuracy in handling DLP alerts.
Agentic SOC Risks and Mitigations
AI agents can independently interpret evidence, make decisions, and execute actions across security tools. These responsibilities carry risks, whether they’re handled by a human analyst or an AI agent.
Fortunately, agentic SOC risks are predictable, and you can reduce most of them with the right controls.
Below, we explain five core risks we think organizations should know about before green-lighting any agentic AI deployment in the SOC, along with how Legion approaches them.
1. Incorrect decisions and hallucinations
A confident explanation does not necessarily mean an investigation is correct. AI agents can misinterpret evidence, miss genuine threats, or classify legitimate activity as malicious.
Mitigation
Require verifiable evidence for investigative conclusions. At Legion, we believe agents should meet the same documentation standards as human analysts. Our platform captures screenshots of the systems agents interact with, allowing analysts to review the evidence behind each conclusion.
2. Missing or outdated organizational context
An AI agent may reach the wrong conclusion if it lacks information about the organization. For example, it might classify a legitimate financial document upload as data theft, or dismiss a suspicious transfer based on a previously approved workflow that is no longer safe.
Mitigation
Give agents access to organizational knowledge, previous investigations, asset information, and current access permissions. This knowledge must be regularly validated, i.e., you must be able to distinguish between how strongly evidence supports a conclusion and how recently that evidence was verified. Legion tracks these separately, as confidence and freshness, so teams can see when knowledge needs re-verifying before an agent relies on it.
3. Unauthorized or disruptive actions
Agents with broad permissions could mistakenly isolate production systems, disable legitimate accounts, or modify security configurations.
Mitigation
Apply least-privilege permissions, restrict access to approved tools, and require approval for high-impact actions. Legion’s AI Investigator allows organizations to define which tools and actions an agent can use and when it must request human approval.
4. Lack of visibility and accountability
One of the biggest risks in agentic SOCs is that security teams may struggle to understand why an agent made a decision or what actions it performed. Lack of visibility makes errors harder to investigate and can create problems for auditing and compliance.
Mitigation
Maintain an auditable record of investigations, including evidence, tool interactions, decisions, approvals, and response actions. Legion takes a white-box approach. Each automated investigation appears as a workflow analysts can inspect and edit, and corrections apply to future investigations.
5. Unreliable automation at scale
An agent that performs well in a demonstration can struggle with real-world workflows due to missing data, unfamiliar tools, and unusual cases. Automating unreliable decisions at scale can create more work for analysts or allow threats to go undetected.
Mitigation
Benchmark agents against actual SOC workflows before expanding their responsibilities. Measure false positives, false negatives, investigation accuracy, workflow completion, and the frequency of human intervention.
We highly recommend involving analysts in testing and starting with well-understood, repeatable use cases before expanding agentic AI SOC workflows. This also has the positive side effect of improving analysts’ performance and keeping your team sharp and engaged.
Safely Make Your SOC Agentic with Legion
Ready to bring agentic capabilities into your SOC? Get a demo of Legion today.
An agentic SOC uses AI agents to investigate alerts and take action. See how it compares to SOAR, real customer results, and the risks to plan for.
Agentic swarm attacks are changing what security teams are up against. Instead of a single attacker working step by step, a coordinated group of AI agents probes, adapts, and spreads across an environment at once, generating thousands of small signals that each look routine on their own.
For security operations teams, this creates a problem that has nothing to do with skill or effort. The tools and processes most SOC teams rely on were designed for a different kind of threat.
What are Agentic Swarm Attacks?
An agentic swarm attack uses multiple AI agents working in parallel, each handling a different part of an intrusion. One agent might map the environment, another test stolen credentials, another move laterally between systems, and another quietly collect data. The agents share what they learn and adjust their approach as they go.
We’ve seen attacks (that aren’t even really attacks, but accidents) in which AI agents carried out most of the work on their own, at a pace no human team could match, with 10s of thousands of uncorrelated alerts adding up. As frontier AI models become more capable and more widely available, the techniques once limited to well-funded nation-state groups are now being used by mom-and-pop type attackers.
Why Agentic Swarm Attacks are so Hard to Stop
Several characteristics combine to make agentic swarm attacks uniquely difficult for security teams to detect and respond to.
They operate at massive scale. This has been covered ad nauseum. Agents move fast and do a ton of stuff.
Their activity is disconnected. Nothing obviously links a help desk password reset to a file share access to a burst of unusual API calls. Each alert or event lands in a different queue, often with a different analyst.
They leave no reusable indicators. Traditional detection depends on recognizing something seen before: a known file hash, a malicious domain, a familiar sequence of steps. Agents can generate new scripts and tooling on the fly, so indicators rarely repeat and there's often no pattern to write a rule for.
They mutate in real time. When one attempt is blocked, the swarm tries a variation, oftentimes in very short order.
They blend in with normal activity. Agents often use valid credentials and legitimate administrative tools, so their actions look like ordinary IT work. Activity is also spread across enough accounts and systems that no single one crosses an alerting threshold.
They cross team boundaries. An agentic swarm attack doesn't respect the lines between the SOC, identity, data loss prevention, and IT, in fact they are built to fall between the cracks of how the enterprise carves up its teams. The pieces of the attack show up in different teams' tools, which means no single team sees the full picture.
Why SOC Teams Aren't to Blame
When an attack slips through, it's tempting to ask what the analysts missed, but the smarter things to investigate are the conditions they're working in.
There's already too much noise
Long before agentic attacks, SOC teams were overwhelmed with alerts. This is not a new thing that cybersecurity marketers yell about (I’ll plead the fifth on this). Most alerts turn out to be false positives, so analysts learn to move quickly, trust severity scores and their intuition, and save their deepest attention for the alerts that look most dangerous.
The tools were built for yesterday's problems
Most security operations run as a funnel: collect data, write rules that match known attack patterns and indicators, rank alerts by severity, and have people work the top of the queue. SIEM correlation rules, signature-based detection, and SOAR playbooks all assume attacks are loud, patterned, and repeatable. Black hat agents are not like this.
Context is scattered across tools and teams
Deciding whether an alert matters depends on context from identity systems, endpoint tools, HR records, past cases, etc., and usually are spread across a half-dozen consoles. When the pieces of an attack land in different teams' queues, nobody has a chance to connect dots.
What it Takes to Defend Against Agentic Swarm Attacks
If the attack is a swarm, the defense has to work like one. That requires changes to both the technology and the role of the people running it.
Investigate every signal, not just the top of the queue. The evidence of an agentic swarm attack lives in the low-severity alerts and sensor anomalies most SOCs filter out. Defenders need to evaluate every one of them, which is only possible with AI.
Use fast triage agents that touch everything. A first layer of agents has to review every signal as it arrives, close the obvious noise, and recognize when a signal is related to something already under investigation. To run on everything, these agents need to be fast and thorough (but somehow affordable).
Send deeper investigations to specialized agents. When a signal needs a closer look, it should go to an expert (human or agentic) that knows exactly how to manage that kind of problem.
Share context across every team. Agents and people need one shared memory of every user, system, case, and decision, so activity in different departments can be recognized as one attack.
Earn trust instead of assuming it. Disabling an account or isolating a host on a wrong call is its own incident. Agents should be tested against your own past cases and given authority to act only as their record supports it.
The role of analysts changes too. Instead of working alerts one at a time, they shift their roles into ones that see them provisioning agents and teaching them how investigations should run, governing what agents are allowed to do, and orchestrating the response when human judgment is needed.
The Bottom Line
Agentic swarm attacks don't win because security teams fall short. They win because they're built to hide in the gaps between the noise, the tools, and the teams that today's security operations were designed around. Closing those gaps takes a defense that works like a swarm too: agents that know your organization, share what they find across every team, and earn trust one decision at a time, with your analysts in control.
To see how Legion Security helps enterprises defend against agentic swarm attacks, visit legionsecurity.ai.
Agentic swarm attacks use coordinated AI agents to hide in the noise. Learn why they overwhelm today's SOCs and how to defend against them.
