{"id":98075,"date":"2026-07-07T19:10:10","date_gmt":"2026-07-07T19:10:10","guid":{"rendered":"https:\/\/www.europesays.com\/ai\/98075\/"},"modified":"2026-07-07T19:10:10","modified_gmt":"2026-07-07T19:10:10","slug":"aim-building-an-agentic-tier-2-soc-analyst-at-cisco-live-amer-2026","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/ai\/98075\/","title":{"rendered":"AIM: Building an Agentic Tier-2 SOC Analyst at Cisco Live AMER 2026"},"content":{"rendered":"

\t\tWhy we built it<\/p>\n

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.<\/p>\n

A typical incident looked like this:<\/p>\n

\"\"<\/p>\n

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 \u2014 the enrichment, the packets, the right SPL across the right indexes \u2014 naturally took us a fair amount of time per incident. And we kept thinking the same engineer thought: this flow is so consistent\u2026 could an agentic agent do the first 90%?<\/p>\n

The goal we set: pass a single XDR incident ID and get back a full HTML report in a few minutes \u2014 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.<\/p>\n

A detour worth mentioning: the local-GPU experiment<\/p>\n

Here\u2019s a fun bit. Our \u201cSOC in a Box\u201d has serious horsepower \u2014 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.<\/p>\n

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

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

What does an agentic SOC actually need?<\/p>\n

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?<\/p>\n

The context of Cisco Live \u2014 the IP ranges and their locations
\nThe Splunk indexes \u2014 purpose-built indexes for network, firewall, DNS etc.
\nThe MCP servers \u2014 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.
\nAccess to the XDR APIs \u2014 for incident, targets, observables, and events.<\/p>\n

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 \u2014 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.<\/p>\n

The architecture, briefly<\/p>\n

\"\"<\/p>\n

INPUT: an XDR incident ID
\u2502
\u25bc
Agentic Orchestration \u2014 Claude Opus 4.8 (1M context), via Claude Code
\u2502 carrying: Skill \u00b7 Subagent \u00b7 Prompt \u00b7 (adapts per incident) \u00b7 Cisco Live SOC context
\u2502
\u251c\u2500\u2500 Analyse XDR \u2500\u2500 via the XDR APIs
\u251c\u2500\u2500 Analyse Packets \u2500\u2500 via the Endace MCP server \u2500\u2500\u25ba EndaceProbe in \u201cSOC in a Box\u201d
\u2514\u2500\u2500 Analyse Logs \u2500\u2500 via the Splunk MCP server + index context \u2500\u2500\u25ba Splunk
\u2502
\u25bc
OUTPUT: a detailed, Tier-2 HTML report<\/p>\n

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

The three ingredients every agentic process needs<\/p>\n

Building AIM or any agentic process rests on three pieces:<\/p>\n

A Skill \u2014 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.
\nA Prompt \u2014 to tell it its problem statement (the mission, the rules of engagement)
\nA Subagent \u2014 to give it its own context window, so deep work on one incident does not poison the other context<\/p>\n

And here\u2019s 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 \u2192 Endace \u2192 Splunk \u2014 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.<\/p>\n

See it in action: the polyfill.io incident \ud83c\udfa5<\/p>\n

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

See the video walkthrough below. <\/p>\n

\n

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 \u2014 who had no idea we were even working this incident \u2014 separately sent a block request for polyfill.io to the NOC team. That was the exact conclusion AIM had reached proving the tools usability.<\/p>\n

A second, hands-on example: the \u201cAngler exploit kit on port 80\u201d<\/p>\n

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

The initial Attack Storyboard analysis (XDR\u2019s AI assessment)<\/p>\n

Before we touched it, the XDR Attack Storyboard had already drafted an AI hypothesis:<\/p>\n

\u201cFalse Positive: Two Secure Firewall IDS signature alerts for \u2018EXPLOIT-KIT Angler exploit kit exploit download attempt\u2019 fired on allowed HTTP (port 80) connections from internal IPv6 hosts to a Cloudflare address. The Angler exploit kit was active circa 2012\u20132016; 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.\u201d<\/p>\n

\"\"<\/p>\n

A solid hypothesis \u2014 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.<\/p>\n

What AIM came back with<\/p>\n

Angler exploit attempt on port 80 \u2192 False Positive: an Apple Podcasts app fetching a feed via Cloudflare.<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

What it proved (from data from AIM tool):<\/p>\n

An attendee\u2019s iPhone Podcasts app requested a podcast feed\/episode from transistor.fm (hosted behind Cloudflare) over HTTP. The server did a 301 redirect to HTTPS \u2014 totally normal \u201d 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.)<\/p>\n

What it inferred (reasoning):<\/p>\n

The EXPLOIT-KIT Angler Snort signature mis-matched on a random-hex URL path (Transistor\u2019s normal subscriber-feed format). Angler EK has been defunct since ~2016<\/p>\n

Disposition: Closed: False Positive \u2192 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.<\/p>\n

Our manual conclusion \u2014 and how it matched :<\/p>\n

Here\u2019s 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.<\/p>\n

\"\"\"\"<\/p>\n

The tool told us the right answer; it reproduced the same evidence-backed reasoning a human analyst arrived at independently \u2014 in a fraction of the time. That\u2019s the moment we trusted it.<\/p>\n

What makes it agentic (not just a script)<\/p>\n

The tool fetches XDR, Endace, and the Splunk indexes on the fly \u2014 and it reasons about them:<\/p>\n

It\u00a0knows the indexes, so it writes the right SPL to land the right time window\u00a0\u00a0
\nIt\u2019s\u00a0agentic because it will\u00a0re-check an SPL with corrected timing, and\u00a0decide the next query based on what the\u00a0previous\u00a0one returned\u00a0
\nIt\u00a0comes back to the human when it has a real question\u00a0\u2014 but mostly it runs autonomously\u00a0\u00a0
\nOn another incident, the tool\u00a0didn\u2019t\u00a0just analyze one device \u2014 it showed us that\u00a0multiple attendee devices\u00a0had accessed the same malicious destination. It\u00a0wrote\u00a0the SPL to\u00a0enumerate\u00a0every affected attendee device, and it also confirmed that\u00a0our\u00a0firewall\u00a0had already blocked it\u00a0\u2014 so there was\u00a0no impact.\u00a0That\u2019s\u00a0the kind of \u201czoom out and check the blast radius\u201d step a good Tier-2 analyst does by reflex, done in seconds.\u00a0<\/p>\n

Why this matters: AI defense vs. AI attackers<\/p>\n

Attackers are increasingly using\u00a0AI to attack our infrastructure. The answer is symmetric:\u00a0our products\u2019 built-in AI SOC features + custom tools like this\u00a0form an\u00a0AI defense boundary\u00a0(The\u00a0layers\u00a0of AI\u00a0protects\u00a0us from the\u00a0attackers)\u2014\u00a0letting us understand and stop attackers\u00a0before\u00a0they can act, at machine speed.\u00a0<\/p>\n

And here\u2019s the future we\u2019re excited\u00a0about:\u00a0this can run\u00a0inside the SOC in a Box\u00a0and be wired into\u00a0XDR automation, so that on\u00a0every assigned incident, a Tier-2 report is generated and\u00a0automatically attached to the incident worklog\u00a0\u2014 ready and waiting the next time an analyst opens it.\u00a0<\/p>\n

That, right there, is our\u00a0Innovate\u00a0mission \u2014\u00a0accomplished. \u2705\u00a0<\/p>\n

So\u2026 why did we call it AIM?<\/p>\n

Every\u00a0good tool\u00a0needs a name.\u00a0Lou Norman\u00a0and\u00a0John\u00a0Park\u00a0jokingly proposed\u00a0AIM\u00a0\u2014 and honestly, why not? It\u00a0stuck.\u00a0<\/p>\n

Acknowledgements\u00a0<\/p>\n

Aditya Sankar\u00a0\u2014 for the SOC-in-a-Box and access to the on-box GPU\u00a0compute\u00a0for local-model experiment.\u00a0
\nLou Norman\u00a0and\u00a0John Park\u00a0\u2014 for the name.\u00a0
\nAdam\u00a0Alkishawi\u00a0\u2014 for the polyfill.io\u00a0incident, and for letting AIM lend a hand on the\u00a0analysis.\u00a0
\nThe\u00a0Cisco XDR,\u00a0Splunk, and\u00a0Foundation AI\u00a0teams whose AI features made the Tier-1 layer something we could\u00a0build on.\u00a0
\nOur\u00a0Endace\u00a0partners \u2014 the packet-capture backbone (and MCP) that\u00a0let\u00a0the agent reach the actual bytes.\u00a0
\nJessica Bair Oppenheimer, our leaders, and the seasoned SOC analysts who taught us the flow\u00a0and motivated us in each step.\u00a0
\nTony Harrison\u00a0and other engineering leaders.\u00a0<\/p>\n

Check out the other blogs from our team at the Cisco Live Americas 2026 SOC at Las Vegas:<\/p>\n","protected":false},"excerpt":{"rendered":"Why we built it Over the first couple of days in the SOC at Cisco Live Americas 2026,…\n","protected":false},"author":2,"featured_media":98076,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[179,7493,24,34783,1772,313,23155,21767,1780,51161,1781],"class_list":["post-98075","post","type-post","status-publish","format-standard","has-post-thumbnail","category-agentic-ai","tag-agentic-ai","tag-agentic-artificial-intelligence","tag-ai","tag-cisco-live","tag-cisco-xdr","tag-cybersecurity","tag-security-operations-center","tag-soc","tag-splunk","tag-splunk-cloud","tag-splunk-enterprise-security"],"_links":{"self":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/98075","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/comments?post=98075"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/98075\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media\/98076"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media?parent=98075"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/categories?post=98075"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/tags?post=98075"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}