AI Security, azure, Microsoft Certification, SC-500, security

Implement conditional access for Microsoft Entra Agent ID (SC-500 Exam Prep)

 
This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for AI
      --> Implement conditional access for Microsoft Entra Agent ID

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

AI agents increasingly perform tasks that were previously completed by users or applications. They may access files, call APIs, read databases, send messages, or execute business processes. Because agents can operate autonomously and at high speed, granting them unrestricted access creates significant security risks.

Microsoft Entra Agent ID provides identity and access-management capabilities designed specifically for AI agents. Microsoft Entra Conditional Access can then evaluate the agent’s identity, context, and risk before allowing it to access protected resources.

The objective is to apply Zero Trust principles to agents:

Never trust an agent automatically. Verify the agent’s identity, evaluate its risk and context, and grant only the access it requires.

Microsoft Entra Agent ID introduces dedicated agent identities that can be governed and protected similarly to other identities, while also providing agent-specific controls and policy scenarios.

Why Conditional Access Is Important for AI Agents

Traditional applications generally operate according to predefined workflows. AI agents, however, can dynamically interpret instructions, select tools, and decide which actions to perform.

For example, an agent might:

  1. Receive a user request.
  2. Retrieve information from a business application.
  3. Call a database or API.
  4. Generate a response.
  5. Perform an additional action based on the information it discovered.

If the agent is compromised, misconfigured, or manipulated through prompt injection, it may attempt to access resources outside its intended scope.

Conditional Access helps reduce this risk by allowing an organization to define policies such as:

  • Block high-risk agent identities.
  • Allow only selected agents to access production resources.
  • Restrict agents based on security attributes.
  • Apply different policies to development and production agents.
  • Require access to occur through approved network conditions.
  • Apply different controls to autonomous agents and agents acting on behalf of users.

Conditional Access does not replace authorization. It determines whether access is permitted under specific conditions. The agent must still have the necessary permissions to access the target resource.

Microsoft Entra Agent ID Concepts

Agent identity

An agent identity is a dedicated identity representing an AI agent in Microsoft Entra ID. It provides a distinct security principal that can be authenticated, authorized, governed, and monitored.

Using a separate identity is preferable to allowing many agents to share a broad application identity because it improves:

  • Accountability.
  • Permission management.
  • Risk evaluation.
  • Access reviews.
  • Incident investigation.
  • Lifecycle management.

Agent identity blueprint

An agent identity blueprint represents the definition or source from which agent identities are created.

Conditional Access policies can be applied at the blueprint level so that agent identities created from that blueprint inherit the applicable policies. This is useful when an organization wants consistent controls across a group of related agents.

Agent user

An agent user is an identity associated with an agent for scenarios in which the agent operates on behalf of a user. This is different from an autonomous agent that acts without a user context.

The distinction matters because an organization may need different policies for:

  • Autonomous agents that act independently.
  • Agents acting on behalf of users.
  • Agents with delegated access.
  • Agents using application-only permissions.

Microsoft Entra documentation provides separate policy scenarios for autonomous agents and agents acting on behalf of users.

How Conditional Access Works for Agents

A Conditional Access policy is essentially an if-then statement:

If a specified identity attempts to access a specified resource under specified conditions, then grant access, require an applicable control, or block access.

For agent identities, the policy can evaluate information such as:

  • Which agent is requesting access.
  • Whether the agent belongs to a particular blueprint.
  • The resource being accessed.
  • The agent’s risk level.
  • Agent attributes.
  • Network or location-related signals.
  • Whether the agent is autonomous or acting on behalf of a user.

All applicable Conditional Access policies must be satisfied before access is granted. If one applicable policy blocks access, the request is blocked.

Conditional Access Policy Assignments for Agents

A Conditional Access policy generally contains three major areas:

  1. Assignments
  2. Conditions
  3. Access controls

1. Assignments

Assignments determine which identities and resources are included in the policy.

For agent policies, supported targeting options include:

  • All agent identities.
  • Selected agents acting as users.
  • Agents selected by attributes.
  • Individual agent identities.

This allows an organization to create broad policies or highly targeted policies.

