Securing enterprise AI agents with Microsoft Sentinel: a monitoring blueprint

An agent that can read, decide, and call tools is a new kind of insider. Give your SOC the telemetry to watch it.

Copilot, Copilot Studio, Azure AI Foundry, and custom agents are moving into finance, IT, and customer workflows. Each one holds an identity, accepts instructions in plain language, and can act on business systems. That combination creates an attack surface that classic log monitoring was never designed to cover.

If you cannot reconstruct what an agent was asked, what it did, and as whom, you cannot investigate it.

Six questions your SOC must be able to answer

Microsoft’s guidance centers on end-to-end visibility across an agent’s life. We turn that into six investigative questions, each tied to a data source.

Question	Evidence you need
Who asked, and what?	User prompts and Copilot activity logs
What path did the agent take?	Agent execution traces from observability data
Which tools did it call?	Tool and MCP invocation records
Did safety controls fire?	Prompt-safety signals from Defender for AI
Whose identity did it use?	Agent identity records
Did anything alert?	Defender XDR detections and Sentinel incidents

Reference architecture

Sentinel works best as the place where these signals meet. Agent telemetry flows in on the left, detections add meaning, and Sentinel correlates everything into incidents people can act on.

Agent estate

• Microsoft 365 Copilot
• Copilot Studio agents
• Azure AI Foundry agents
• Custom agents on business apps

Telemetry

• Agent observability data
• Agent identity records
• Copilot activity logs
• Cloud app events

Detection

• Defender XDR alerts
• Defender for AI safety signals

Microsoft Sentinel

• Correlate across sources
• Hunt for misuse
• Investigate incidents
• Retain evidence

Action

• Incident response
• Access and policy changes
• Governance reporting

Data sources follow Microsoft’s published guidance. The layout and grouping are our design.

What this unlocks

Threat hunting

Search for odd prompts, unusual tool use, or agents reaching data they never touched before.

Incident response

Link a risky prompt to the identity, tool call, and alert in one timeline.

Governance

Show auditors which agents exist, what they can do, and how they behave.

Forensics

Rebuild a past agent session step by step after something goes wrong.

Five design rules

1. Give every agent its own identity. Shared service accounts make attribution impossible.
2. Log every tool call, not just every prompt. Harm happens when the agent acts.
3. Correlate on a shared key. Tie prompt, identity, tool call, and alert together so one query tells the story.
4. Set retention for investigation, not storage cost. Agent incidents are often found late.
5. Start with the riskiest agents. Cover those that touch sensitive data or can change systems first.

Takeaway

AI agents do not need a separate security program. They need the same discipline you apply to privileged users: known identity, full audit trail, and detections that understand their behavior. Sentinel can be the place where that picture comes together.

Source

Microsoft Tech Community, “Securing Enterprise AI Agents with Microsoft Sentinel”. The six questions, architecture layout, and design rules are our own framework.