Defense at Machine Speed: How Arctic Wolf Built the Aurora Agentic SOC on AWS

Discover how Arctic Wolf built an AI-powered Agentic SOC on AWS to automate investigations, accelerate threat response, and scale security operations.
6 min read

By

Avni Wala, Principal Developer – Arctic Wolf
Laura Ellis, SVP Artificial Intelligence – Arctic Wolf
Merin Eralil, Security Partner Solutions Architect – AWS
Tim Sitze, Solutions Architect – AWS

Attackers now operate at machine speed, and security operations center (SOC) teams must match that pace. Reconnaissance, phishing, and exploit development used to require skilled operators, and now much of that work is automated. The gap between initial access and real impact keeps shrinking. Most SOCs still measure alert triage in tens of minutes and investigations in hours, a pace built for a slower era of attacks.

Adding analysts and faster tooling helps take the edge off, but it does not close the gap, so we rebuilt the SOC around a Swarm of Experts, a graph of specialized agents (each focused on a specific sub-task like customer preferences evaluation, historical tickets correlation, or observations analysis) running concurrently across thousands of investigations.

Operating at an industry-leading scale, the Aurora Agentic SOC investigates every alert autonomously and runs in production today, triaging security events and observations from more than 10,000 customers. Making this scale in production requires a strong architecture on AWS to support hundreds of agents investigating without runaway cost or unreliable results.

From AI-Assisted to Agent-Led

Most security AI is still a bolt-on, added on top of security stacks that were never designed around it. It rides alongside the analyst, condensing an alert, gathering related context, and sketching out notes, but a person still makes every call and carries the investigation by hand. Running one agent against one alert is manageable. Running them across every SOC function at once is where it gets hard.

The Aurora Agentic SOC is built for exactly that. A traditional SOC routes work up a chain from Tier 1 to Tier 2 to Tier 3. We run specialized agents in parallel instead, covering threat intelligence, threat hunting, triage, investigation and response at once. Agents do most of the investigating, and our security experts stay in the loop for the cases that call for human judgment or sign-off. When one of those reaches an analyst, an investigation is already written up.

How We Built It on AWS

At our scale, running this in production is as much of an infrastructure challenge as an AI one. Here is how the stack fits together on AWS, starting with the intelligence layer and working down to the runtime.

The Intelligence Layer: Aurora Superintelligence Platform

Every agent in the Aurora Agentic SOC runs on the Aurora Superintelligence Platform, which brings AI and human expertise together to give each workflow the data, context, and guardrails it needs to produce trustworthy results.

The Swarm of Experts is our agentic framework. Rather than pushing a case up an escalation chain, the Swarm treats each one as its own investigation. Specialized agents run as stages in a directed graph. These agents cover customer preferences evaluation, historical tickets correlation, observation log analysis, triage reasoning, and ticket generation, among other tasks. Thousands of these investigations run concurrently across the platform.

Our data foundation grounds every workflow in more than 14 years of security operations experience, validated by over 1,000 security engineers across more than 10,000 real customer environments. The agent behavior is informed by our own investigation history, not generic training data. They also draw on the more than one trillion security events we process each day and carry each customer’s business context into every decision. The platform fetches this context at runtime through integrations with our data stores and ticketing systems, so each investigation reasons about the actual environment rather than working from assumptions.

The AI Trust Engine keeps agents inside their limits. Agents work within defined guardrails and will not answer beyond what they have been validated to handle. If a case falls outside an agent’s expertise, it stops and hands off to a human analyst instead of guessing. An AI Judge reviews every outcome across predefined quality dimensions before it reaches the customer. Those checks are what make the results dependable enough to act on automatically.

Agents earn their autonomy in stages. A new agent starts in shadow mode, running alongside the live workflow without acting, so we can compare its calls against what happened. Once it proves out, it moves to recommendation mode, proposing actions for a human to approve, and only after it clears our quality gates does it graduate to acting on its own. Oversight does not stop once an agent is live: we run ongoing spot-checks and statistical sampling of its decisions, so quality stays front and center rather than drifting over time.

Running on Amazon Bedrock and EKS

Model inference runs on Amazon Bedrock. Bedrock gives us access to a range of leading models through one API, and we use that flexibility at a granular level, matching the right model to each agent task rather than committing the whole platform to a single model. Most agents access Large Language Models via cross-region inference profiles, which Bedrock routes across regions to smooth out capacity.

For many tasks, where latency and cost matter more than reasoning depth, a smaller, less complex model is used instead. We also use Bedrock’s prompt caching to avoid re-processing shared prompt prefixes across agent calls, which cuts inference latency and cost on the high-volume tasks that form the bulk of our workload. Agents fetch customer-specific evidence and historical context at runtime through a set of MCP tool integrations, so each investigation is grounded in the actual environment instead of working from generic assumptions.