2. Target resources

The policy can target the cloud applications or resources that agents are attempting to access.

For example, an organization could create a policy that applies to agents accessing:

  • Production databases.
  • Sensitive document repositories.
  • Microsoft Graph resources.
  • Business applications.
  • Administrative services.
  • High-value APIs.

The agent may be allowed to access low-risk resources while being blocked from sensitive resources unless additional conditions are satisfied.

3. Conditions

Conditions determine when the policy applies. Depending on the supported agent scenario, conditions can include:

  • Agent risk.
  • Agent attributes.
  • Network location.
  • Other applicable identity or resource context.

Agent-specific Conditional Access guidance emphasizes using risk, identity filters, and named locations rather than relying on interactive user controls.

Agent Risk and Microsoft Entra ID Protection

One of the most important capabilities is the ability to use Microsoft Entra ID Protection risk signals in Conditional Access policies.

An agent may be considered high risk because of suspicious behavior, such as:

  • Accessing unfamiliar resources.
  • Making an unusually high number of sign-in attempts.
  • Exhibiting behavior associated with a compromised identity.
  • Displaying other risk indicators detected by Microsoft Entra ID Protection.

An organization can create a Conditional Access policy that blocks agent identities identified as high risk.

Example

A company has an autonomous purchasing agent that normally accesses inventory and approved purchasing APIs. Microsoft Entra ID Protection detects that the agent is attempting to access unfamiliar resources at an unusually high rate.

A Conditional Access policy can be configured to:

  • Include all agent identities.
  • Target the relevant resources.
  • Use high agent risk as a condition.
  • Block access.

This helps prevent a potentially compromised agent from continuing to access organizational resources.

Agent Attributes and Fine-Grained Policies

Organizations can use attributes to classify agents and apply more precise controls.

Examples of useful attributes include:

  • Environment: Development, Test, or Production.
  • Department: Finance, Human Resources, or Operations.
  • Data sensitivity: Public, Internal, Confidential, or Restricted.
  • Business owner.
  • Agent type.
  • Regulatory classification.

For example, an organization might apply a policy that blocks agents classified as Development from accessing production resources.

This approach is more scalable than manually creating a separate policy for every agent. It also makes it easier to enforce consistent security standards across large agent inventories.

Important Agent-Specific Consideration: Interactive Controls

Many traditional Conditional Access policies are designed for human users. They may require controls such as:

  • Multifactor authentication.
  • A compliant device.
  • A user-approved client application.
  • A password change.
  • Acceptance of terms of use.

Agents generally cannot complete interactive controls in the same way that human users can.

For this reason, organizations should not simply apply a broad user policy to agents and assume it will work correctly. Instead, create dedicated agent policies that use controls appropriate for noninteractive or agent-based access, such as:

  • Agent identity targeting.
  • Risk-based blocking.
  • Attribute-based filtering.
  • Resource restrictions.
  • Network controls.
  • Least-privilege authorization.

Microsoft recommends creating agent-specific policies rather than relying exclusively on policies designed for users.

Autonomous Agents Versus Agents Acting on Behalf of Users

Autonomous agents

An autonomous agent operates without a user context. It may run on a schedule, respond to events, or independently perform tasks.

Examples include:

  • An agent that monitors inventory.
  • An agent that processes incoming support requests.
  • An agent that checks compliance conditions.
  • An agent that performs scheduled data analysis.

Policies for autonomous agents should focus on the agent’s own identity, permissions, risk, and resource access.

Agents acting on behalf of users

An agent acting on behalf of a user performs actions in the context of a human user or uses delegated permissions.

Examples include:

  • An assistant retrieving a user’s calendar.
  • An agent preparing a report using the user’s permitted files.
  • An agent submitting a request on behalf of an employee.

These scenarios require careful consideration of both:

  • The agent’s identity.
  • The user context and delegated permissions.

Microsoft Entra provides separate Conditional Access policy scenarios for autonomous agents and agents acting on behalf of users.

Example Conditional Access Policies

Policy 1: Block high-risk agents

Purpose: Prevent risky agents from accessing organizational resources.

