By Barry “Baz” Shaw, Senior Engineering Manager, Technology Partner Programs, Endace
At Cisco Live AMER 2026 Endace debuted an MCP (Model Context Protocol) server for the integration of EndaceVault into the emergent agentic Security Operations Center (SOC), providing access to 200TB of full packet data and on-demand packet analysis to all agents present in the SOC.
Going into Cisco Live we had key questions about the utility of PCAP data to agents, how to manage making terabytes of data available without overflowing their context windows, and whether the models could parse, analyze and make judgements from the PCAP data comparable to that of an analyst. Results from some simple tests are extremely encouraging and indicate a bright future for agentic AI in the SOC.
Endace Always-on Packet Capture
Two of Endace’s newest EP94C8 EndaceProbes were installed in the GovWare SOC to provide full packet capture to support the conference SOC directives of Protect, Educate, and Innovate. Full packet capture provides unique insight into all activities on the network, delivering critical context and evidence for Incident Response and Threat Hunting teams.
The EndaceProbes each hosted three VMs that were running Zeek and delivering critical log data into Splunk. Custom Zeek script additions provided additional valuable details around clear text passwords in email and HTTP, and the use of insecure protocols. Zeek was also used for file-carving and automated submission of objects to Splunk Attack Analyzer and a beta of Endace’s new Vault API used in a Cisco XDR automated workflow was field tested.
PCAP and AI – a key question answered
In this scenario we wanted to test the ability of a reasonably new on-prem model to make incident judgements based on PCAP data. Using the qwen-3.6 model and Open WebUI, a DNS buffer overflow attempt flagged by Cisco Secure Firewall, and raised as an incident in Cisco XDR, was chosen as the candidate.
Using the Endace XDR workflow integration (which automatically creates Endace Pivot-to-Vision and EndaceVault links directly in the worklog) a quick pivot from Cisco XDR to EndaceVision shows DNS traffic present:
After pivoting from EndaceVision into Wireshark, we can see DNS activity and some large query responses. This verification served as the analyst judgement to be compared with the LLM findings.
In Open WebUI a new chat was opened, the Endace MCP connected as a tool, and the following prompt was issued:
There was a firewall alert called ‘PROTOCOL-DNS Microsoft SMTP excessive answer records buffer overflow attempt’ recorded for the traffic between IP addresses <redacted> and <redacted> at 2026-06-03T15:24:01.000Z and 2026-06-03T15:22:33.000Z. Can you get a packet decode from Endace and either confirm or deny the existence of DNS responses that would match this alert.
The model’s reasoning is shown in the following screenshot:
The Endace MCP tools contain detailed annotations that provide context to the model. Above we can see this context helping the model choose between different time inputs and correctly identifying that the start and stop times provided in the prompt were (accidentally) transposed in the prompt.
Once the AI issued the tool call to the Endace Vault API via the MCP, the extraction of the related PCAP data began. To make this data more consumable by AI, it is converted to JSON by the Endace Vault API and streamed back in manageable sized chunks. The AI can request additional chunks as required, which protects the context window from being swamped by a large PCAP download.
An example of the returned JSONified PCAP data is shown below, this is the raw data that the AI has to make its determination.
After consuming the JSONified PCAP data the AI began its analysis, clearly having parsed the PCAP data and displaying an understanding of the DNS protocol. From the name of the alert, it understood the specific details pertaining to the alert and was able to look for these in the DNS packets:
The reasoning of the model makes for interesting reading. It can comprehend the nature and specifics of the alert and use this to reason about the DNS packets. It successfully found an oversized DNS response and provided unprompted enrichment by determining the hosting provider of the DNS server.
So far, the model has performed admirably, validating the firewall alert and the analyst judgement. To take things further, we asked the model to do some extra analysis over and above the human analysis we’d done. While this chat was user driven, we expect that this is the kind of autonomous activity AI agents will perform on their own.
The AI was asked to confirm the hosting provider and look at the contents of the large DNS response to determine if it contained a malicious payload or was in fact just a verbose and unusually large response.
Can you confirm that the destination host <redacted> is in fact Microsoft hosted? Is there anything in the large DNS response that could be malicious or is it just a DNS response?
The model has told us that the source of the DNS response is a reputable domain and that the payload of the response was just a large number of regular AAAA records. In a pre-AI SOC, the analyst would need to spend time inspecting the PCAP in Wireshark (if they had access to full packet capture in the first place) to determine this was a false positive.
Conclusion
While this example was intentionally not an autonomous agentic finding, the model was able to determine that this alert was a false positive by analyzing the PCAP. The fact that relatively small open-source models can successfully extract findings from PCAP data is a major validation of their utility in the agentic SOC. We expect that frontier models will provide even richer analysis of PCAP data when available in the SOC if the token cost can be justified. A possible architecture is an on-prem first approach, escalating to a frontier model in the event on-prem cannot make a confident determination.
By using an agent to investigate events like these, and having access to full PCAP data, alerts can be triaged by the agent, requiring only a cursory review by a human analyst to definitively close cases in record time. This validates the core concept that the agentic SOC will improve overall efficiency and accuracy by optimizing incident triage and freeing up time for analysts to work on the more complex incidents that threaten enterprise operations.
Acknowledgements
Our thanks go to the Cisco SOC team, led by Jessica Oppenheimer and Ivan Berlinson, for the opportunity to integrate EndaceProbes with the Cisco Live Agentic SOC architecture.
The SOC team is a collection of Cisco and Splunk experts across many domains who were a pleasure to work and innovate with, and we came away with a great appreciation for the power of the Cisco Security and Splunk tools.
The Endace and Cisco teams were able to prove out integration innovations and test them in earnest in a real-world environment in preparation for making them generally available to the market.
More from Endace, Splunk and Cisco in the SOC series
Read more from Endace about the Cisco Live USA 2026 SOC:
- Elliott Hinson: Supporting Encryption vs. Using Encryption – when the best laid plans go astray
- Stephen Donnelly: Never underestimate Cisco Live!
Read related Cisco Team Blogs from the Cisco Live USA 2026 SOC:
https://blogs.cisco.com/security/clamer-soc-2026
For more Endace blogs in our SOC series, see here:
https://blog.endace.com/tag/soc/
Event SOC Website
Visit Cisco’s Event SOC website for full details of the SOC setup, and download the whitepaper written by Jessica Oppenheimer:
https://www.cisco.com/site/us/en/products/security/event-soc-report.html
