Building an Agentic SOC Analyst with Microsoft Sentinel, Azure Log Analytics, and Gemini

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.