Example configuration:

  • Include: All agent identities.
  • Target resources: Selected organizational resources.
  • Condition: High agent risk.
  • Access control: Block access.

This is one of the most important baseline policies for agent security.

Policy 2: Restrict development agents

Purpose: Prevent development agents from accessing production resources.

Example configuration:

  • Include: Agents with an Environment attribute of Development.
  • Target resources: Production applications or databases.
  • Access control: Block access.

Policy 3: Protect sensitive resources

Purpose: Apply stricter controls to agents accessing confidential data.

Example configuration:

  • Include: Selected agent identities or agents with a specific data-sensitivity attribute.
  • Target resources: Sensitive applications or data repositories.
  • Conditions: Applicable agent context and risk.
  • Access control: Allow only when the required conditions are satisfied.

Policy 4: Separate autonomous-agent access

Purpose: Apply policies specifically to agents that operate without user context.

Example configuration:

  • Include: Autonomous agent identities.
  • Target resources: Approved APIs and applications.
  • Access control: Permit only the intended access pattern.

How to Configure Conditional Access for Agent Identities

The exact portal experience may change as Microsoft Entra Agent ID and Microsoft Agent 365 evolve. The following process describes the core configuration approach.

Step 1: Identify the agents that require protection

Before creating policies, determine:

  • Which agents exist.
  • Which agents use Microsoft Entra Agent ID.
  • Whether each agent is autonomous or acts on behalf of a user.
  • Which resources each agent needs.
  • Who owns and sponsors each agent.
  • Which agents access sensitive or production resources.

Do not begin by applying a broad blocking policy without understanding the agent inventory and access requirements.

Step 2: Assign appropriate permissions

Conditional Access does not grant permissions by itself.

First, assign the agent only the permissions required for its tasks. Use:

  • Least-privilege permissions.
  • Narrow API scopes.
  • Specific resource assignments.
  • Access packages where appropriate.
  • Separate identities for separate agents or workloads.

Access packages can assign agent identities access to resources such as security groups, application permissions, and Microsoft Entra roles.

Step 3: Open the Conditional Access policy experience

In the Microsoft Entra admin center:

  1. Open Microsoft Entra ID.
  2. Navigate to Protection.
  3. Open Conditional Access.
  4. Create a new policy.

The exact navigation labels may vary as the portal changes.

Step 4: Select the agent identities

In the policy’s identity assignment area, select the applicable agent scope.

Possible scopes include:

  • All agent identities.
  • Specific agent identities.
  • Agents selected by attributes.
  • Agents acting as users.

Avoid accidentally including human users or unrelated workload identities when the policy is intended only for agents.

Step 5: Select target resources

Choose the applications, services, or resources that the agent policy should protect.

A policy targeting sensitive production resources is often safer and easier to test than a policy initially targeting every resource in the tenant.

Step 6: Configure conditions

Configure conditions appropriate to the scenario, such as:

  • High agent risk.
  • Agent identity attributes.
  • Network conditions.
  • Other supported context signals.

For example, a high-risk policy should use the agent risk condition rather than a human-user sign-in-risk condition.

Step 7: Configure the access control

Select the appropriate enforcement action:

  • Block access for high-risk or unauthorized scenarios.
  • An applicable grant control when the agent scenario supports it.
  • Appropriate session or network controls where available.

Do not require interactive MFA as a default solution for autonomous agents. Agents cannot generally respond to an interactive MFA challenge as a human user would.

Step 8: Start in report-only mode

Use report-only mode to evaluate the policy before enforcing it.

This helps identify:

  • Agents that would be blocked.
  • Unexpected policy matches.
  • Conflicts with existing policies.
  • Agents that require different permissions or attributes.
  • Potential business impact.

Microsoft recommends testing agent policies in report-only mode before enabling enforcement.

Step 9: Review the results

Review the Conditional Access results and determine whether:

  • The intended agents are being targeted.
  • Unintended identities are included.
  • The policy blocks legitimate operations.
  • The policy fails to protect the intended resources.
  • Existing broad policies interfere with agent access.

Step 10: Enable the policy

