Why we built it

Over the first couple of days in the SOC at Cisco Live Americas 2026, we did what every new junior analyst does: we picked up incidents, one after another, and worked them for Tier-2 analysis. With a lot of help from the experienced SOC folks, we learned the flow.

A typical incident looked like this:

It was a genuinely fun mix of agentic AI assistance and our own manual logic powered by our world-class Cisco and partner products. For those of us newer to the SOC, gathering all of this — the enrichment, the packets, the right SPL across the right indexes — naturally took us a fair amount of time per incident. And we kept thinking the same engineer thought: this flow is so consistent… could an agentic agent do the first 90%?

The goal we set: pass a single XDR incident ID and get back a full HTML report in a few minutes — taking us to the 90% mark, so a human does the final verification, adds nuance, attaches the report and if needed ships it to our Tier-3 champions.

A detour worth mentioning: the local-GPU experiment

Here’s a fun bit. Our “SOC in a Box” has serious horsepower — on-box GPU compute, installed right there. Thanks to Aditya Sankar, we got access to a pre-installed Ollama server on it, and we really wanted our agentic flow to run on local models for that extra layer of on-prem self-reliance.

With the limited time and a few failed attempts, we couldn’t get the full agentic loop stable on the local models in time. It was a great experiment — and a glimpse of a fully self-hosted agentic SOC — but for the event we pivoted to Claude Opus 4.8 running through Claude Code.

The division of labor we landed on: Tier-1 agentic SOC was already handled beautifully by the AI features in our own products — XDR’s Agentic Attack Storyboard and Splunk’s Triage Agent. We focused on the Tier-2 agentic automation layer on top tailored to Cisco Live.

What does an agentic SOC actually need?

This was the key insight. An agent is only as good as its context and its hands. So, we asked: what would we need to hand a brand-new analyst on day one?

• The context of Cisco Live — the IP ranges and their locations
• The Splunk indexes — purpose-built indexes for network, firewall, DNS etc.
• The MCP servers — an Endace MCP for packet capture/decode and a Splunk MCP for running queries. Thanks to the Endace team for their excellent MCP server, which let our agent reach the actual packets.
• Access to the XDR APIs — for incident, targets, observables, and events.

We packaged that knowledge, wired up the tools, and rapidly prototyped the Tier-2 agent around it. With more investment, we could make it considerably more sophisticated and robust — running smoothly and reliably at scale. And perhaps the most exciting part: we can take these learnings back to our products and engineer them based on this real-world experience.

The architecture, briefly

INPUT: an XDR incident ID
│
▼
Agentic Orchestration — Claude Opus 4.8 (1M context), via Claude Code
│ carrying: Skill · Subagent · Prompt · (adapts per incident) · Cisco Live SOC context
│
├── Analyse XDR ── via the XDR APIs
├── Analyse Packets ── via the Endace MCP server ──► EndaceProbe in “SOC in a Box”
└── Analyse Logs ── via the Splunk MCP server + index context ──► Splunk
│
▼
OUTPUT: a detailed, Tier-2 HTML report

The analyst kicks it off from their laptop / the XDR workflow (an HTTPS POST); the agent orchestrates XDR → Endace → Splunk, and a self-contained HTML report drops out the other end.

The three ingredients every agentic process needs

Building AIM or any agentic process rests on three pieces:

• A Skill — to explain what the steps are (the triage playbook: how to read an XDR incident, when to pull packets, which indexes to query), Guardrails etc.
• A Prompt — to tell it its problem statement (the mission, the rules of engagement)
• A Subagent — to give it its own context window, so deep work on one incident does not poison the other context

And here’s the beauty of it: an agentic process is not a constant, fixed flow. It adapts to each incident. A DNS incident, an exploit-signature false positive, and a data-exfiltration hunt each take a different path through XDR → Endace → Splunk — and AIM decides that path as it goes, based on what each step actually returns. That adaptability is precisely what separates an agent from a runbook.

See it in action: the polyfill.io incident 🎥

Our first cool walkthrough is an attendee Wi-Fi device that contacted polyfill.io — the CDN domain made infamous by the 2024 supply-chain hijack. We passed the incident ID to the tool and let it run.

See the video walkthrough below.

This one showed AIM proving its worth in real time. Adam Alkishawi ran the incident through AIM and, within about five minutes, had the full context he needed to decide. The validation came independently: a Tier-3 analyst — who had no idea we were even working this incident — separately sent a block request for polyfill.io to the NOC team. That was the exact conclusion AIM had reached proving the tools usability.

A second, hands-on example: the “Angler exploit kit on port 80”

Separately, Abhishek Dubey and Manoj Sudhakara were looking at a great incident — an apparent exploit attempt on port 80. The XDR Attack Storyboard gave us a strong head start, including an initial AI assessment.

The initial Attack Storyboard analysis (XDR’s AI assessment)

Before we touched it, the XDR Attack Storyboard had already drafted an AI hypothesis:

“False Positive: Two Secure Firewall IDS signature alerts for ‘EXPLOIT-KIT Angler exploit kit exploit download attempt’ fired on allowed HTTP (port 80) connections from internal IPv6 hosts to a Cloudflare address. The Angler exploit kit was active circa 2012–2016; its legacy signatures are known to produce false positives on modern CDN-proxied web traffic, and no endpoint telemetry, blocked action, or payload confirmation is present.”

A solid hypothesis — and we wanted to further dig into this using our AIM tool. So, we sent the incident ID to our tool to prove it on the wire and in the logs.

What AIM came back with

Angler exploit attempt on port 80 → False Positive: an Apple Podcasts app fetching a feed via Cloudflare.

What it proved (from data from AIM tool):

An attendee’s iPhone Podcasts app requested a podcast feed/episode from transistor.fm (hosted behind Cloudflare) over HTTP. The server did a 301 redirect to HTTPS — totally normal ” behavior. The phone then completed the download over encrypted TLS/443. The entire exchange is a phone fetching a podcast(surrounding traffic was all consumer Apple/iCloud/Spotify apps.)

What it inferred (reasoning):

The EXPLOIT-KIT Angler Snort signature mis-matched on a random-hex URL path (Transistor’s normal subscriber-feed format). Angler EK has been defunct since ~2016

Disposition: Closed: False Positive → report to ENG for signature tuning (EXPLOIT-KIT Angler on SPAN-sourced CDN/podcast traffic). The same signature also fired for other attendee hosts, hitting the same Cloudflare edge. No escalation; the device is benign.

Our manual conclusion — and how it matched :

Here’s the part that sold us. After AIM produced its report, we did the manual Tier-2 verification ourselves independently, working the packets and logs by hand. Our written conclusion was exactly the same.

The tool told us the right answer; it reproduced the same evidence-backed reasoning a human analyst arrived at independently — in a fraction of the time. That’s the moment we trusted it.

What makes it agentic (not just a script)

The tool fetches XDR, Endace, and the Splunk indexes on the fly — and it reasons about them:

• It knows the indexes, so it writes the right SPL to land the right time window  
• It’s agentic because it will re-check an SPL with corrected timing, and decide the next query based on what the previous one returned 
• It comes back to the human when it has a real question — but mostly it runs autonomously  
• On another incident, the tool didn’t just analyze one device — it showed us that multiple attendee devices had accessed the same malicious destination. It wrote the SPL to enumerate every affected attendee device, and it also confirmed that our firewall had already blocked it — so there was no impact. That’s the kind of “zoom out and check the blast radius” step a good Tier-2 analyst does by reflex, done in seconds. 

Why this matters: AI defense vs. AI attackers

Attackers are increasingly using AI to attack our infrastructure. The answer is symmetric: our products’ built-in AI SOC features + custom tools like this form an AI defense boundary (The layers of AI protects us from the attackers)— letting us understand and stop attackers before they can act, at machine speed. 

And here’s the future we’re excited about: this can run inside the SOC in a Box and be wired into XDR automation, so that on every assigned incident, a Tier-2 report is generated and automatically attached to the incident worklog — ready and waiting the next time an analyst opens it. 

That, right there, is our Innovate mission — accomplished. ✅ 

So… why did we call it AIM?

Every good tool needs a name. Lou Norman and John Park jokingly proposed AIM — and honestly, why not? It stuck. 

Acknowledgements 

• Aditya Sankar — for the SOC-in-a-Box and access to the on-box GPU compute for local-model experiment. 
• Lou Norman and John Park — for the name. 
• Adam Alkishawi — for the polyfill.io incident, and for letting AIM lend a hand on the analysis. 
• The Cisco XDR, Splunk, and Foundation AI teams whose AI features made the Tier-1 layer something we could build on. 
• Our Endace partners — the packet-capture backbone (and MCP) that let the agent reach the actual bytes. 
• Jessica Bair Oppenheimer, our leaders, and the seasoned SOC analysts who taught us the flow and motivated us in each step. 
• Tony Harrison and other engineering leaders. 

Check out the other blogs from our team at the Cisco Live Americas 2026 SOC at Las Vegas:

• Building the Agentic SOC at Cisco Live Americas 2026
• The Experience Dividend: How Better Digital Experience Protects Revenue, Trust, and Growth
• Cable to Cloud – A Product Engineer’s Journey Through the Cisco Live AMER 2026 SOC
• What Working the Cisco Live SOC Taught Me About AI, Detection, and Response
• Educate at Event Speed: Inside the Cisco Live SOC
• Elevating Expertise in the SOC
• Machine Speed, Human Judgement: How AI Changed the SOC in 2026
• SharpHound Recon Attack – How AI enhanced the threat hunt
• Endace: Using LLMs and Endace Full Packet Capture for Incident Response
• Endace: Never Underestimate Cisco Live!
• Endace: Supporting Encryption vs. Using Encryption: When the best laid plans go astray