Daily.Entra.NewsAgent Conditional Access is the clear center of the 7 October update: a new Entra ID guide covers agents operating through their own user accounts, while Agent ID guidance separates agent identities, agent user accounts, and delegated or on-behalf-of access. The guidance directs administrators to match policy targeting to the token subject and check the stated licensing, role, device, network, registration, and OAuth prerequisites. A separate authentication update refreshes FIDO2 attestation data.
Entra ID · Conditional AccessThe new Entra ID Conditional Access guide covers agent risk, compliant devices, and compliant networks for agents that use their own user accounts. It states that policies targeting all users do not include agent user accounts, so administrators must target agent users separately and satisfy the listed licensing, role, device, and network prerequisites.
Agent ID · Conditional AccessUpdated Agent ID guidance says the signed-in user is the token subject for on-behalf-of traffic, whether targeted directly or through groups, and directs administrators to user-targeted policies for those resources. Selecting an agent identity is documented for a different access pattern.
Agent ID · Conditional AccessThe revised guidance centers policies on agents using their own identities, adds licensing, role, registration, and OAuth prerequisites, and recommends report-only block policies for unapproved agents.
Entra ID · GeneralThe Policy Autonomous Agents page lists Microsoft 365 E7, or Microsoft Agent 365 paired with Microsoft Entra P1 or Microsoft 365 E3, and says Agent 365 will soon be required.
Entra ID · AuthenticationThe attestation page now references MDS version 285 instead of 279 and adds five FIDO2 security-key models with their AAGUIDs and capability indicators. Administrators evaluating key attestation should use the updated identifiers.
This period briefing was generated by AI from the tracked Microsoft Learn and Message Center changes.
The documentation now specifies Microsoft Entra ID P1 or Microsoft 365 E3 for Conditional Access, and Microsoft Entra ID P2 or Microsoft 365 E5 when using agent risk-based Conditional Access with Microsoft Agent 365.
The documentation adds links and clarifies that relevant agents run on Intune-managed Windows 365 Cloud PCs, with Global Secure Access for compliant network policies. It also refines targeting, assignment, and risk-level guidance.
The documentation now uses corrected step numbering and clearer instructions for excluding agent blueprints or identities and creating custom attributes and predefined values.
The documentation now lists Microsoft 365 E7, or Microsoft Agent 365 paired with Microsoft Entra P1 or Microsoft 365 E3, instead of a general Entra ID P1 or P2 requirement.
The documentation now lists two licensing options: Microsoft 365 E7, or Agent 365 paired with Microsoft Entra P1 or Microsoft 365 E3. It also states that Agent 365 will soon be required.
The guidance now links to the Windows 365 Cloud PC for Agents introduction and the Entra Global Secure Access overview.
The documentation now says Microsoft 365 E7 protects access for both users and agents, replacing wording about governance of user and agent identities.
The documentation now references MDS version 285 instead of 279 and adds five FIDO2 security key models with their AAGUIDs and capability indicators.
A new guide explains how to apply Conditional Access to agents using their own user accounts, including policies for agent risk, compliant devices, and compliant networks. It also documents agent-specific targeting and prerequisites.
The September row now includes an additional 99.999% value in the performance reference table.
The page now covers agent identities and additional policy options, including custom security attributes, agent execution environments, device compliance, network locations, and agent risk. It also updates policy creation steps and links.
The documentation now refers to real-time risk information, rather than session risk information, among the signals used to determine access.
The autonomous agents policy documentation now includes a section for custom security attributes in policies.
The Agent ID documentation now uses the correct anchor for the “Allow approved agents by using custom security attributes” policy example.
The policy example link now points to the `use-custom-security-attributes` section.
The article now focuses on Conditional Access for agents using their own identities, adds prerequisites, clarifies that policies target agent identities rather than users, and recommends report-only block policies for unapproved agents.
The article now documents the enhanced object picker for selecting agent identities and blueprints, updates policy-creation steps, and notes that an Agent 365 license will soon be required.
The overview now explains policy decisions, evaluation timing, token subjects and audiences, and supported agent access patterns. It also adds links to related identity-management and policy guidance.
The overview now explains how Conditional Access evaluates the token subject and resource, and distinguishes delegated, agent-identity, and agent-user-account scenarios. Licensing and network-control requirements remain documented.
The article now covers selecting agent identities or agent user accounts, explains that conditions and controls depend on the token subject, and updates related links and terminology.
The documentation now states that Microsoft Entra ID Conditional Access for agents requires an eligible license plan, including Microsoft 365 E7 with Agent 365 and Microsoft Entra Suite. The explanatory governance phrase was removed.
The documentation now states that Conditional Access evaluates the signed-in user who is the token subject, including users targeted directly or through groups. Selecting an agent identity does not cover OBO traffic.
The documentation clarifies that Conditional Access policies targeting agent identities do not apply to on-behalf-of (OBO) traffic, because the user is the subject of that flow.
The licensing requirements now list Microsoft 365 E7, or Microsoft Agent 365 paired with at least Microsoft Entra P1 or Microsoft 365 E3.
The Microsoft Agent 365 licensing prerequisite bullet was reformatted for consistency.
The Conditional Access Agent ID page now links to Microsoft Agent 365 plans and pricing instead of the Agent ID getting-started information.
The agent identity targeting documentation now links to the relevant section on Conditional Access policies and agent identity blueprints.
The documentation clarifies that policies scoped through the Users assignment do not apply to agent user accounts, regardless of whether they target all users, selected users, groups, directory roles, or external users. To protect agents, select Agents under Users, agents, or workload identities.
The documentation now identifies the agent identity, rather than the application or autonomous agent, as the subject in application-only access.