After testing, enable the policy and monitor its effect.

Use a staged rollout where possible:

  1. Test with a small group of agents.
  2. Review logs and operational behavior.
  3. Expand the scope.
  4. Continue monitoring for false positives and unexpected access attempts.

Conditional Access and Existing User Policies

A common mistake is assuming that a policy such as “All users must use MFA” automatically provides appropriate protection for agents.

Agent identities are not human users, and interactive user controls may not apply to them in the same way.

Organizations should:

  • Review broad policies for their impact on agents.
  • Create dedicated policies for agent identities.
  • Avoid unintentionally blocking legitimate agent flows.
  • Avoid excluding agents from security controls merely because a user-focused policy does not work.
  • Replace unsuitable controls with agent-appropriate conditions and restrictions.

The goal is not to weaken security for agents. The goal is to apply controls that are appropriate for how agents authenticate and operate.

Relationship to Other Security Controls

Conditional Access is only one layer of defense.

Microsoft Entra authorization

Authorization determines what the agent is allowed to access. Conditional Access determines whether the access is permitted under current conditions.

Both are required.

Microsoft Entra ID Protection

ID Protection supplies risk signals that can be used by Conditional Access policies, including policies that block high-risk agents.

Access packages and identity governance

Access packages help control which resources an agent can receive access to and can include approval and expiration requirements.

Microsoft Agent 365

Microsoft Agent 365 provides broader agent discovery, management, and governance capabilities. Microsoft Entra Agent ID provides the identity foundation used to manage and protect agent identities.

Microsoft Purview

Purview can help identify and govern data risks, including classification, sensitivity labels, and data protection controls. These capabilities complement Conditional Access but do not replace it.

Runtime protection

Runtime protection can inspect agent behavior or tool invocations while the agent is operating. Conditional Access is primarily an identity and access decision made before access to a resource is granted.

Best Practices

Use a unique identity for each agent

Avoid sharing one broad identity across many unrelated agents. Separate identities improve accountability and make it easier to revoke or restrict access.

Apply least privilege

Grant only the permissions required for the agent’s specific tasks. Do not use broad permissions simply because they are easier to configure.

Block high-risk agents

Create a baseline policy that blocks agent identities identified as high risk by Microsoft Entra ID Protection.

Use attributes for scale

Use attributes such as environment, department, and data sensitivity to apply consistent policies across many agents.

Separate development and production

Development agents should not automatically have access to production resources.

Test policies in report-only mode

Validate policy behavior before enforcement to reduce accidental outages.

Review existing policies

Broad policies designed for users may unintentionally block agents or fail to protect them appropriately.

Combine Conditional Access with authorization

Conditional Access cannot compensate for excessive permissions. The agent must still be granted only the access it needs.

Maintain ownership and sponsorship

Every agent should have an accountable owner or sponsor who can review its permissions, lifecycle, and continued business need.

Monitor and review continuously

Agent behavior, permissions, and risk can change over time. Periodically review:

  • Agent identities.
  • Access assignments.
  • Conditional Access results.
  • Risk detections.
  • Resource permissions.
  • Ownership and sponsorship.
  • Policy exceptions.

Common Exam Traps

Conditional Access is not the same as authorization

Conditional Access does not determine the complete set of permissions an agent has. It evaluates whether access should be allowed under specified conditions.

Agent identities are not ordinary human users

Do not assume an agent can satisfy interactive controls such as MFA prompts.

High-risk agents should generally be blocked

A common security scenario is creating a policy that blocks agent identities identified as high risk.

User policies should not be copied blindly

Policies designed for human users may not be appropriate for autonomous agents.

Report-only mode does not enforce the policy

Report-only mode evaluates and reports policy results without applying the policy’s enforcement action.

Conditional Access does not replace least privilege

An agent with excessive permissions remains dangerous even if Conditional Access is enabled.

Autonomous and delegated agents are different

An autonomous agent and an agent acting on behalf of a user may require different policy designs.

Practice Exam Questions

Question 1

What is the primary purpose of applying Conditional Access to Microsoft Entra agent identities?

