ID Protection for agents (Risky Agents)

Why this matters

An agent that runs continuously with credentialed access to Graph, Azure resources, and MCP tools is a valuable target. Once an attacker gets a foothold — via a stolen FIC token, a leaked blueprint credential, or an over-permissive OBO chain — the blast radius is far worse than a compromised human user. Microsoft's answer is ID Protection for agents, which extends the existing risky-user machinery to agent identities with an agent-specific detection set and remediation model.

Cross-ref: Lesson 8.1 (Prompt injection + token theft) and Lesson 8.2 (MCP supply chain) tell you what attackers do; this lesson is Microsoft's detection surface for those attacks at the identity layer. Pair it with Conditional Access (Lesson 10.5) for automated response.

Learning objectives

1. Know the eight agent risk signals ID Protection currently emits and what triggers each.
2. Understand Learning Mode and why brand-new agents get a grace period.
3. Understand the OBO risk attribution rule (why OBO risk lands on the user, not the agent).
4. Query riskyAgents / agentRiskDetections via Microsoft Graph.
5. Wire ID Protection risk into Conditional Access for auto-response.

1. The eight agent risk detections

Currently all detections are offline (post-facto batch scoring, not real-time), but they feed Conditional Access which is near-real-time via CAE. Detections apply to autonomous agent activity; OBO risk attributes to the user (Section 3).

Two things to notice:

• These map very directly to the attack patterns in Lesson 8 (token theft, confused deputy, lateral movement, prompt-injected exfil). ID Protection is Microsoft's implementation of ITDR for agents.
• Several signals require baseline learning. A brand-new agent has no baseline → hence Learning Mode.

2. Learning Mode — the newborn grace period

Agents with no history would otherwise trigger dozens of false positives on day 1 (every access is "unfamiliar", every sign-in a "spike"). ID Protection has Learning Mode:

• Newly created (or long-dormant) agents have their behavioural detections (spikes, unfamiliar resource access, etc.) auto-suppressed.
• Meanwhile the early-life malicious activity detector runs in parallel — so genuine "attacker registered this agent" behaviour is still caught.
• After enough legitimate activity, Learning Mode ends and behavioural detections start firing normally.

Implication: don't panic if a fresh agent's risk stays at None for the first day even though you know it's active. That's Learning Mode. Do panic if earlyLifeMaliciousActivity fires — that means the newborn is doing attacker-like things and Learning Mode is not going to save it.

3. OBO risk attribution rule (memorise this)

In OBO flows, risky behaviour is attributed to the user, not the agent.

Rationale: the agent is a shared piece of software running for many users; disabling the agent globally because Alice's session leaked would break Bob, Charlie, and Diana. Instead, the risk lands on Alice's session and any user-scoped ID Protection policies (block risky users, require password change, revoke sessions) apply.

Consequences:

• Do not write a CA policy that fires on "agent risk = high" and expect it to catch OBO abuse.
• Do write a user CA policy on the app used to invoke OBO agents — the risk will attribute there.
• Your autonomous flows will fire agent risk normally.

Only the autonomous and agent-user account flows attribute risk to the agent object.

4. Where risky agents surface

4.1 ID Protection dashboard (Entra portal)

A tile summarises risky agents by risk level. Click through to the Risky Agents report — the equivalent of Risky Users but for agent identities. From there you can:

• Filter / sort by agent, risk state, risk level.
• Drill into a specific agent's risk detections (last 90 days of retention).
• Take action inline.

4.2 Actions available on a risky agent

4.3 Microsoft Graph APIs

Two collections in the ID Protection Graph surface:

• GET /identityProtection/riskyAgents — current risky-agent list with id, displayName, riskLevel, riskState, riskDetail, sponsors.
• GET /identityProtection/agentRiskDetections — the raw detection events (up to 90 days).

You can filter, page, and export. Feed both into your SIEM.

Example — top current risky agents by risk level:

GET https://graph.microsoft.com/beta/identityProtection/riskyAgents
     ?$filter=riskLevel eq 'high'
     &$select=id,displayName,riskLastUpdatedDateTime,sponsors

Example — all detections in the last 7 days for a specific agent:

GET https://graph.microsoft.com/beta/identityProtection/agentRiskDetections
     ?$filter=agentId eq '9d6f8e73-...-agent-identity'
        and detectedDateTime ge 2026-06-01T00:00:00Z

Rule: write both to Splunk / Sentinel via diagnostic settings → Log Analytics → your SIEM. That way agent risk is queryable alongside user risk, sign-in logs, and Defender alerts.

5. Automated response — CA template

The recommended pattern is CA policy that blocks agents with High risk. Microsoft ships a CA template exactly for this:

Policy: Block high-risk agents
  Assignments:
    Include: All agent identities
  Conditions:
    Agent risk level: High
  Access controls:
    Grant: Block access
    (No exceptions)
  State: On

Combined with CAE-supported resources, this means:

