Wiring AI Agent Telemetry into Sentinel to Detect Threats Early

In this blog post Wiring AI Agent Telemetry into Sentinel to Detect Threats Early we will explain how to turn everyday AI agent activity into useful security signals, helping your team detect risky behaviour before it becomes a serious incident.

The problem is not usually that an AI agent suddenly “goes rogue”. It is that a legitimate agent reads a malicious document, uses the wrong tool, accesses more information than expected or repeats an action hundreds of times before anyone notices.

Traditional monitoring may confirm that the application is online and responding quickly. It may not tell you that the agent attempted to export customer records, followed hidden instructions in an email or used a privileged identity outside its normal workflow.

What agent telemetry means in plain English

Agent telemetry is the record of what an AI agent did during a task. It can show who started the request, which agent handled it, what information it accessed, which tools it called, what decisions were blocked and whether the task succeeded.

OpenTelemetry provides a standard way to produce these records. Think of it as a common reporting format that lets different agents, models and business applications describe their activity consistently. Microsoft Agent Framework and Microsoft’s current observability tools can use this standard to produce traces, logs and measurements for agent workflows.

Microsoft Sentinel is the security monitoring platform that analyses those records. Once agent activity reaches Sentinel, it can be compared with Microsoft Entra sign-ins, Microsoft Defender alerts, Azure activity and other security data to identify patterns that would be difficult to see in separate systems.

Our earlier guide to monitoring AI agent activity with Sentinel and OpenTelemetry covers the foundations. The next step is deciding which events matter, routing them reliably and creating detections that lead to action rather than another noisy dashboard.

How the technology fits together

A practical architecture has four parts.

1. The agent records important events. These include model requests, tool calls, data access, policy decisions, errors and task outcomes.
2. OpenTelemetry collects and labels the events. It connects each step using a trace or correlation identifier, allowing investigators to reconstruct the full task.
3. Azure Monitor receives and stores the data. A data collection rule controls the format, removes unnecessary fields and sends the records to the Log Analytics workspace used by Sentinel.
4. Sentinel looks for risky patterns. Detection rules create alerts and incidents, while automation can notify the right team or temporarily restrict an affected identity.

Azure Monitor’s Logs Ingestion API can send custom JSON records into standard or custom Log Analytics tables. Data collection rules act as a gatekeeper, controlling the schema, destination and transformations applied before the information is stored.

Record decisions and actions, not every conversation

A common mistake is sending every prompt and complete AI response into the security platform. This increases storage costs and may create a new collection of sensitive personal, customer or commercial information.

Start with metadata that answers the questions an investigator will actually ask:

• Which agent performed the action?
• Which user, service or agent started the task?
• Which tool was requested?
• What resource or data category was accessed?
• Was the action allowed, blocked or sent for approval?
• How many records, files or messages were involved?
• Did a security control detect prompt injection or unsafe content?
• Which trace identifier links the event to the full workflow?

A simplified event could look like this:

{
 "time": "2026-09-05T02:18:24Z",
 "agentId": "service-desk-triage",
 "runId": "8fe2c921",
 "initiatedBy": "user-1842",
 "eventType": "tool.call",
 "toolName": "reset-user-password",
 "targetResource": "account-5521",
 "actionRisk": "high",
 "approvalRequired": true,
 "actionOutcome": "blocked",
 "promptInjectionDetected": true
}

This tells the security team what happened without automatically storing the full conversation. If prompt content must be retained for investigation, access should be tightly restricted, retention should be limited and sensitive values should be masked.

Build detections around business impact

Do not alert merely because an agent called a tool. Alert when the behaviour differs from what the business approved.

1. A low-risk agent requests a privileged tool

A service desk triage agent may be allowed to classify and route tickets. It should not normally reset passwords, change group memberships or create administrator accounts.

If that agent requests a privileged tool, Sentinel should generate an alert even when the action is blocked. The attempt may reveal prompt injection, a configuration error or an unauthorised change to the agent.

2. A normal task suddenly accesses unusual volumes of data