A. To automatically create agent identities
B. To evaluate agent context and risk before allowing access to resources
C. To replace all agent authorization permissions
D. To train the agent to recognize malicious prompts

Correct answer: B

Explanation: Conditional Access evaluates identity, context, and risk to determine whether an agent should be allowed to access a resource. It does not create identities, replace authorization, or train the agent.

Question 2

An organization wants to prevent agents identified as high risk from accessing company resources. Which solution is most appropriate?

A. Require all agents to complete interactive MFA
B. Assign every agent the Global Administrator role
C. Disable all agent identities permanently
D. Create a Conditional Access policy that blocks high-risk agent identities

Correct answer: D

Explanation: Microsoft Entra ID Protection risk signals can be used with Conditional Access to block high-risk agent identities.

Question 3

Which targeting option is appropriate when an organization wants a Conditional Access policy to apply to every Microsoft Entra agent identity?

A. All Microsoft 365 users
B. All guest users
C. All managed identities
D. All agent identities

Correct answer: D

Explanation: Conditional Access supports targeting all agent identities. The other options target different identity categories.

Question 4

Why should organizations avoid applying human-user Conditional Access policies to autonomous agents without review?

A. Agents cannot be assigned permissions
B. Agents are not recorded in Microsoft Entra ID
C. Agents may not be able to satisfy interactive controls such as MFA
D. Conditional Access cannot block agents

Correct answer: C

Explanation: Autonomous agents generally cannot respond to interactive controls in the same way as human users. Dedicated agent policies should use appropriate identity, risk, attribute, and resource controls.

Question 5

An organization wants to prevent development agents from accessing production applications. Which approach is most scalable?

A. Require every developer to manually approve each request
B. Delete all development agents
C. Give development agents unrestricted access and monitor them
D. Use an agent attribute such as Environment and create a policy targeting development agents

Correct answer: D

Explanation: Attribute-based targeting allows organizations to apply consistent policies to groups of agents, such as blocking development agents from production resources.

Question 6

What is the recommended first enforcement stage when testing a new Conditional Access policy for agents?

A. Report-only mode
B. Permanent blocking mode
C. Global Administrator approval for every request
D. Disabling all existing policies

Correct answer: A

Explanation: Report-only mode allows administrators to evaluate the policy’s impact before enforcing it.

Question 7

Which statement best describes the relationship between Conditional Access and authorization?

A. Conditional Access grants all permissions required by the agent
B. Authorization is unnecessary when Conditional Access is enabled
C. Conditional Access evaluates whether access is allowed, while authorization determines what the agent can access
D. Conditional Access only applies after the agent has completed its task

Correct answer: C

Explanation: Conditional Access and authorization serve different purposes. Both are necessary for secure agent access.

Question 8

An autonomous agent normally accesses inventory APIs but suddenly attempts to access unfamiliar resources. Which Microsoft Entra capability can provide a risk signal for a Conditional Access policy?

A. Microsoft Entra ID Protection
B. Azure Resource Locks
C. Azure Backup
D. Microsoft Purview retention labels

Correct answer: A

Explanation: Microsoft Entra ID Protection can detect risky identity behavior and provide risk signals that Conditional Access can use to block or restrict access.

Question 9

Which statement about autonomous agents and agents acting on behalf of users is correct?

A. They always require identical Conditional Access policies
B. Autonomous agents always use delegated user permissions
C. Agents acting on behalf of users cannot access applications
D. They may require different policies because their identity and user-context models differ

Correct answer: D

Explanation: Autonomous agents operate without a user context, while delegated agents act on behalf of users. Their access and policy requirements can therefore differ.

Question 10

Which action is most consistent with a least-privilege strategy for Microsoft Entra agent identities?

A. Give every agent broad Microsoft Graph application permissions
B. Assign only the API scopes, applications, and resources required by each agent
C. Use one shared administrator identity for all agents
D. Exclude agents from all Conditional Access policies

Correct answer: B

Explanation: Least privilege means granting each agent only the permissions necessary for its intended tasks. Broad shared identities and excessive permissions increase risk.

Go to the SC-500 Exam Prep Hub main page

Leave a Reply