soc-assist — Project Story
Inspiration
I'm new to SOC/SIEM work myself. I installed Splunk, looked at an alert, and felt the "...where do I even start?" paralysis every junior analyst hits on day one. That confusion is the spine of this project. The thing that would have unstuck me was a senior engineer next to me — someone who brings judgment (a playbook, triage, a severity call with a reason) and guardrails (least privilege, sign-off, an audit trail). So the thesis became: the harness is the senior engineer. The judgment is the value; the guardrails are the proof an AI can be trusted to act in production.
What it does
Given an alert context, soc-assist runs a guided, plain-language investigation:
- It investigates read-only — running corroborating SPL through the Splunk MCP server and explaining each query in plain English.
- It returns a verdict with a severity and a stated reason — citing the rubric, and honest about evidence gaps rather than confidently guessing.
- To publish evidence it must clear a human approval gate; on yes, it renders a native Splunk Dashboard Studio view and returns the URL.
- Every query, gate decision, and write lands in a dedicated Splunk audit index — the watcher is watched.
Slack is the doorway; a generated Splunk dashboard is the room. It assists a real analyst through Splunk's own surfaces — it doesn't replace or reinvent them.
How we built it
On the Claude Agent SDK (Python), with the whole architecture mapping 1:1 onto SDK primitives — no web framework, no inbound server, no database. Splunk is the datastore and the audit log. Four planes, separated by privilege:
- READ — the native Splunk MCP server as an external client (read-only).
- WRITE — the only elevated capability: one in-process tool that can physically only POST a dashboard to a single app. The LLM never holds write credentials.
- NOTIFY — Slack, with zero Splunk privilege.
- AUDIT — every action appended to a Splunk index, with its own dashboard.
The security core is the can_use_tool gate: on every write it (a) hard-rejects
out-of-scope targets before any human is asked — so a persuaded human can't bless an
escape — and (b) requires an explicit human yes, defaulting to deny.
Challenges we ran into
- Silent failures, not errors. Wrong MCP tool names and a too-narrow
allowed_toolsentry made the agent quietly do nothing instead of erroring. Only live calls caught it. - The gate's footgun. Any tool in
allowed_toolsbypasses the gate entirely, so the write tool is deliberately not pre-allowed — pre-allowing it would silently disable the whole security story. - Least-privilege leaks by default. The SDK loads global settings and injects ambient MCP servers into a "confined" agent; pinning it down was required for a clean boundary.
Accomplishments that we're proud of
- A least-privilege model that holds even against a fully prompt-injected agent, with a runnable offline proof that the gate can't be exceeded.
- Verdicts that cite their reasoning — severity with a rationale, and honesty about gaps.
- An audit plane where the agent that watches the SIEM is itself observable inside it.
- A genuinely environment-agnostic, public repo — the offline demo needs zero config.
- An elegant coincidence: the approval gate and the "junior makes a decision" teaching moment are the same beat. Security control is pedagogy.
What we learned
- Verify against the live system; never advance on assumption. Plausible-but-wrong docs bit us repeatedly — a unit was only done when its behavior was observed.
- Governance is the product. The AI-specific threat is a compromised or prompt-injected agent, not just a leaked credential — and most agentic tooling over-privileges and doesn't notice. We're the governance layer you wrap around an agent, not a competitor to one.
What's next for soc-assist
- Trigger on a live alert. Today the agent is pointed at an alert context manually; next is firing automatically when a Splunk detection (saved search / alert) does.
- Integrate institutional knowledge — runbooks, past incidents, and internal docs as retrieval context, so the agent reasons with the org's own playbooks, not just generic SOC knowledge.
- Splunk-side role IAM as defense-in-depth — scoping the write to one app at the credential layer, not just the harness.
- Deeper integration with Splunk-native AI features like the Splunk AI Assistant for SPL
(
saia_*) — dropping it in behind the same governance gate as a swappable reasoning backend. - Richer detections and playbooks beyond the demo, each with its own investigative rubric.
Log in or sign up for Devpost to join the conversation.