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.
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?
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.
Building AIM or any agentic process rests on three pieces:
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.
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.
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.
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.
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.
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.
The tool fetches XDR, Endace, and the Splunk indexes on the fly — and it reasons about them:
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. ✅
Every good tool needs a name. Lou Norman and John Park jokingly proposed AIM — and honestly, why not? It stuck.
Acknowledgements
Check out the other blogs from our team at the Cisco Live Americas 2026 SOC at Las Vegas:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。