• Admin clicks Confirm compromise in the portal (or your SIEM rule POSTs confirmCompromised via Graph).
• Risk elevates to High immediately.
• CA blocks the next token request.
• CAE-supported resources (Graph, Exchange, SharePoint, Teams) revoke active tokens within ~5 minutes.
• Agent is effectively offline until you remediate + confirm safe.

No human in the loop between detection and response for the "confirmed compromised" case. That's what you want.

6. Response playbook — from detection to closed ticket

You need a runbook. Suggested playbook (adapt to your SIEM + IR process):

1. Detection fires — agentRiskDetections receives a new event (e.g. suspiciousCredentialUsage).
2. SIEM alert — Splunk / Sentinel rule creates a P2 ticket. Include agent oid, blueprint, sponsor, recent audit events.
3. On-call review — check the recent audit log for the agent, check who added the new credential (was it a legitimate CI/CD run or a stranger?), check sponsor and page them.
4. If real: Confirm compromise in ID Protection → CA blocks it → CAE revokes active tokens → escalate to incident response.
5. If false positive: Confirm safe → dismiss detection with rationale → document in the ticket for future tuning.
6. Root cause + remediation: rotate blueprint credentials (best case: rotate FIC managed identity), audit all sibling agents from the same blueprint, review the sponsor + owner assignments.
7. Post-mortem: did the attacker exploit an inheritable permission? A dev secret? A misconfigured CA policy exclusion? Update controls.

Keep the runbook alongside your Module 8 attack response playbooks.

7. Integration with your existing SIEM / SOAR

• Splunk / Sentinel input: Diagnostic settings on the Entra tenant → forward RiskyAgents and AgentRiskDetection categories to a Log Analytics workspace / event hub / SIEM.
• SOAR automation: on High detection, automatically call Microsoft Graph POST /identityProtection/riskyAgents/confirmCompromised (requires the Conditional Access Administrator role) if agent matches a "kill switch" tag.
• Reports: weekly report of agentRiskDetections grouped by detection type; long-term trend of "detection → CA block → confirmed compromise" ratio to measure detection quality.

8. Common pitfalls

1. Ignoring Learning Mode. You panic that a busy agent shows no risk on day 1. Wait a week.
2. Trying to catch OBO abuse via agent risk. Doesn't fire; risk attributes to the user. Target the user.
3. Not enabling CAE on the resources you care about. Detection to block gap is minutes vs seconds.
4. No CA policy to auto-block on Confirm Compromise. You mark it compromised and it keeps issuing tokens. Deploy the template.
5. Sponsor not on-call. ID Protection alerts land in the SIEM; the sponsor named on the agent identity is the fastest-context human to investigate. Keep sponsors current (Lesson 10.7).
6. Deleting a risky agent instead of investigating. You lose the audit trail. Disable + investigate first.
7. Not exporting risk data. 90 days retention only; if you need longer for compliance, forward to a Log Analytics workspace / storage account / event hub.
8. Not populating custom security attributes. Without AgentEnvironment=prod you can't write "block risky prod agents" as a precise policy; you either over-block (all agents) or don't block at all.

9. Hands-on lab (2 h)

Prereqs: an Entra tenant with P2 licence trial + Agent 365, plus the agent identities from Lessons 10.2-10.5.

1. In the Entra portal, open ID Protection → Risky Agents. Confirm you see your test agents (probably with Risk = None initially due to Learning Mode).
2. Simulate earlyLifeMaliciousActivity: create a brand-new agent identity, immediately have it try to access three resources it has no permission for. Wait for the batch detection (up to 24 hours in the trial). Verify it appears in the Risky Agents report with earlyLifeMaliciousActivity.
3. Set the CA template "Block high-risk agents" to On.
4. Manually Confirm compromise on a test agent. Immediately try to acquire a token — expect a CA block error.
5. Query Graph:
   http

   GET /beta/identityProtection/riskyAgents?$filter=riskLevel eq 'high'

   Verify the agent appears with the expected riskDetail.
6. Simulate suspiciousCredentialUsage: add a new secret to your test blueprint, then acquire a token with it (dev only). Wait 24 h. Verify the detection appears.
7. Configure diagnostic settings → forward RiskyAgents category to a Log Analytics workspace. Write a KQL query for "all High detections in the last 7 days, by blueprint".
8. Confirm safe on the test agent; verify subsequent token acquisitions succeed.

10. Self-check

1. Which of the eight detections indicates "attacker added a new credential and used it"?
2. Why do OBO flows attribute risk to the user rather than the agent?
3. What does Learning Mode suppress and what does it still let fire?
4. Which admin action immediately elevates risk to High and triggers CA?
5. What are the two Microsoft Graph collections for querying risky agents?
6. What's the max retention for agentRiskDetections if not exported?

11. References

• ID Protection for agents
• Investigate risk with Entra ID Protection
• Vendor-neutral Lesson 8.1 — Prompt injection + token theft (the attacks these detections catch).
• Vendor-neutral Lesson 8.2 — MCP supply chain.
• Vendor-neutral Lesson 7.1 — Audit + provenance (feed detections into your audit + SIEM).