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
--> Manage Entra Agent ID access
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
Artificial intelligence agents increasingly perform tasks that traditionally required human users or application identities. An agent may read documents, query databases, call APIs, send messages, update business systems, or perform actions autonomously.
Because an agent can access organizational resources and act on behalf of users or applications, it must be managed as an identity—not merely as a software component. Microsoft Entra Agent ID extends Microsoft Entra identity, access, governance, and security capabilities to AI agents.
For the SC-500 exam, managing Entra Agent ID access involves understanding how to:
- Create and manage agent identities.
- Understand agent identity blueprints.
- Assign permissions to agents.
- Apply Conditional Access policies.
- Use access packages to govern agent access.
- Monitor agent sign-ins and activity.
- Manage owners and sponsors.
- Detect, restrict, or disable risky agents.
- Apply least-privilege and lifecycle controls.
Microsoft Entra Agent ID provides specialized identity constructs for AI agents and supports authentication, authorization, governance, and security controls throughout the agent lifecycle.
Why AI Agents Require Identity and Access Management
A traditional application may perform a limited set of predefined operations. An AI agent, however, may interpret instructions, select tools, retrieve information, and take actions dynamically.
For example, a customer-service agent might be able to:
- Read customer records.
- Search internal knowledge bases.
- Access Microsoft Graph.
- Update a CRM system.
- Create support tickets.
- Send email.
- Access files stored in SharePoint or Azure Storage.
If that agent is compromised, manipulated, or incorrectly configured, its permissions could be abused. The security impact depends not only on whether the agent is compromised, but also on what the agent can access and what actions it can perform.
Therefore, security teams must answer questions such as:
- What identity does the agent use?
- Who owns and sponsors the agent?
- Which resources can the agent access?
- Which permissions were granted to it?
- Are those permissions inherited from a blueprint?
- Can the agent access resources on behalf of a user?
- Can it act autonomously?
- Can Conditional Access restrict its access?
- How can the agent be disabled if it becomes risky?
The objective is to provide agents with only the access they require, for only as long as they require it.
Core Entra Agent ID Concepts
Agent identity
An agent identity is a specialized identity in Microsoft Entra ID that represents an individual AI agent.
Microsoft documentation describes an agent identity as a special service principal created from an agent identity blueprint. The agent identity represents the agent that is authorized to use the blueprint. It does not independently maintain its own credentials; the blueprint can acquire tokens on behalf of the agent identity after the appropriate consent and permissions have been granted.
An agent identity allows an organization to:
- Give an agent a distinct identity.
- Assign permissions to the agent.
- Apply access policies.
- Track sign-in activity.
- Associate the agent with owners and sponsors.
- Disable the agent when necessary.
- Govern the agent independently from human users.
Example
A company deploys three instances of a sales assistant:
- North America Sales Assistant.
- Europe Sales Assistant.
- Enterprise Sales Assistant.
Each instance can have its own agent identity while being created from the same blueprint. This allows the organization to manage the agents individually while also applying consistent controls to all agents created from that blueprint.
Agent identity blueprint
An agent identity blueprint is the parent definition from which agent identities are created.
A blueprint can establish common characteristics and permissions for agents of a particular type or purpose. It provides a way to apply consistent security controls across multiple agent identities.
For example, a company might create a blueprint named Customer Support Assistant. Multiple agents can be created from that blueprint for different departments or regions.
Blueprints help administrators:
- Identify related agents.
- View linked agent identities.
- Manage common permissions.
- Configure inheritable permissions.
- Manage blueprint owners and sponsors.
- Review audit and sign-in activity.
- Disable the blueprint.
- Prevent new agents from being created from a blueprint.
When a blueprint is disabled, existing agent identities created from that blueprint can also be prevented from authenticating.
Blueprint versus agent identity
| Concept | Description |
|---|---|
| Agent identity blueprint | Parent definition used to create and authorize agent identities |
| Agent identity | Individual identity representing a deployed AI agent |
| Blueprint permissions | Permissions that can be inherited by agents created from the blueprint |
| Agent-specific access | Access assigned directly to an individual agent, such as through an access package |
| Blueprint owner | Person responsible for technical administration |
| Agent sponsor | Person accountable for the agent’s business purpose and lifecycle |
A blueprint is useful when many agents require a consistent baseline. However, organizations should still evaluate whether each individual agent needs additional permissions.
Agent user account
Some agent scenarios require an identity that can interact with services expecting a user identity. Microsoft Entra Agent ID supports an agent user account for these scenarios.
An agent user account can bridge the gap between an AI agent and services that require user-like capabilities. It is different from the agent identity itself and should be governed with appropriate security boundaries.
The key exam distinction is that an organization may encounter several related identity concepts:
- Agent identity.
- Agent identity blueprint.
- Agent user account.
- Agent service principal.
- Human user identity.
Do not assume that every agent uses the same identity model. The appropriate identity depends on how the agent authenticates, whether it acts autonomously, and whether it acts on behalf of a user.
Viewing and Managing Agent Identities
Administrators can view agent identities in the Microsoft Entra admin center.
The general navigation is:
Microsoft Entra admin center → Entra ID → Agents → Agent identities
The agent identity list can be searched, filtered, sorted, and customized. Administrators can search by:
- Agent name.
- Object ID.
- Blueprint App ID.
The details for an agent identity can include:
- Name and description.
- Status.
- Parent blueprint.
- Owners and sponsors.
- Granted permissions.
- Microsoft Entra roles.
- Audit logs.
- Sign-in logs.
- Whether the agent uses an agent identity object or a service principal.
Viewing agent identities does not necessarily require an administrative role. Managing them generally requires the Agent ID Administrator or Cloud Application Administrator role. An agent identity owner may also manage their own agent without holding one of those administrative roles.
Important administrative roles
| Task | Typical role or responsibility |
|---|---|
| View agent identities | Microsoft Entra user account |
| Manage agent identities | Agent ID Administrator or Cloud Application Administrator |
| Create agent blueprints | Agent ID Developer |
| Configure Conditional Access | Conditional Access Administrator |
| View Identity Protection risk reports | Security Administrator, Security Operator, or Security Reader |
| Manage lifecycle workflows | Lifecycle Workflows Administrator |
| Manage an owned or sponsored agent | Agent owner or sponsor |
The exact capabilities available depend on the operation, licensing, and whether the feature is in preview.
Understanding Agent Access
Agent access should be evaluated from several perspectives.
1. Authentication
Authentication establishes the identity of the agent or the user on whose behalf the agent is acting.
Questions to consider include:
- How does the agent obtain tokens?
- Is the agent autonomous?
- Does it act on behalf of a signed-in user?
- Which authentication protocol is used?
- Is the identity associated with the correct blueprint?
- Are sign-in events being logged?
Authentication alone does not determine what the agent is allowed to do. Authorization and policy controls are also required.
2. Authorization
Authorization determines which resources and operations the agent can access.
Examples include:
- Microsoft Graph permissions.
- Application API permissions.
- Delegated permissions.
- Microsoft Entra roles.
- Security group membership.
- Access to business applications.
- Access to storage, databases, or repositories.
An agent should not receive broad permissions simply because it might need them in the future. Permissions should be limited to the agent’s documented business purpose.
3. Resource access
An agent may have access through:
- Permissions inherited from its blueprint.
- Direct permissions assigned to the agent.
- Access packages.
- Group memberships.
- Application roles.
- Microsoft Entra roles.
- User-delegated access.
- Access to connected tools or APIs.
A complete access review must consider all of these paths. Reviewing only the agent’s direct permissions may miss access inherited from a group, blueprint, or delegated user context.
Inheritable Permissions
Agent identity blueprints can be configured with inheritable permissions.
Inheritable permissions provide a consistent permission baseline for agents created from a particular blueprint. This is useful when all agents of a specific type need access to the same application or API.
For example, all agents created from a finance-assistant blueprint might need read access to a financial reporting API.
However, inheritable permissions must be designed carefully. If excessive permissions are assigned to a blueprint, every agent created from it may inherit unnecessary access.
Recommended approach
- Define the agent’s business purpose.
- Identify the minimum required resources.
- Assign the narrowest available permissions.
- Avoid inheriting high-privilege permissions unless required.
- Review the permissions assigned to the blueprint.
- Review the permissions of each linked agent.
- Remove permissions that are no longer needed.
Microsoft documentation identifies limits for blueprint access configuration, including a maximum number of resource applications and enumerated scopes per resource application. Some high-privilege scopes may be blocked by platform policy and cannot be inherited.
Access Packages for Agent Identities
Microsoft Entra entitlement management can be used to govern agent access through access packages.
Access packages provide a policy-based way to assign access to resources. For agent identities, an access package can include:
- Security group memberships.
- Application OAuth API permissions.
- Microsoft Graph application permissions.
- Microsoft Entra roles.
Access packages can help organizations control:
- Who can request access for an agent.
- Which resources can be assigned.
- Whether approval is required.
- How long access remains active.
- Whether access must be reviewed.
- When access should expire.
An access package assignment policy can be configured for users, service principals, and agent identities in the directory. The policy can target all agents or a more specific set of identities.
Why access packages are useful
Access packages are especially valuable when an agent requires temporary or controlled access to sensitive resources.
For example, an analytics agent may need access to a restricted data source for a limited project. Instead of granting permanent broad access, the organization can:
- Create an access package.
- Define the required resource permissions.
- Require approval from the agent owner or sponsor.
- Set an expiration date.
- Review the assignment periodically.
- Remove access when the project ends.
This supports the principle of just enough access for just enough time.
Owners and Sponsors
Agent owners and sponsors provide accountability.
Owners
Owners are generally responsible for technical administration. They may manage:
- Agent configuration.
- Operational status.
- Technical access.
- Agent-related administration.
- Enabling or disabling the agent.
Sponsors
Sponsors are accountable for the agent’s business purpose and lifecycle. They should help determine:
- Why the agent exists.
- Who is responsible for its use.
- Whether the agent is still needed.
- Whether its permissions remain appropriate.
- Whether it should be retired.
- Who should replace the sponsor if the sponsor leaves.
An agent without an accountable owner or sponsor can become an unmanaged identity with persistent access.
Organizations should establish requirements for:
- At least one responsible owner.
- A business sponsor.
- Periodic access reviews.
- Sponsor reassignment.
- Retirement of unused agents.
- Documentation of the agent’s purpose and data access.
Owners and sponsors can manage agents they own or sponsor through the Microsoft Entra end-user experience. They may be able to enable or disable agents and request access packages on behalf of those agents.
Conditional Access for Agent Identities
Conditional Access controls the conditions under which an agent identity can access resources.
Conditional Access policies can be used to:
- Block all agent identities.
- Allow only selected agents.
- Target specific agent identities.
- Target agent identities associated with a blueprint.
- Block agents based on risk.
- Apply policies to all resources.
- Use report-only mode before enforcement.
For example, an organization could create a policy that blocks agent identities with a high agent risk level.
Conditional Access enforcement applies when an agent identity or an agent user account requests a token for a resource. It does not apply when an agent identity blueprint acquires a token to create agent identities or agent user accounts.
Report-only mode
Report-only mode allows administrators to evaluate the potential effect of a policy before enforcing it.
This is useful because a broad policy blocking all agents could disrupt:
- Business workflows.
- Copilot experiences.
- Automated processes.
- Applications that depend on agent access.
- Agents that have not yet been migrated to the correct identity model.
A recommended deployment process is:
- Create the Conditional Access policy.
- Configure it in report-only mode.
- Review sign-in and policy impact.
- Identify agents that would be blocked.
- Correct unintended dependencies.
- Enable enforcement.
- Monitor the results.
Identity Protection for Agents
Microsoft Entra ID Protection can detect anomalous behavior involving agent identities.
Examples of risk signals include:
- Unfamiliar resource access.
- Unusual sign-in spikes.
- Failed access attempts.
- Other abnormal authentication or access patterns.
Administrators can review the Risky Agents report and take actions such as:
- Confirm compromise.
- Confirm safe.
- Dismiss the risk.
- Disable the agent.
When an agent is confirmed as compromised, its risk level is set to High. If a Conditional Access policy is configured to block agents with high agent risk, the agent can be blocked from accessing resources.
Important distinction
Identity Protection detects risk. Conditional Access enforces access decisions.
| Capability | Primary purpose |
|---|---|
| Identity Protection for agents | Detect anomalous or risky agent behavior |
| Conditional Access | Enforce access conditions based on identity, context, and risk |
| Agent administration | Enable, disable, and manage agent identities |
| Access packages | Govern assignment and duration of resource access |
| Defender XDR | Discover, investigate, and assess security risks and attack paths |
Do not confuse an agent being marked as risky with the agent automatically being disabled. Automatic blocking depends on the policies configured by the organization.
Disabling Agent Identities
An organization can disable access at several levels.
Individual agent
Disabling an individual agent:
- Prevents it from accessing resources.
- Prevents it from being issued tokens.
- Stops the specific agent without necessarily affecting other agents.
Blueprint level
Disabling a blueprint can:
- Prevent new agent identities from being created from that blueprint.
- Block existing agents associated with the blueprint from authenticating.
Tenant-wide
Conditional Access can be used to block all agent identity authentication. Organizations may also use product-specific controls to prevent the creation of new agent identities.
Tenant-wide blocking should be used carefully because it can:
- Break existing agent workflows.
- Degrade Microsoft product experiences.
- Cause applications to fail.
- Encourage teams to use less visible service-principal or application identities.
A more targeted approach is generally preferable when only a subset of agents is risky.
Monitoring Agent Activity
Agent activity should be monitored throughout the identity lifecycle.
Useful sources of information include:
- Sign-in logs.
- Audit logs.
- Permission assignments.
- Blueprint configuration.
- Owners and sponsors.
- Access package assignments.
- Conditional Access results.
- Identity Protection risk reports.
- Security alerts.
- Agent runtime activity.
Monitoring can help answer:
- Is the agent authenticating as expected?
- Is it accessing resources outside its normal purpose?
- Are permissions being changed?
- Has the agent been disabled or re-enabled?
- Is the agent experiencing unusual sign-in behavior?
- Is the agent using a deprecated or unnecessary permission?
- Is the agent still owned and sponsored?
All agent authentication and activity should be logged and reviewed according to the organization’s security, privacy, and compliance requirements.
Managing Access for Autonomous and On-Behalf-of Agents
Not all agents operate in the same way.
Autonomous agents
An autonomous agent acts independently using its own agent identity and permissions.
Examples include:
- A monitoring agent that investigates alerts.
- A scheduled reporting agent.
- An automation agent that updates records.
- A data-processing agent that runs without a user being present.
For autonomous agents, the organization must carefully control the permissions assigned directly to the agent identity.
On-behalf-of-user agents
An on-behalf-of-user agent acts using the context or permissions of a signed-in user.
Examples include:
- An assistant that searches a user’s files.
- An agent that creates calendar events for a user.
- An agent that retrieves information the user is already authorized to access.
On-behalf-of scenarios require careful consideration of delegated permissions and user context. The agent should not become a way to bypass the user’s permissions.
Exam consideration
When evaluating an agent’s access, determine whether it:
- Uses its own application permissions.
- Uses delegated permissions.
- Acts autonomously.
- Acts on behalf of a user.
- Uses an agent user account.
- Inherits permissions from a blueprint.
The identity model affects how access should be assigned and controlled.
Recommended Least-Privilege Strategy
A secure Entra Agent ID implementation should follow these practices.
Use separate identities for separate purposes
Do not use one highly privileged agent identity for unrelated workloads.
For example, separate:
- Customer support.
- Financial reporting.
- Human resources.
- Production operations.
- Security investigation.
This limits the impact if one agent is compromised.
Minimize permissions
Grant only the permissions required for the agent’s documented tasks.
Prefer:
- Read-only access where possible.
- Narrow API scopes.
- Specific application roles.
- Restricted resource groups.
- Limited group memberships.
- Time-bound access packages.
Avoid:
- Broad directory roles.
- Unnecessary Microsoft Graph permissions.
- Permanent access to production systems.
- Shared identities across unrelated agents.
- Excessive delegated permissions.
Separate read and write capabilities
If an agent only needs to retrieve information, do not grant it write, delete, or administrative permissions.
For example:
- A reporting agent should read data but not modify it.
- A knowledge agent should retrieve documents but not change permissions.
- A support agent may create tickets but should not delete customer accounts.
Require approval for sensitive operations
High-impact operations should require additional controls, such as:
- Human approval.
- Restricted API endpoints.
- Separate privileged workflows.
- Explicit access packages.
- Just-in-time access.
- Transaction limits.
Review inherited permissions
Review both:
- Permissions inherited from the blueprint.
- Permissions assigned directly to the agent.
A blueprint change can affect many linked agents, so blueprint permissions should be treated as a high-impact administrative control.
Maintain ownership and sponsorship
Every production agent should have:
- A technical owner.
- A business sponsor.
- A documented purpose.
- A defined data classification.
- A review schedule.
- A retirement process.
Use report-only policies before enforcement
Conditional Access and other broad controls should be tested in report-only mode where supported.
Disable unused agents
An agent that is no longer needed should be disabled or retired. Unused identities can retain access and become attractive targets.
Example Scenario
A company deploys a customer-service agent that can:
- Read customer records.
- Search SharePoint knowledge bases.
- Read Microsoft Graph mail.
- Update the CRM.
- Access an Azure DevOps repository.
- Call a production API.
The agent was initially configured with broad permissions to simplify development.
A security review identifies several concerns:
- The agent has access to data unrelated to customer support.
- It can modify production records.
- It can read confidential email.
- It has access to source code.
- Its blueprint grants permissions inherited by multiple agents.
- No formal sponsor has been assigned.
A secure remediation plan would include:
- Create a clearly defined business purpose.
- Assign a technical owner and business sponsor.
- Remove access to email and source code unless explicitly required.
- Replace broad CRM permissions with narrowly scoped roles.
- Separate read-only operations from write operations.
- Restrict production API access.
- Use an access package for temporary elevated access.
- Apply Conditional Access policies.
- Monitor sign-ins and risk signals.
- Disable the agent if compromise is suspected.
- Review all agents created from the same blueprint.
- Reassess permissions after remediation.
The goal is not merely to secure the agent’s authentication. It is to reduce the consequences of compromise by limiting the agent’s reachable resources and available actions.
Common Exam Distinctions
Entra Agent ID versus Microsoft Agent 365
Microsoft Entra Agent ID provides the identity and access foundation for agents.
Microsoft Agent 365 provides an enterprise control plane for managing and governing agents at scale, using Entra Agent ID as its identity foundation.
Agent identity versus blueprint
An agent identity represents an individual agent.
A blueprint is the parent definition from which agent identities are created and may inherit common permissions.
Access packages versus Conditional Access
Access packages govern which resources an agent can be assigned.
Conditional Access governs under what conditions the agent can access those resources.
Identity Protection versus Conditional Access
Identity Protection detects risk.
Conditional Access can use risk signals to enforce access decisions.
Disabling an agent versus removing a permission
Disabling an agent blocks its operation and token issuance.
Removing a permission reduces what the agent can access but does not necessarily stop the agent from operating.
Autonomous versus delegated access
An autonomous agent uses its own identity and permissions.
A delegated or on-behalf-of agent operates in the context of a user and must not exceed the user’s authorized access.
Exam Tips
Remember the following points:
- Treat AI agents as identities that require lifecycle management.
- Use agent identity blueprints for consistent management and permissions.
- Review both inherited and direct permissions.
- Use access packages to govern resource assignments.
- Use Conditional Access to control access conditions.
- Use Identity Protection to detect risky agent behavior.
- A risky agent is not necessarily automatically disabled.
- Owners provide technical accountability.
- Sponsors provide business and lifecycle accountability.
- Report-only mode helps test Conditional Access policies.
- Disabling a blueprint can affect existing agents created from it.
- Tenant-wide blocking can disrupt legitimate agent workflows.
- Least privilege is especially important because agents may invoke tools and act autonomously.
- Always determine whether the agent acts autonomously or on behalf of a user.
Practice Exam Questions
Question 1
A security administrator wants to give each deployed AI agent a distinct identity that can be managed, monitored, and disabled independently. Which capability should the administrator use?
A. Azure resource locks
B. Azure Policy initiatives
C. Microsoft Defender for Storage
D. Microsoft Entra agent identities
Answer: D
Explanation: Microsoft Entra agent identities provide specialized identities for individual AI agents. They can be assigned permissions, monitored, associated with owners and sponsors, and disabled independently.
Question 2
An organization has 50 agents created for the same business function. The security team wants to apply common permissions and manage the agents consistently. What should the team use?
A. A separate Conditional Access policy for every user
B. A shared human administrator account
C. A single Azure subscription
D. An agent identity blueprint
Answer: D
Explanation: An agent identity blueprint is the parent definition from which agent identities are created. It supports consistent configuration, permission management, and administration across linked agents.
Question 3
An agent needs temporary access to a sensitive application for a specific project. The organization wants approval, expiration, and periodic review of that access. Which capability is most appropriate?
A. Microsoft Entra access packages
B. Azure resource locks
C. Microsoft Defender Antivirus
D. Azure DDoS Protection
Answer: A
Explanation: Access packages can govern resource access for agent identities and can include approval policies, expiration, and access reviews.
Question 4
A company wants to block agent identities that Microsoft Entra ID Protection identifies as having high risk. Which control should enforce this requirement?
A. Azure Policy
B. Microsoft Defender for Storage
C. Conditional Access
D. Azure Bastion
Answer: C
Explanation: Identity Protection detects agent risk, while Conditional Access can enforce a policy that blocks agents with a high agent risk level.
Question 5
Which responsibility is most closely associated with an agent sponsor?
A. Writing the agent’s application code
B. Managing the Azure virtual network
C. Creating all Microsoft Graph permissions
D. Providing business accountability and lifecycle oversight
Answer: D
Explanation: Sponsors are accountable for the agent’s business purpose and lifecycle. They help determine whether the agent is still needed and whether its access remains appropriate.
Question 6
An administrator wants to evaluate the effect of a Conditional Access policy before blocking agent identities. What should the administrator do?
A. Disable all agent blueprints
B. Configure the policy in report-only mode
C. Delete the agent identities
D. Remove all delegated permissions
Answer: B
Explanation: Report-only mode allows administrators to evaluate policy impact and identify unintended effects before enforcing the policy.
Question 7
An agent has permissions inherited from its blueprint and additional permissions assigned directly to the agent. During an access review, what should the administrator evaluate?
A. Only the direct permissions
B. Only the blueprint permissions
C. Both inherited and direct permissions
D. Only the agent’s display name
Answer: C
Explanation: An agent’s effective access can come from multiple sources. Reviewing both blueprint-inherited permissions and direct assignments is necessary to determine the agent’s complete access.
Question 8
A security team confirms that an agent identity has been compromised. Which action immediately prevents that specific agent from being issued tokens?
A. Disable the agent identity
B. Rename the agent
C. Change the agent’s description
D. Add another owner
Answer: A
Explanation: Disabling an individual agent identity blocks access and prevents the identity from being issued tokens. Adding owners or changing descriptive information does not stop the agent.
Question 9
Which statement best describes the difference between an autonomous agent and an on-behalf-of-user agent?
A. An autonomous agent cannot access any resources
B. An autonomous agent uses its own identity and permissions, while an on-behalf-of-user agent operates in a user context
C. An on-behalf-of-user agent must always have a Microsoft Entra administrator role
D. An autonomous agent does not require authentication
Answer: B
Explanation: Autonomous agents operate using their own identity and permissions. On-behalf-of-user agents operate using the context or permissions of a signed-in user.
Question 10
An organization disables an agent identity blueprint. What is the most likely security effect?
A. Only the blueprint’s display name changes
B. All human users are disabled
C. All Azure subscriptions are locked
D. Existing agents associated with the blueprint can be prevented from authenticating, and new agents cannot be created from it
Answer: D
Explanation: Disabling a blueprint can prevent new agent identities from being created from it and can block existing agents associated with the blueprint from authenticating.
Go to the SC-500 Exam Prep Hub main page
