BreachLens - Splunk MCP SOC Copilot

• 

  Title Picture

Inspiration

SOC teams are dealing with more alerts every year, and analysts need help turning noisy signals into clear triage and response decisions. I built BreachLens because I wanted an AI-assisted SOC workflow that still behaves like security tooling: useful, fast, and auditable.

A lot of AI security demos look good until you ask, “Where did that claim come from?” In incident response, a confident unsupported answer is worse than no answer. BreachLens is my attempt to make AI helpful without letting it guess its way into an incident report.

What it does

BreachLens starts with a suspicious Splunk alert and runs a guided investigation across identity, cloud, endpoint, and proxy telemetry.

It builds an incident timeline, maps behavior to MITRE ATT&CK, suggests response actions, drafts detections, and exports an evidence ledger plus Markdown incident report. The UI also shows a proof strip for the active runtime, including live Splunk MCP mode, NiNa(LLM)/Ollama, MCP tool calls, and evidence count.

The AI analyst note is evidence-gated: NiNa (LLM) can summarize the incident, but every accepted claim has to cite real Splunk evidence IDs and fields.

How we built it

I built a local Splunk app with a breachlens index, JSON sourcetypes, synthetic breach telemetry, saved searches, macros, and a dashboard.

The backend is FastAPI. It supports three modes: local Splunk REST, Splunk MCP Server, and offline sample data. In MCP mode, BreachLens records the tool path and shows transport=mcp in the SPL transcript so MCP proof is based on the actual runtime, not just MCP-looking labels.

The frontend is a React/Vite SOC console with an alert queue, proof strip, evidence drawer, timeline, MITRE mapping, response plan, SPL transcript, exports, and detection drafts. NiNa runs locally through Ollama.

Challenges we ran into

One challenge was making sure the demo proved what it claimed. It is easy for an app to show tool-like names in a transcript, but that does not automatically prove the calls went through MCP. I wanted the proof to be explicit, so BreachLens records the transport for every transcript entry and only counts the MCP proof calls when they show transport=mcp.

Another challenge was keeping the AI useful without making it too trusted. A model can write a convincing incident summary, but that is not enough for a SOC workflow. I added an evidence gate so the backend checks that the AI response uses valid statuses, real evidence IDs, and field references that came from Splunk.

The last challenge was balancing depth with demo clarity. BreachLens touches Splunk data, MCP tool calls, NiNa/Ollama, evidence validation, MITRE mapping, response actions, detections, and exports. I had to keep the workflow understandable without hiding the parts that make it auditable.

Accomplishments that we're proud of

I’m proud that BreachLens feels like a real analyst workflow, not just a chatbot attached to logs.

The project shows live Splunk MCP proof, evidence-backed findings, NiNa(LLM)/Ollama integration, raw Splunk evidence links, detection drafts, MITRE mapping, response actions, and exportable incident artifacts.

I’m also proud of the evidence gate. It forces the AI to work inside boundaries an analyst can audit, which is exactly where I think AI belongs in security operations.

What we learned

I learned that the hard part of AI in SOC workflows is not generating text. The hard part is making the text accountable to evidence.

I also learned that proof matters in demos. It is not enough to say “this uses MCP”; the UI needs to show the runtime, tool calls, and transcript transport clearly.

Finally, I learned that a useful copilot should reduce analyst load without hiding the reasoning path. The analyst still needs to see what was queried, what evidence came back, and why the response plan makes sense.

What's next for BreachLens - Splunk MCP SOC Copilot

Next, I want to make the evidence gate stricter by checking not only that evidence IDs and fields exist, but that each claim is semantically supported by those fields.

I also want to add more investigation playbooks, more detection templates, richer Splunk dashboards, and support for additional local or enterprise-hosted models.

Longer term, BreachLens could become a reusable SOC triage layer where analysts can move from alert to evidence package in minutes while keeping every AI-assisted conclusion auditable.

Built With

• docker
• docker-compose
• fastapi
• llm
• mitre-att&ck
• nina
• ollama
• playwright
• python
• react
• splunk-clients
• splunk-enterprise
• splunk-mcp-server
• splunk-rest-api
• typescript
• vite