The service runs in three distinct deployment modes on Amazon Elastic Kubernetes Service (Amazon EKS), each containerized and isolated in its own namespace. An API tier handles synchronous requests. A listener tier reads from our internal event stream on Amazon Managed Streaming for Apache Kafka (Amazon MSK), filters cases that qualify for automation, and publishes them to Amazon Simple Queue Service (Amazon SQS). A worker tier polls SQS and executes the investigation graph for each case.

This separation means each tier scales independently: worker capacity tracks SQS queue depth, listener capacity tracks Kafka partition load, and neither is coupled to the other. SQS also absorbs alert surges, filling during spikes and draining as workers catch up, so investigation throughput scales with alert volume rather than being blocked by it.

Amazon ElastiCache is used for inter-process coordination: storing triage results, managing rule queues, tracking sampling state, and caching alert content. Agents reach their enrichment sources, ticketing, and other downstream systems through a Model Context Protocol (MCP) layer. That gives us one consistent tool interface and keeps the agent logic decoupled from the dozens of downstream integrations sitting behind it. This triage graph of specialized agents is also capable of identifying early-exit conditions.

For example, if an agent in the graph can determine a triage outcome conclusively, with high confidence, then the rest of the downstream agents do not need to run, thereby aiding in time and cost savings.

We run and scale this platform ourselves on AWS. Kubernetes autoscaling expands and contracts investigation capacity as alert volume moves, AWS IAM governs what each agent and service can access, and keeping deployment and orchestration in our own hands lets us tune reliability and cost for security workloads specifically.

Fast results only matter if they can be trusted. Every agent run is fully traced in Langfuse, so we can reconstruct any verdict step by step, and we watch service health and SLOs through Amazon CloudWatch and Grafana dashboards.

The whole stack runs under the compliance and access controls our enterprise customers require, and it scales with threat volume rather than with headcount.

What Defense at Machine Speed Looks Like in Practice

The Aurora Agentic SOC is already running across our customer base, and the results are measurable.

Investigations that run for hours in a traditional SOC are now completed in seconds to minutes, with agents working in parallel rather than sequentially. The Aurora Agentic SOC resolves more than 200,000 investigations each week without human intervention. For the workflows where agents operate, case resolution is up to 15x faster than human-only approaches.

This matters most during off-hours and alert surges, exactly when a traditional SOC is stretched thinnest. Agents do not work a smaller night shift, so the same investigation quality holds at 3 a.m. as at 3 p.m.

Turnkey Deployment, Predictable Investment

Most teams that try to build an agentic SOC in-house hit the same wall. Standing up the data foundation, acquiring and orchestrating the agents, integrating everything, and proving it all works costs real time and money long before any of it pays off, and plenty of these efforts never reach production.

Delivered as a service, the Aurora Agentic SOC removes that build-out. The agents are pre-built and pre-orchestrated, so there is no baselining, model management, or bespoke integration work to do before value shows up, and deployment lands in as little as 10 days.

It also takes the unpredictable economics of do-it-yourself AI off the table, including the token spend, compute overhead, and engineering cost of keeping experimental systems alive in production. Customers get a predictable cost and outcomes that start on day one.

Arctic Wolf and AWS: Built for This Together

Arctic Wolf’s partnership with AWS is not new, but it is accelerating. Through its Strategic Collaboration Agreement with AWS, Arctic Wolf has scaled the Aurora Superintelligence Platform globally on AWS infrastructure, advancing AI-driven threat detection and response at enterprise scale.

AWS provided elastic capacity, model access through Bedrock, and the security-native services our customers expect. Arctic Wolf brings the SOC operating model refined over years, the proprietary data behind it, and the ability to get a customer into production in days. For customers, this partnership means:

  • Pre-validated architecture running on enterprise-grade AWS security services
  • Elastic scale to process security telemetry across thousands of environments simultaneously
  • Continuous improvement as both AWS AI capabilities and Arctic Wolf’s security intelligence advance together

At AWS Summit New York 2026, AWS highlighted the shift from experimenting with agents to putting them into production. Arctic Wolf is already operating at that stage, and the Aurora Agentic SOC is available today through AWS Marketplace.

Security Outcomes for the Agentic Era

Speed gets the attention, but the bigger shift is where analysts spend their time. Once agents clear the alert queue, the team is no longer buried in triage and can hunt for what detection missed and sharpen the detections themselves. Over time that moves the program from reacting to threats toward measurably reducing risk and building lasting business resilience.

Getting there takes more than AI features bolted onto existing workflows. It takes a data layer grounded in real operational expertise, an agentic framework that covers every SOC function, and infrastructure that scales without turning into its own project. For us that infrastructure is Amazon Bedrock, Amazon EKS, and the security controls enterprises require.

Most security teams should not have to build any of this themselves. They need it working now, and they need it to hold up when a real intrusion is moving through their environment. We built the Aurora Agentic SOC on AWS to clear that bar.

Disclaimer: This blog is provided for informational purposes only. It reflects general industry perspectives and the author’s views as of the publication date, including forward-looking statements about technology trends. Actual outcomes may differ based on attacker behavior, customer environments, and broader market and regulatory developments.

Share this post: