Tag: Entra Agent ID

Analyze blast radius for security risks related to Entra Agent ID by using Defender XDR (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
      --> Analyze blast radius for security risks related to Entra Agent ID by using Defender XDR


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 can access data, invoke tools, call APIs, and perform actions across an organization. If an agent identity is compromised, the impact may extend far beyond the agent itself.

For example, an agent might have permission to:

  • Read confidential documents.
  • Access a customer database.
  • Modify records in a business application.
  • Call privileged APIs.
  • Access other identities or resources.
  • Use knowledge sources containing sensitive information.

The blast radius of an agent represents the potential impact of compromising that agent identity. It helps security teams understand what an attacker might be able to reach or control by abusing the agent’s permissions, connected resources, and relationships.

Microsoft Defender XDR provides an AI agent inventory, posture-risk information, and attack-path analysis to help security teams discover agents and assess the consequences of a compromised agent identity.


What Is Microsoft Entra Agent ID?

Microsoft Entra Agent ID provides identity capabilities for AI agents. Instead of treating every agent as an unidentified application process, an organization can represent an agent with a distinct identity that can be:

  • Authenticated.
  • Assigned permissions.
  • Governed.
  • Monitored.
  • Investigated.
  • Disabled or remediated when risky.

An agent identity should be treated as a security principal with a defined owner, purpose, permission set, and lifecycle.

This is important because an AI agent may have more effective access than its name or user interface suggests. The agent’s actual risk depends on what it can access and what actions it can perform—not merely on what the agent was designed to do.


What Is Blast Radius?

The blast radius is the set of resources, identities, applications, data, and systems that could potentially be affected if an agent identity were compromised.

A blast-radius assessment asks questions such as:

  • What permissions does the agent have?
  • Which applications and APIs can it access?
  • Which data sources are available to it?
  • Can it read or modify sensitive data?
  • Can it invoke tools that perform destructive actions?
  • Can it access privileged business systems?
  • Can it reach other identities or resources through existing relationships?
  • Are there attack paths from the agent to critical assets?

Example

Suppose an AI agent has:

  • Read access to a document repository.
  • Write access to a purchasing application.
  • Permission to call an external API.
  • Access to a knowledge source containing confidential business information.

If the agent is compromised, the attacker might be able to:

  1. Read confidential documents.
  2. Extract sensitive information.
  3. Submit unauthorized purchasing requests.
  4. Use the external API to transfer data.
  5. Reach additional resources through the agent’s permissions.

The agent’s blast radius is therefore larger than the agent itself.


Why AI Agents Create Unique Blast-Radius Risks

AI agents introduce additional risk because they can dynamically determine which tools to use and which actions to perform.

Traditional applications often follow fixed workflows. Agents may instead:

  • Interpret natural-language instructions.
  • Retrieve information from multiple sources.
  • Select tools dynamically.
  • Chain several actions together.
  • Act autonomously.
  • Use permissions inherited from a user or application.
  • Operate without continuous human approval.

A compromised or manipulated agent may therefore use legitimate permissions in unintended ways.

Important AI-related risks include:

  • Over-privileged agent identities.
  • Excessive access to sensitive data.
  • Unrestricted tool invocation.
  • Indirect prompt injection.
  • Weak or missing authentication.
  • Agents that can operate without human approval.
  • Privileged access to business systems.
  • Active threats or alerts associated with the agent.

Microsoft Defender assesses agent posture using risk indicators derived from configuration, permissions, tools, runtime activity, settings, and associated security alerts.


Microsoft Defender XDR AI Agent Inventory

Microsoft Defender XDR provides a centralized inventory of AI agents in the organization.

Depending on the available integrations and supported platforms, the inventory can include agents built with:

  • Microsoft Copilot Studio.
  • Microsoft Foundry.
  • Microsoft 365.
  • Supported non-Microsoft platforms.
  • Local AI agents discovered on endpoint devices.

The inventory can provide information about:

  • Agent identity.
  • Agent type.
  • Agent configuration.
  • Connected tools.
  • Knowledge sources.
  • Risk level.
  • Risk indicators.
  • Security recommendations.
  • Related alerts.
  • Security context.

To review agents in the Microsoft Defender portal, navigate to:

Assets → AI agents → Agents

The exact portal experience may change as Microsoft’s AI security capabilities evolve.


Agent Risk Level Versus Blast Radius

These concepts are related but are not identical.

Agent risk level

The risk level represents the overall security risk associated with an agent. Microsoft Defender combines active risk indicators to determine an overall risk level.

Possible risk levels include:

  • High
  • Medium
  • Low
  • No known risk
  • Not evaluated

Risk indicators may include:

  • Weak instructions.
  • Indirect prompt-injection exposure.
  • Privileged business-system access.
  • High usage.
  • Active threats.
  • Lack of human approval.
  • Access to sensitive data.

The risk level is influenced by both the severity and combination of active indicators.

Blast radius

Blast radius focuses on the potential impact if the agent is compromised.

An agent could have a high blast radius even if no active threat has been detected. For example, an agent may be operating as designed but have broad permissions to critical systems.

Conversely, an agent may have a low blast radius but still be actively compromised.

Therefore:

Risk level describes the likelihood and seriousness of the agent’s security exposure. Blast radius describes what could be affected if the agent were compromised.

Security teams should evaluate both.


Key Risk Indicators

Microsoft Defender uses risk indicators to provide context about an agent’s exposure.

Privileged business-system access

This indicates that an agent has write access to important business systems.

Examples include:

  • Creating or modifying financial transactions.
  • Changing customer records.
  • Updating inventory.
  • Modifying business-critical configurations.
  • Accessing administrative APIs.

An agent with write access generally has a greater blast radius than an agent with read-only access.

Indirect prompt-injection exposure

An agent may retrieve content containing hidden instructions from:

  • Email.
  • Documents.
  • Web pages.
  • Knowledge bases.
  • External data sources.

The content may attempt to manipulate the agent into performing unintended actions.

This risk is especially important when the agent can access sensitive data or invoke powerful tools.

Weak instructions

Weak or incomplete instructions may fail to establish safe operating boundaries for the agent.

For example, an agent may not be clearly instructed to:

  • Refuse unauthorized requests.
  • Avoid exposing secrets.
  • Request approval before destructive actions.
  • Validate tool parameters.
  • Restrict access to approved resources.

High-usage agent

An agent used by many people may be important to business operations. A compromise could affect a large number of users or business processes.

High usage does not necessarily mean the agent is insecure, but it increases the importance of careful review.

Active threat

An active threat indicator means that security alerts are associated with the agent.

An agent with both an active threat and privileged access should receive immediate attention because the likelihood and potential impact of compromise may both be significant.


Understanding Attack Paths

An attack path is a possible sequence of relationships or permissions that could allow an attacker to move from a compromised entity to a target resource.

For an agent, an attack path might look like:

Compromised agent identity → application permission → sensitive database → confidential data

Another example could be:

Compromised agent → privileged API → business application → administrative action

Attack-path analysis helps identify indirect exposure that may not be obvious when reviewing the agent’s permissions individually.

A single permission may appear harmless, but a sequence of permissions and relationships may create a significant route to a critical asset.

Microsoft Defender graphs use nodes and edges to represent entities and relationships. Attack-path analysis can show potential routes between a source entity and a target asset.


How to Analyze an Agent’s Blast Radius

Step 1: Discover the agent

Open the Microsoft Defender portal and review the AI agent inventory.

Identify:

  • The agent name.
  • The agent type.
  • Its associated identity.
  • Its owner.
  • Its environment.
  • Its connected tools.
  • Its knowledge sources.
  • Its risk level.

The inventory is the starting point for understanding which agents exist and which require further investigation.

Step 2: Review the agent’s configuration

Examine how the agent is configured.

Important questions include:

  • Is the agent autonomous?
  • Does it act on behalf of a user?
  • Can it operate without human approval?
  • Which tools can it invoke?
  • Which applications can it access?
  • Does it have write or administrative capabilities?
  • Does it use external services?
  • Does it retrieve content from untrusted sources?

Configuration weaknesses can increase the likelihood that an agent will be manipulated or misused.

Step 3: Review permissions and identities

Determine the permissions assigned to the agent identity.

Review:

  • Microsoft Entra roles.
  • Application permissions.
  • Delegated permissions.
  • API scopes.
  • Resource access.
  • Group memberships.
  • Access packages.
  • Privileged assignments.
  • Permissions inherited through applications or users.

The goal is to determine what the agent can actually do, not merely what it is intended to do.

Step 4: Review knowledge sources

Knowledge sources can significantly increase an agent’s blast radius.

Review whether the agent can access:

  • Confidential documents.
  • Customer information.
  • Financial data.
  • Internal policies.
  • Credentials or secrets.
  • Sensitive databases.
  • External content.
  • Data belonging to multiple departments.

An agent with read access to a broad knowledge source may expose more information than expected, even if it cannot modify the underlying data.

Step 5: Review connected tools

Tools determine what actions the agent can perform.

Examples include tools that:

  • Query databases.
  • Send email.
  • Create support tickets.
  • Modify records.
  • Call external APIs.
  • Execute workflows.
  • Access storage.
  • Provision resources.

A tool with write, delete, or administrative capability can substantially increase the agent’s potential impact.

Step 6: Review blueprint configuration

Agent identity blueprints can provide a consistent way to create and manage agent identities.

Review blueprint configuration to determine whether it establishes:

  • Appropriate identity settings.
  • Required governance.
  • Permission boundaries.
  • Consistent security controls.
  • Appropriate ownership.
  • Secure defaults.

A poorly configured blueprint may create multiple agents with the same excessive permissions or weak security settings.

Step 7: Review risk indicators and recommendations

Review the agent’s active risk indicators and any available security recommendations.

Risk indicators describe the agent’s exposure. Recommendations identify actionable changes that may reduce that exposure.

A high-risk agent may not always have an available recommendation, and a lower-risk agent may still have a recommendation that should be implemented. Therefore, review the risk level and recommendations together.

Step 8: Analyze attack paths

Use the available Defender graph and attack-path capabilities to investigate possible routes from the agent to sensitive resources.

Look for paths involving:

  • Privileged identities.
  • Sensitive applications.
  • Critical databases.
  • Storage accounts.
  • Administrative roles.
  • High-value business systems.
  • External access.
  • Lateral movement.

The objective is to identify not only direct access but also indirect routes that could lead to compromise of critical assets.

Step 9: Prioritize remediation

Prioritize agents that combine several high-impact characteristics, such as:

  • High risk.
  • Privileged access.
  • Access to sensitive data.
  • Autonomous operation.
  • External exposure.
  • Active security alerts.
  • Write access to critical systems.
  • Multiple attack paths to important assets.

Defender Blast-Radius Graphs

Microsoft Defender can display graph-based views of entities and potential attack paths.

A graph generally contains:

  • Nodes, representing entities or assets.
  • Edges, representing relationships or connections.
  • Paths, representing possible routes between entities.

For an incident, investigators can select an entity and choose View blast radius when the capability is available. The graph can show highly rated attack paths and a list of reachable targets. Investigators can select a target to inspect the potential path leading to it.

What the graph can help identify

The graph may reveal:

  • A compromised identity’s reachable resources.
  • Indirect paths to critical assets.
  • Relationships between identities and applications.
  • Potential lateral movement.
  • Privilege-escalation routes.
  • Access to sensitive data.
  • Connections between an agent and other entities.

Important limitations

Blast-radius graphs are an approximation of possible attack reach.

They may be limited by:

  • The number of hops analyzed.
  • Data freshness.
  • The attack techniques modeled.
  • The viewer’s RBAC scope.
  • Missing or incomplete relationships.
  • Changes in the environment that have not yet been reflected.

The graph shows possible paths. It does not guarantee that an attacker will use every path shown.


Interpreting the Blast Radius Correctly

A blast-radius graph should not be interpreted as proof that a compromise has occurred.

Instead, it answers:

“If this identity were compromised, what resources might be reachable through known relationships and permissions?”

The graph is useful for:

  • Prioritizing remediation.
  • Identifying excessive permissions.
  • Understanding lateral movement.
  • Finding critical assets exposed through an agent.
  • Supporting incident investigation.
  • Designing Conditional Access policies.
  • Improving agent architecture.

It should be combined with:

  • Actual sign-in and activity logs.
  • Security alerts.
  • Agent configuration.
  • Permission reviews.
  • Data classification.
  • Business criticality.
  • Incident-response procedures.

Example Scenario

A company deploys an autonomous finance agent.

The agent can:

  • Read invoices.
  • Query a financial database.
  • Submit payment requests.
  • Access a shared document repository.
  • Call a payment-processing API.

Defender identifies the following risk indicators:

  • Privileged business-system access.
  • Indirect prompt-injection exposure.
  • Ability to operate without human approval.
  • Access to sensitive financial data.

An attack-path analysis shows:

Agent identity → payment API → financial system

It also shows:

Agent identity → shared repository → confidential financial documents

The security team should consider:

  1. Removing unnecessary write permissions.
  2. Requiring human approval for payment actions.
  3. Restricting the agent to approved APIs.
  4. Limiting access to financial documents.
  5. Reviewing prompt-injection protections.
  6. Applying Conditional Access to high-risk agent identities.
  7. Monitoring related alerts and activity.
  8. Reassessing the blast radius after remediation.

Relationship to Conditional Access

Conditional Access and blast-radius analysis work together.

Blast-radius analysis helps answer:

  • Which agents are high impact?
  • Which agents have privileged access?
  • Which resources should be protected?
  • Which agents should be restricted or blocked?

Conditional Access can then enforce policies such as:

  • Block high-risk agent identities.
  • Restrict selected agents from sensitive applications.
  • Separate development and production agents.
  • Apply policies based on agent attributes.
  • Restrict access to selected resources.

Microsoft Entra ID Protection can detect risky agent behavior. When an agent is confirmed as compromised, its risk can be set to High, allowing a Conditional Access policy configured to block high agent risk to prevent access to resources.


Relationship to Microsoft Defender for Cloud and Microsoft Purview

Blast-radius analysis is not the same as every other security capability.

Microsoft Defender XDR

Used for:

  • AI agent inventory.
  • Agent risk assessment.
  • Identity investigation.
  • Attack-path analysis.
  • Security alerts.
  • Incident investigation.

Microsoft Defender for Cloud

Used more broadly for:

  • Cloud security posture management.
  • Workload protection.
  • Security recommendations.
  • Cloud resource security.
  • AI workload protection.

Microsoft Purview

Used for:

  • Data classification.
  • Sensitivity labels.
  • Data security posture management.
  • Data-loss prevention.
  • Compliance and information protection.

Microsoft Entra Conditional Access

Used for:

  • Evaluating access conditions.
  • Blocking risky agent identities.
  • Restricting access to selected resources.
  • Enforcing identity-based access policies.

These capabilities complement one another. No single control provides complete protection for AI agents.


Best Practices

Use dedicated agent identities

Avoid sharing a broad identity across unrelated agents. Separate identities improve accountability and reduce the impact of a single compromise.

Apply least privilege

Grant only the permissions required for the agent’s purpose.

Minimize write and administrative permissions

Read-only access generally creates a smaller blast radius than the ability to modify or delete data.

Restrict tools

Every connected tool expands the agent’s potential attack surface. Remove tools that are not required.

Use approval gates

Require human approval for:

  • Financial transactions.
  • Data deletion.
  • Permission changes.
  • External communications.
  • Production changes.
  • Other high-impact actions.

Protect knowledge sources

Limit the data available to the agent and ensure that sensitive sources are properly secured.

Separate environments

Development and test agents should not automatically have access to production resources.

Review blueprints

Ensure that agent identity blueprints do not create agents with excessive or inconsistent permissions.

Monitor active threats

An agent with active alerts and privileged access should be investigated immediately.

Reassess after changes

Recalculate or review the agent’s exposure after changing:

  • Permissions.
  • Tools.
  • Knowledge sources.
  • Identity configuration.
  • Resource access.
  • Blueprint settings.

Treat graphs as possible paths

Do not assume that every path shown is an active attack or that every possible path is displayed.


Common Exam Traps

Blast radius is not the same as risk level

Risk level describes the agent’s overall security exposure. Blast radius describes the potential impact of compromise.

An agent does not need to be compromised to have a large blast radius

An agent may be configured with excessive permissions even when no threat has been detected.

Read access and write access are different

Write access to critical business systems generally creates a greater potential impact than read-only access.

Attack paths show possibilities

A graph shows possible routes based on known relationships and data. It does not prove that an attacker has used the route.

Conditional Access does not remove permissions

Conditional Access controls whether access is allowed under specified conditions. It does not replace least-privilege authorization.

Risk indicators and recommendations are different

Risk indicators contribute to the agent’s risk assessment. Recommendations identify available actions that may improve security posture.

A high-risk agent may not have a recommendation

Risk level and available recommendations are calculated separately.

Missing graph paths do not prove that no risk exists

Graphs have scope, freshness, and modeling limitations.


Practice Exam Questions

Question 1

What does the blast radius of a Microsoft Entra agent identity primarily describe?

A. The number of users who have interacted with the agent
B. The amount of compute capacity assigned to the agent
C. The potential resources and systems affected if the agent identity is compromised
D. The number of prompts processed by the agent

Correct answer: C

Explanation: Blast radius describes the potential impact of compromising the agent, including reachable data, applications, identities, and systems.


Question 2

Which Microsoft Defender capability provides a centralized view of AI agents and their security context?

A. Azure Cost Management
B. Azure Resource Graph only
C. Microsoft Purview retention management
D. AI agent inventory

Correct answer: D

Explanation: The AI agent inventory in Microsoft Defender provides visibility into agents, configuration, identities, risk indicators, tools, and related security information.


Question 3

An agent has no active security alerts but can modify a critical financial system. What should the security team conclude?

A. The agent has no security risk
B. The agent has a potentially large blast radius even though no compromise has been detected
C. The agent must be deleted immediately
D. The agent cannot be protected by Conditional Access

Correct answer: B

Explanation: Blast radius is based on potential impact. Privileged access can create significant exposure even when no active threat has been detected.


Question 4

Which risk indicator most directly suggests that an agent can affect important business operations?

A. High usage
B. Weak instructions
C. Indirect prompt-injection exposure
D. Privileged business-system access

Correct answer: D

Explanation: Privileged business-system access indicates that the agent can write to or otherwise affect important business systems.


Question 5

What is the purpose of analyzing attack paths for an agent identity?

A. To determine the model’s response quality
B. To identify possible routes from the agent to other resources or critical assets
C. To calculate the agent’s monthly operating cost
D. To configure the agent’s natural-language instructions

Correct answer: B

Explanation: Attack-path analysis identifies possible relationships and permission chains that could allow access to additional resources or critical assets.


Question 6

Which statement best distinguishes an agent’s risk level from its blast radius?

A. Risk level measures potential impact only, while blast radius measures prompt quality
B. Risk level applies only to human users, while blast radius applies only to applications
C. Risk level reflects overall security exposure, while blast radius reflects potential impact if compromised
D. They are two names for exactly the same measurement

Correct answer: C

Explanation: Risk level combines active risk indicators. Blast radius focuses on what could be affected if the agent identity were compromised.


Question 7

A Defender blast-radius graph displays a path from an agent to a sensitive database. What does this mean?

A. The agent has definitely been compromised
B. The database has already been accessed
C. The graph identifies a possible route based on known relationships and permissions
D. The agent must be assigned a database administrator role

Correct answer: C

Explanation: A blast-radius graph shows possible attack paths. It does not prove that compromise or access has occurred.


Question 8

Which change would most directly reduce an agent’s blast radius?

A. Remove unnecessary write permissions and restrict the agent to required resources
B. Increase the agent’s model size
C. Add more knowledge sources
D. Allow the agent to use additional administrative APIs

Correct answer: A

Explanation: Reducing permissions and limiting resource access directly reduces what the agent could affect if compromised.


Question 9

Why should security teams review an agent’s knowledge sources during blast-radius analysis?

A. Knowledge sources determine the agent’s compute pricing
B. Knowledge sources may expose confidential or sensitive information to the agent
C. Knowledge sources automatically grant Global Administrator access
D. Knowledge sources eliminate the need for identity protection

Correct answer: B

Explanation: Knowledge sources may contain sensitive information. The agent’s access to those sources can significantly increase the impact of compromise or misuse.


Question 10

Which statement about Microsoft Defender blast-radius graphs is accurate?

A. They show every possible attack path with complete certainty
B. They prove that all displayed paths have been exploited
C. They replace permission reviews and incident investigation
D. They show possible paths and may be limited by data freshness, scope, and modeled attack techniques

Correct answer: D

Explanation: Blast-radius graphs are useful approximations, but they have limitations involving data freshness, RBAC scope, hop limits, and known attack vectors.


Go to the SC-500 Exam Prep Hub main page

Manage Entra Agent ID access (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
      --> 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

ConceptDescription
Agent identity blueprintParent definition used to create and authorize agent identities
Agent identityIndividual identity representing a deployed AI agent
Blueprint permissionsPermissions that can be inherited by agents created from the blueprint
Agent-specific accessAccess assigned directly to an individual agent, such as through an access package
Blueprint ownerPerson responsible for technical administration
Agent sponsorPerson 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

TaskTypical role or responsibility
View agent identitiesMicrosoft Entra user account
Manage agent identitiesAgent ID Administrator or Cloud Application Administrator
Create agent blueprintsAgent ID Developer
Configure Conditional AccessConditional Access Administrator
View Identity Protection risk reportsSecurity Administrator, Security Operator, or Security Reader
Manage lifecycle workflowsLifecycle Workflows Administrator
Manage an owned or sponsored agentAgent 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

  1. Define the agent’s business purpose.
  2. Identify the minimum required resources.
  3. Assign the narrowest available permissions.
  4. Avoid inheriting high-privilege permissions unless required.
  5. Review the permissions assigned to the blueprint.
  6. Review the permissions of each linked agent.
  7. 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:

  1. Create the Conditional Access policy.
  2. Configure it in report-only mode.
  3. Review sign-in and policy impact.
  4. Identify agents that would be blocked.
  5. Correct unintended dependencies.
  6. Enable enforcement.
  7. 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.

CapabilityPrimary purpose
Identity Protection for agentsDetect anomalous or risky agent behavior
Conditional AccessEnforce access conditions based on identity, context, and risk
Agent administrationEnable, disable, and manage agent identities
Access packagesGovern assignment and duration of resource access
Defender XDRDiscover, 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:

  1. Create a clearly defined business purpose.
  2. Assign a technical owner and business sponsor.
  3. Remove access to email and source code unless explicitly required.
  4. Replace broad CRM permissions with narrowly scoped roles.
  5. Separate read-only operations from write operations.
  6. Restrict production API access.
  7. Use an access package for temporary elevated access.
  8. Apply Conditional Access policies.
  9. Monitor sign-ins and risk signals.
  10. Disable the agent if compromise is suspected.
  11. Review all agents created from the same blueprint.
  12. 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