An agent that usually reads one customer record but suddenly queries 5,000 records may be malfunctioning or being manipulated. Monitoring the volume and sensitivity of accessed information helps detect possible data theft before the information leaves the environment.

3. Prompt injection is followed by a tool request

Prompt injection occurs when malicious instructions are hidden inside content such as an email, document or webpage. The attacker is attempting to make the agent ignore its approved instructions and perform an unintended action.

The strongest alert is not simply “suspicious text found”. It is a chain of events: suspicious content was detected, the agent changed direction and then requested a sensitive tool. Microsoft’s AI security guidance treats indirect prompt injection as a key threat because agents increasingly process untrusted external content.

4. The agent identity behaves differently

Agent activity should be correlated with Microsoft Entra ID, which manages identities and access to company systems. Watch for access from an unexpected location, repeated authentication failures, newly granted permissions or activity outside the agent’s normal resources.

This builds on the identity controls discussed in securing agent-to-agent communication with Microsoft Entra ID. Authentication establishes who the agent is. Telemetry helps confirm that it continues behaving as expected.

A practical Sentinel detection

Sentinel uses Kusto Query Language, usually called KQL, to search security records. The following simplified rule identifies high-risk or unapproved tool calls:

let ApprovedTools = dynamic([
 "search-knowledge",
 "classify-ticket",
 "create-ticket"
]);
AgentTelemetry_CL
| where TimeGenerated > ago(15m)
| where EventType == "tool.call"
| where ToolName !in (ApprovedTools)
 or ActionRisk in ("high", "critical")
| summarize
 CallCount = count(),
 Users = make_set(InitiatedBy, 20),
 Targets = make_set(TargetResource, 20),
 FirstSeen = min(TimeGenerated),
 LastSeen = max(TimeGenerated)
 by AgentId, ToolName, ActionRisk
| where CallCount >= 3
 or ActionRisk == "critical"

The exact thresholds should reflect the agent’s purpose. A payroll agent, customer service agent and software development agent will have very different normal behaviour.

Turn alerts into a response process

Detection is only valuable when someone owns the response. As we discussed in The Defender Alerts Nobody Looked At Until It Was Too Late, many incidents grow because an existing warning was never reviewed.

For every agent rule, document who receives the alert, how quickly it must be reviewed and which actions are safe to automate. A medium-risk event might create a service desk ticket. A critical event could disable a tool connection, revoke an agent credential and notify the security team.

Microsoft Defender can also detect suspicious agent behaviour, including prompt injection, credential leakage and malicious tool use for supported agent platforms. Sentinel remains valuable as the correlation layer that combines these detections with identity, endpoint, cloud and business application evidence. Some newer agent protection capabilities remain in preview, so they should be tested and governed rather than assumed to cover every agent automatically.

A realistic business scenario

Consider a 200-person professional services firm using an agent to summarise client emails and create follow-up tasks. A malicious instruction is hidden in an attached document and tells the agent to search previous correspondence and send the results externally.

Without connected telemetry, the email system, agent platform and identity logs each show only part of the story. With Sentinel correlation, the firm can see the suspicious document assessment, unusual search volume, external tool request and agent identity involved in one incident.

The business outcome is faster containment, less investigation time and a much smaller chance of a reportable data breach.

Start with one agent and five useful detections

You do not need to monitor every possible event on day one. Choose one production agent, define its approved tools and data boundaries, then implement five high-value detections covering prompt injection, privileged tool use, abnormal data volume, identity anomalies and repeated failures.

This approach also supports Australian governance expectations. Agent telemetry does not replace the Essential Eight, the Australian Government’s baseline cybersecurity framework, but it can strengthen monitoring, incident response and evidence around the use of privileged systems.

CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect Azure, Microsoft 365, Defender, Sentinel, OpenAI and Claude into practical controls that security teams can operate.

If you are deploying agents but cannot clearly see what they access, which tools they use or who will respond when something looks wrong, we are happy to review the setup with you—no strings attached.