{"slug": "design-conditional-access-policies-for-agent-identities", "title": "Design Conditional Access policies for agent identities", "summary": "Microsoft Entra ID introduces Conditional Access policies for AI agent identities, enabling organizations to enforce governance based on agent classification and custom security attributes. The approach distinguishes between on-behalf-of, autonomous, and user-like agent patterns, using metadata like approval status and data sensitivity to scale policy enforcement without creating per-agent rules.", "body_md": "This article is part of a multi-part series on Microsoft Entra Agent ID governance. For the full sequence and recommended reading order, start from the [Governing AI agents with Microsoft Entra Agent ID and Agent 365](https://dev.to/stepbysteptocloud/governing-ai-agents-with-microsoft-entra-agent-id-and-agent-365-3a7g)\n\nAfter agent inventory, ownership, sponsorship and custom security attributes are in place, the next step is to turn that governance metadata into policy enforcement. This is where **Conditional Access** becomes important.\n\nThe goal is not to create one policy per agent. That model will not scale. The better approach is to use the information already captured during inventory and classification — such as approval status, access pattern, environment, data sensitivity and risk — to decide which agents should access which resources, and under what conditions.\n\nConditional Access is the point where the governance model starts becoming enforceable.\n\nAgents can access resources in different ways. Some act on behalf of a signed-in user. Some operate independently using their own identity. Some behave more like user accounts with their own mailbox, collaboration context or persistent access.\n\nBecause these patterns are different, one Conditional Access design will not fit every agent type.\n\nBefore creating policies, classify each agent by access pattern:\n\n| Access pattern | What it means | Conditional Access approach |\n|---|---|---|\nOn-behalf-of flow |\nAgent acts in the signed-in user’s context | Review existing user Conditional Access policies |\nAutonomous agent |\nAgent authenticates using its own identity | Use agent-specific Conditional Access policies |\nAgent user identity |\nAgent behaves like a user-like identity with its own access | Use agent-user targeting and supported endpoint/network controls |\n\nThis distinction matters because the policy subject changes. In an on-behalf-of flow, the user is still central to the access decision. In an autonomous agent flow, the agent identity itself becomes the subject of the policy.\n\nFor agents acting on behalf of users, do not immediately assume a new agent-specific policy is required. First review the existing user Conditional Access baseline.\n\nThe organisation should confirm whether existing user policies already enforce the expected Zero Trust posture:\n\nIf the user access path is already well governed, the on-behalf-of agent scenario benefits from those user-context controls. The agent does not bypass the user’s identity governance model simply because it is performing work for the user.\n\nScreenshot: Existing user Conditional Access policy baseline for Microsoft 365 resources\n\nAutonomous agents need a different approach. These agents authenticate using their own identity and may run without a signed-in user present. They cannot satisfy interactive controls in the same way a human user can.\n\nFor these agents, Conditional Access should use agent-specific signals and metadata.\n\nA practical starting point is to use the custom security attributes populated in the previous phase.\n\n| Policy pattern | Suggested targeting | Recommended action |\n|---|---|---|\nAllow only approved agents |\n`ApprovalStatus = Approved` |\nAllow access to selected resources |\nBlock rejected agents |\n`ApprovalStatus = Rejected` or `Revoked`\n|\nBlock access |\nRestrict unknown agents |\n`ApprovalStatus = New` or `ReviewRequired`\n|\nKeep blocked or in report-only validation |\nBlock high-risk agents |\nAgent risk is high | Block access |\nProtect sensitive data access |\n`DataSensitivity = Confidential` or `Restricted`\n|\nApply stricter access decisions |\nSeparate production from test |\n`Environment = Prod` , `Test` , `Sandbox`\n|\nApply different enforcement rings |\n\nThe key design idea is simple: approved agents can proceed, unknown or rejected agents should not be trusted by default.\n\nScreenshot: Conditional Access policy targeting agent identities by custom security attributes\n\nAutonomous agents are not humans. They do not complete MFA prompts. They do not respond to interactive remediation flows. They may not have a compliant device context unless they run through a managed endpoint model.\n\nFor autonomous agents, focus on controls that make sense for non-human access:\n\nAvoid applying human-user policy patterns without reviewing the agent access model. A policy designed for a person may not behave correctly for an autonomous agent.\n\nAgent Conditional Access policies should not be enforced blindly. Start with **report-only** mode and validate the effect.\n\nA safe rollout model looks like this:\n\n| Ring | Purpose |\n|---|---|\nRing 0 — report-only |\nUnderstand impact without blocking access |\nRing 1 — pilot agents |\nApply to selected approved agents |\nRing 2 — production approved agents |\nExpand to known, classified, accountable agents |\nRing 3 — broader enforcement |\nApply across a wider approved population |\n\nThis staged approach reduces risk. It also gives administrators an opportunity to validate sign-in logs, policy impact, exceptions and unsupported scenarios before enforcement.\n\nScreenshot: Conditional Access report-only impact for agent identity policy\n\nA clean Conditional Access design for agents can start with a small number of baseline policies.\n\nUse this policy to prevent agents without the right approval metadata from accessing corporate resources.\n\nTarget agents based on custom security attributes such as:\n\n`ApprovalStatus = New`\n\n`ApprovalStatus = ReviewRequired`\n\n`ApprovalStatus = Rejected`\n\n`ApprovalStatus = Revoked`\n\nThis helps ensure only classified and approved agent identities can proceed to resource access.\n\nUse this policy to ensure approved autonomous agents can access only the resources they are supposed to use.\n\nTarget agents where:\n\n`ApprovalStatus = Approved`\n\n`Environment = Prod`\n\n`AccessPattern = Autonomous`\n\nScope the policy to the relevant resources instead of treating all resources the same.\n\nUse this policy to respond to risky agent behaviour.\n\nIf an agent identity is detected as high risk, block access until the issue is reviewed. The operational response could include reviewing permissions, disabling the agent identity, moving the agent back to `ReviewRequired`\n\n, or retiring the agent if it is no longer valid.\n\nAgents tagged with higher sensitivity or business criticality may need stricter governance.\n\nExample targeting:\n\n`DataSensitivity = Confidential`\n\n`DataSensitivity = Restricted`\n\n`BusinessCriticality = High`\n\n`BusinessCriticality = MissionCritical`\n\nThese agents may need stricter resource scoping, closer monitoring, shorter access durations and stronger approval before access packages are granted.\n\nSome agents may operate with their own user-like identity. These scenarios need separate design consideration because controls such as device compliance, network compliance and endpoint execution context may become relevant.\n\nFor agent users, consider policies that evaluate:\n\nBe careful not to apply endpoint-based requirements to cloud-native agents that have no device context. If the agent has no route to satisfy a device or network condition, the result may be unintended blocking.\n\nScreenshot: Conditional Access policy for agent user identity with endpoint-based conditions\n\nUse consistent naming so policies remain readable over time.\n\nSuggested naming pattern:\n\n```\nCA-AgentID-<AccessPattern>-<Control>-<Scope>-<Mode>\n```\n\nExamples:\n\n```\nCA-AgentID-Autonomous-Block-NonApproved-ReportOnly\nCA-AgentID-Autonomous-Block-HighRisk-ReportOnly\nCA-AgentID-Autonomous-Allow-Approved-Prod\nCA-AgentUser-Require-CompliantDevice-Pilot\n```\n\nGood naming helps during operations, troubleshooting and policy review. It also prevents agent policies from being confused with human-user policies.\n\nKeep these points visible in the design:\n\nConditional Access should come after inventory, accountability and custom security attributes.\n\nThe sequence should look like this:\n\nConditional Access is not the first step. It is the enforcement layer that becomes effective once the governance metadata is trusted.\n\nConditional Access turns agent classification into access control. For on-behalf-of flows, review the existing user Conditional Access baseline. For autonomous agents, use agent identity policies driven by approval status, risk and custom security attributes. For agent users, evaluate endpoint, network and device-based controls only where they apply.\n\nStart in report-only mode, validate impact, and then enforce in controlled rings. This keeps agent governance scalable, defensible and safer to operate.", "url": "https://wpnews.pro/news/design-conditional-access-policies-for-agent-identities", "canonical_source": "https://dev.to/stepbysteptocloud/design-conditional-access-policies-for-agent-identities-29cb", "published_at": "2026-07-09 15:11:35+00:00", "updated_at": "2026-07-09 15:36:06.267976+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "ai-infrastructure", "developer-tools"], "entities": ["Microsoft Entra ID", "Agent 365", "Conditional Access"], "alternates": {"html": "https://wpnews.pro/news/design-conditional-access-policies-for-agent-identities", "markdown": "https://wpnews.pro/news/design-conditional-access-policies-for-agent-identities.md", "text": "https://wpnews.pro/news/design-conditional-access-policies-for-agent-identities.txt", "jsonld": "https://wpnews.pro/news/design-conditional-access-policies-for-agent-identities.jsonld"}}