Agentic SOC Alert Enrichment

01 / Gap Triage starts with twenty minutes of tab-switching

An analyst opens an alert and immediately goes hunting for context that lives in three different consoles. Sentinel has the incident and the correlated signals. Defender has the endpoint state and the user’s risk score. CrowdStrike has the process tree and the detection detail. None of them talk to each other, so the analyst becomes the integration layer: copy an entity, paste it into the next tool, repeat.

That context is entirely knowable. Gathering it by hand is just tax, paid 5–10 times a shift, 10–30 minutes per alert, before triage even begins.

02 / Bet Hand the gathering to an agent, not the analyst

The instinct is to train analysts to pivot faster or to wire up brittle point-to-point integrations. Both miss the real shape of the problem. The gathering is mechanical and repeatable, which is exactly what an agent is for.

So: an LLM agent that can call each tool the way an analyst would, pull the same context, and write it back onto the alert before anyone opens it. Triage starts with the picture already assembled.

The hard part was never the model. It’s giving an agent safe, scoped access to live security tooling and trusting what it writes back.

03 / System How it’s wired

When an alert fires, an agent built in Copilot Studio is triggered. It reaches each security tool through an MCP server that exposes a deliberately narrow set of read-only actions. The agent decides which context is relevant for the alert type, calls the tools, and assembles a single enrichment block that gets written back to the incident.

What it pulls

• Sentinel — the incident timeline, correlated alerts, and the entities already mapped to it
• Defender — device health, logged-on users, and the endpoint’s recent risk signals
• CrowdStrike — the process tree and detection context for the host in question

Guardrails (the part that actually mattered)

• Read-only scopes. The MCP servers expose retrieval actions only. The agent annotates; it never closes, isolates, or acts.
• Data stays in tenant. Alert content is passed to the model within the Azure OpenAI deployment in-tenant, not to a third-party endpoint.
• Everything is logged. Each enrichment records which tools were called and what was returned, so an analyst can audit the agent’s work instead of trusting it blind.
• Fails quiet. If a tool call fails or returns nothing, the alert lands un-enriched rather than with a confident guess.

04 / Result What changed

No hard numbers yet — the meaningful shift is qualitative. An analyst opening an alert used to spend the first stretch of triage just assembling the picture: pull the incident from Sentinel, pivot to Defender for the endpoint, open CrowdStrike for the process tree. That’s before any actual judgment has happened.

Now the enrichment block is already on the incident when the ticket opens. The analyst’s first move is evaluation, not collection. The context is sourced, assembled, and logged — and if the agent missed something or a tool call failed, that’s visible too rather than silently absent.

05 / Next Where it goes

• Agent tuning — the current prompt and tool-selection logic is calibrated for the initial alert corpus. The next phase is broadening coverage across alert types and adding a confidence signal to each enrichment block so analysts can see at a glance whether the context is complete or partial.