{"id":74244,"date":"2026-06-15T12:27:10","date_gmt":"2026-06-15T12:27:10","guid":{"rendered":"https:\/\/www.europesays.com\/ai\/74244\/"},"modified":"2026-06-15T12:27:10","modified_gmt":"2026-06-15T12:27:10","slug":"defenseclaw-for-on-prem-ai-soc-workflow-at-black-hat-asia","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/ai\/74244\/","title":{"rendered":"Defenseclaw for On-Prem AI SOC Workflow at Black Hat Asia"},"content":{"rendered":"

Connecting\u00a0OpenClaw\u00a0to\u00a0Ollama, and protecting it with\u00a0DefenseClaw<\/a>.<\/p>\n

Black Hat Asia<\/a>\u00a0gave me a practical environment to test an idea I have been thinking about for a while: how can we bring AI into SOC workflows without immediately pushing sensitive security data into an external cloud model?<\/p>\n

In a previous\u00a0blog<\/a>, I looked at how often AI tools showed up in real network traffic. That led to the next question:\u00a0If users and analysts are already leaning on AI, can we build a private AI workflow that runs local models, connects to SOC tools, and still gives security teams the inspection and audit visibility they need?<\/p>\n

Why Local AI Matters for SOC Teams<\/p>\n

SOC analysts deal with repetitive, high-volume work every day: alert triage, phishing review, log summarization, incident context gathering, and deciding whether an event needs escalation. AI can help with that work, but security data is sensitive. Prompts may include internal hostnames, usernames, detections, packet metadata, log snippets, and incident details\u2026and even passwords\/credentials.<\/p>\n

The goal of this project was not to replace analysts. The goal was to build a private assistant that could help with Tier 1 SOC workflows;\u00a0while keeping model execution, prompts, responses, and audit telemetry under local control.<\/p>\n

The Base Architecture: Local Models with Guardrails<\/p>\n

\"On-premCaption: The on-prem\u00a0Ollama\u00a0architecture used as the foundation for the local AI SOC workflow<\/p>\n

The architecture image shows the full request path from the SOC analyst through Duo\u00a0Directory Single Sign-On, Nginx TLS termination, Open WebUI, the\u00a0FastAPI\u00a0inspection proxy, and\u00a0Ollama, with NVIDIA GPU passthrough for model execution and sidecar MCP containers connecting the workflow to Cisco XDR and Endace Vault.<\/p>\n

The first part of the project was the local model stack. I ran\u00a0Ollama\u00a0directly on an Ubuntu host with NVIDIA GPU acceleration. Open WebUI ran in Docker and provided the initial analyst-facing chat interface.<\/p>\n

\"AICaption:\u00a0Prompt and Responses being seen in AI defense<\/p>\n

The important design decision was to avoid letting Open WebUI talk directly to\u00a0Ollama. Instead, I placed a\u00a0FastAPI\u00a0proxy in the request path. The flow looked like this:<\/p>\n

Analyst -> Open WebUI -> AI Defense\/FastAPI proxy -> Ollama on Ubuntu with NVIDIA GPU
\nAnalyst <- Open WebUI <- AI Defense\/FastAPI proxy <- Ollama on Ubuntu with NVIDIA GPU <\/p>\n

That proxy allowed Cisco AI Defense inspection to happen before prompts reached the local model and again before model responses returned to the user. This gave the deployment a place to enforce policy, inspect risky inputs or outputs, and keep the local model experience from becoming an unmonitored blind spot.<\/p>\n

\"OpenCaption: Open WebUI selecting locally hosted\u00a0Ollama\u00a0models running on the GPU-backed Ubuntu host\u00a0including cisco foundations AI model imported from hugging face<\/p>\n

The other important piece was tool access. A local model is useful, but a SOC assistant becomes much more valuable when it can reach the systems analysts already use. For this, I used MCP sidecars to expose integrations such as Cisco XDR and Endace Vault workflows into the Open WebUI environment. In total, the Open WebUI front end exposed six MCP integrations: Cisco XDR Community, Cisco XDR Conure, Endace Vault, Splunk, Cortex, and ThousandEyes.<\/p>\n

\"MCPCaption: MCP integrations exposed to the local AI workflow for SOC investigation context<\/p>\n

At this stage, the system was already useful. An analyst could ask a local model to explain a detection, summarize an incident, or help reason through suspicious activity. But the interaction model was still mostly chat-based: the analyst asks a question, the model answers, and the analyst drives the next step.<\/p>\n

That is where\u00a0OpenClaw\u00a0changed the architecture.<\/p>\n

Why\u00a0OpenClaw\u00a0Changed the Architecture<\/p>\n

Open WebUI is a strong interface for human-driven interaction with a model. It is familiar, simple, and effective for direct questions. But many SOC tasks are not single-turn questions. They are workflows.<\/p>\n

For example, an analyst may want to start with a high-level objective:<\/p>\n

Investigate this suspicious login alert, gather relevant context, check for related detections, and summarize whether this should be escalated.<\/p>\n

That type of task requires planning, tool use, intermediate reasoning, and a final summary. The analyst should not need to manually break every investigation into a dozen separate prompts.<\/p>\n

I installed\u00a0OpenClaw\u00a0on a second VM and connected it back to the same\u00a0Ollama\u00a0model backend. This let the local model infrastructure support a more agentic workflow. Instead of only asking the model a question, the analyst could delegate a constrained investigation task.<\/p>\n

\"AICaption:\u00a0OpenClaw\u00a0using the local\u00a0Ollama\u00a0model backend instead of an external model provider<\/p>\n

The distinction is important. The model still runs locally, but\u00a0OpenClaw\u00a0adds the orchestration layer around it. It can maintain task state, call tools, reason through multiple steps, and produce a final answer based on the evidence it gathered.<\/p>\n

In practice, this moved the architecture from:<\/p>\n

Human asks local model a question<\/p>\n

to:<\/p>\n

Human delegates a bounded investigation workflow to an agent using local models and approved tools<\/p>\n

For SOC use cases, this is the more interesting direction. A chat interface can help explain an alert. An agentic workflow can help collect context, summarize findings, and leave the analyst with a clearer decision point.<\/p>\n

Adding\u00a0DefenseClaw\u00a0and Splunk Visibility<\/p>\n

Once OpenClaw entered the architecture, visibility became even more important. Agentic workflows can take multiple steps, call tools, and generate intermediate outputs. If a SOC team is going to trust that workflow, it needs an audit trail.That is where DefenseClaw came in. I installed DefenseClaw alongside the OpenClaw environment,\u00a0to add inspection and audit visibility around the agentic AI workflow.<\/p>\n

\"DefenseClawCaption:\u00a0DefenseClaw\u00a0running with\u00a0OpenClaw\u00a0proxy enforcement, showing gateway, agent, watchdog, guardrail, API, and sink services active, along with enforcement counters for scans and alerts<\/p>\n

The\u00a0DefenseClaw\u00a0dashboard gave me a quick operational view of the agentic AI control plane, including whether\u00a0OpenClaw\u00a0enforcement was active, which local services were running, how many scans and alerts had been observed, and whether any setup checks still needed attention.<\/p>\n

The next step was to send\u00a0DefenseClaw\u00a0inspection and audit events into Splunk using the HTTP Event Collector. This made Splunk the operational record for AI activity.<\/p>\n

In Splunk, the\u00a0defenseclaw\u00a0index captured audit events from the\u00a0OpenClaw\u00a0workflow, including tool inspection actions such as\u00a0inspect-tool-allow, the\u00a0OpenClaw\u00a0agent name, target MCP tool, severity, request ID, run ID, and timestamp.<\/p>\n

Instead of treating AI prompts and agent actions as something separate from the SOC, the events became searchable alongside the rest of the security telemetry. That matters for\u00a0more than one reason;\u00a0Analysts can see what AI workflows were used\u00a0and\u00a0organizations\u00a0get a record of AI activity instead of a black box.<\/p>\n

\"DefenseClawCaption:\u00a0DefenseClaw\u00a0audit events sent to Splunk\u00a0via\u00a0HEC<\/p>\n

This was one of the most important parts of the project. Running a local model is useful. Running an agentic workflow is more powerful. But making the workflow inspectable and auditable is what makes it relevant to real security operations.<\/p>\n

Potential\u00a0SOC Use Cases<\/p>\n

I targeted a few\u00a0initial use cases focused on Tier 1 SOC workflows where analysts spend time gathering context, summarizing data, and deciding whether to escalate.\u00a0<\/p>\n

Incident Context<\/p>\n

Another workflow was incident explanation. When an alert appears in a system such as Cisco XDR, a Tier 1 analyst may need help understanding what the detection means, what evidence is available, and what should be checked next.<\/p>\n

The local assistant can summarize the alert in plain language, explain why the behavior may matter, and suggest the next few investigation steps. With MCP integrations, the workflow can also pull supporting context from connected SOC tools.<\/p>\n

Log Summarization<\/p>\n

Security logs are valuable, but they are rarely written for quick human reading. A local model can help turn noisy event data into a concise investigation summary:<\/p>\n

What happened?<\/p>\n

Which systems or users were involved?<\/p>\n

Is there related activity?<\/p>\n

What is the likely risk?<\/p>\n

What should the analyst verify next?<\/p>\n

The key lesson was that the model should not receive unlimited raw logs. Preprocessing and filtering are still necessary. The better the context, the better the answer.<\/p>\n

PCAP and Packet-Capture Workflows<\/p>\n

The project also included Endace Vault\u00a0API\u00a0integration. The goal was not to dump full packet captures into a model. That would quickly run into context and performance limits.<\/p>\n

The more practical pattern is targeted workflow assistance: identify the right capture window, request or locate relevant packet data, summarize metadata, and help guide the analyst toward the traffic that deserves deeper inspection.<\/p>\n

For deeper packet analysis, specialized tooling and preprocessing are still required. The local model is helpful as an assistant, not as a replacement for packet analysis tools.<\/p>\n

Agentic Investigation<\/p>\n

The most interesting use case was the agentic one. Instead of asking a single question, the analyst gives\u00a0OpenClaw\u00a0a bounded objective.\u00a0OpenClaw\u00a0can then use the local model, call approved tools, reason through the task, and produce a summary.<\/p>\n

DefenseClaw\u00a0and Splunk visibility make that workflow much easier to evaluate\u00a0and secure. The SOC can review not just the final answer, but the activity around the workflow.<\/p>\n

Lessons Learned<\/p>\n

The first lesson was that\u00a0while\u00a0local models are\u00a0data sovereign, having an enterprise grade GPU is not the magic\u00a0wand to fix all AI problems. Response times can still be slow.<\/p>\n

The second lesson was that context matters more than almost anything else. Raw logs, long incident histories, and full packet captures can overwhelm the model or produce unfocused answers. Scripts, filters, retrieval, and summarization steps are necessary parts of the architecture.<\/p>\n

The third lesson was that\u00a0AI\u00a0guardrails need visibility. It is not enough to inspect AI activity. Analysts and administrators need to see the audit trail, search it, and understand what happened. Sending\u00a0DefenseClaw\u00a0events into Splunk made the AI workflow feel more operational and less experimental.<\/p>\n

The fourth lesson was about interfaces. Open WebUI is a good experience for direct chat with local models.\u00a0OpenClaw\u00a0is the better story when the goal is agentic SOC workflows. The two are related, but they solve different parts of the problem.<\/p>\n

Finally, the project reinforced that on-prem AI changes the conversation. When models, prompts, responses, and inspection telemetry stay under local control, security teams can experiment with AI in a way that better fits sensitive SOC environments.<\/p>\n

What Comes Next<\/p>\n

There are several areas I want to improve.<\/p>\n

Firstly, the tool context can get better. Cisco XDR, Splunk, Endace, and other SOC platforms all contain valuable context. Improving retrieval, MCP tool use, and workflow design will make the assistant more useful.\u00a0The tool calling consistency\u00a0is\u00a0the most critical area for improvement\u00a0in order for the AI to feel\u00a0genuinely useful.<\/p>\n

Next, the project needs more formal measurement. I want to track model latency, inspection overhead, event volume, false positives, and analyst feedback. Without metrics, it is difficult to compare model sizes, GPU choices, and workflow designs.<\/p>\n

Finally, the deployment needs more production hardening. For a lab or event environment, local environment files are convenient. For production, secrets management, scalable state, and cleaner operational controls become more important.<\/p>\n

Closing<\/p>\n

The most interesting part of this project was not simply running\u00a0Ollama\u00a0on an NVIDIA GPU. The more important lesson was what happens when local inference is combined with an agentic interface, inspection, tool access, and Splunk auditability.<\/p>\n

At Black Hat Asia, this became a practical way to explore what private AI for SOC workflows could look like. Open WebUI gave me the starting point.\u00a0OpenClaw\u00a0moved the project toward agentic investigation.\u00a0DefenseClaw\u00a0and Splunk made the activity visible. MCP integrations connected the assistant to the tools analysts already use.<\/p>\n

For anyone who wants to look at the deployment approach, I published the project\u00a0here<\/a>.<\/p>\n

Black Hat environments are useful proving grounds because they combine real traffic, real analysts, real tooling, and compressed deployment timelines. That is exactly the kind of environment where practical SOC innovation gets tested quickly.<\/p>\n

Check out the other blogs from our team at Black Hat Asia 2026.<\/p>\n

About Black Hat<\/p>\n

Black Hat is the cybersecurity industry\u2019s most established and in-depth security event series. Founded in 1997, these annual, multi-day events provide attendees with the latest in cybersecurity research, development, and trends. Driven by the needs of the community, Black Hat events showcase content directly from the community through Briefings presentations, Trainings courses, Summits, and more. As the event series where all career levels and academic disciplines convene to collaborate, network, and discuss the cybersecurity topics that matter most to them, attendees can find Black Hat events in the United States, Canada, Europe, Middle East and Africa, and Asia. For more information, please visit\u00a0www.Black Hat.com<\/a>.<\/p>\n

We\u2019d love to hear what you think! Ask a question and stay connected with Cisco Security on social media.<\/p>\n

Cisco Security Social Media<\/p>\n

LinkedIn<\/a>
Facebook<\/a>
Instagram<\/a><\/p>\n

\t