Security Operations Centers generate an enormous amount of telemetry every day.
Finding meaningful threats isn't usually limited by data.
It's limited by how quickly an analyst can ask the right questions.
That observation led me to build an Agentic SOC Analyst.
The goal wasn't to replace analysts.
The goal was to reduce the time between an investigation idea and actionable findings.
The Problem
A threat hunter often starts with a vague hypothesis.
For example:
"Something unusual happened with this user during the past two weeks."
Turning that into an investigation usually requires:
- Choosing the correct log source
- Understanding the schema
- Writing Kusto Query Language (KQL)
- Running the query
- Reviewing hundreds or thousands of events
- Mapping activity to known attack techniques
I wanted to automate as much of that workflow as possible while keeping humans in control.
The Architecture
The pipeline looks like this:
Natural Language Request
│
▼
Gemini selects table, fields and filters
│
▼
Guardrails validate every selection
│
▼
Generate scoped KQL
│
▼
Query Azure Log Analytics
│
▼
Gemini analyzes results
│
▼
Structured Findings + MITRE ATT&CK Mapping
Every table and field selected by the model is validated against an allow-list before any query is executed.
This prevents hallucinated tables or unsupported fields from reaching Azure.
Features
The current implementation includes:
- Natural-language threat hunting
- Dynamic KQL generation
- Azure Log Analytics integration
- Microsoft Sentinel compatibility
- Table and field allow-list validation
- Structured threat findings
- MITRE ATT&CK mapping
- IOC extraction
- Confidence scoring
- Token usage and cost estimation
- Synthetic dataset generation
- Automated log ingestion into test workspaces
Why Guardrails Matter
One lesson I learned while building AI agents is that models shouldn't have unrestricted access to external systems.
Before any KQL query is executed, the agent validates:
- Requested tables
- Available fields
- Entity filters
- Query scope
Anything outside the approved allow-list is discarded.
The model assists with decision-making, but deterministic code enforces safety.
Building a Test Environment
Testing SOC tooling against production logs isn't practical.
To solve this, I built utilities that generate synthetic Azure Activity, Entra ID sign-in, network, and device log datasets.
These datasets can be ingested into Azure Log Analytics, allowing the entire threat-hunting workflow to be tested safely without exposing sensitive information.
What I Learned
This project taught me that effective AI agents are more than prompt engineering.
They require:
- Clear system design
- Strong guardrails
- Deterministic validation
- Safe tool execution
- Transparent outputs
It also gave me hands-on experience with Microsoft Sentinel, Azure Log Analytics, Kusto Query Language, and designing LLM-powered workflows for cybersecurity.
What's Next?
I'm continuing to improve the agent by exploring:
- Multi-step investigation planning
- Additional Sentinel tables
- Better evidence correlation
- Memory across investigations
- Support for additional SIEM platforms
Building this project reinforced something I've come to believe about AI engineering.
The most valuable AI systems don't replace experts.
They help experts investigate faster while remaining transparent, predictable, and safe.
Top comments (1)
Really interesting use case — this is exactly where “agentic security” starts to feel practical instead of theoretical.
What I like most is the way you’re bridging SIEM pipelines (Sentinel / Log Analytics) with an LLM layer to simulate SOC reasoning. That mapping from raw logs → correlated signals → investigation narrative is where a lot of current SOC tooling still feels fragmented.
One extension that could make this even stronger in real deployments is introducing a clear separation between detection, reasoning, and action layers:
Detection: Sentinel rules + KQL queries (deterministic, audit-friendly)
Reasoning: Gemini agent layer (hypothesis generation, correlation, summarization)
Action: controlled playbooks (SOAR-style, with approvals or strict guardrails)
The key risk with agentic SOC setups is over-trusting the reasoning layer, so having verifiable traceability back to raw log queries becomes critical for audits and incident response confidence.
Also interesting direction: adding a “case memory” layer so the agent can learn from past incidents (false positives, confirmed attacks) and adjust prioritization over time — essentially turning SOC workflows into a feedback-driven system.
Curious if you’ve thought about how you’d prevent alert fatigue when the agent starts generating its own correlated incidents on top of Sentinel rules.