Merge pull request #53479 from MicrosoftDocs/NEW-entra-ai-understand

New entra ai understand

Author: JillGrant615

learn-pr/wwl-sci/entra-ai-understand/authentication-flows-microsoft-foundry.yml

@@ -0,0 +1,15 @@
+### YamlMime:ModuleUnit
+uid: learn.wwl.entra-ai-understand.authentication-flows-microsoft-foundry
+title: Authentication flows for AI endpoints in Microsoft Foundry
+metadata:
+  title: Authentication flows for AI endpoints in Microsoft Foundry
+  description: "Authentication flows for AI endpoints in Microsoft Foundry."
+  ms.date: 2/13/2026
+  author: wwlpublish
+  ms.author: riswinto
+  ms.topic: unit
+azureSandbox: false
+labModal: false
+durationInMinutes: 5
+content: |
+  [!include[](includes/authentication-flows-microsoft-foundry.md)]

learn-pr/wwl-sci/entra-ai-understand/common-identity-misconfigurations-ai.yml

@@ -0,0 +1,15 @@
+### YamlMime:ModuleUnit
+uid: learn.wwl.entra-ai-understand.common-identity-misconfigurations-ai
+title: Common identity misconfigurations in AI deployments
+metadata:
+  title: Common identity misconfigurations in AI deployments
+  description: "Common identity misconfigurations in AI deployments."
+  ms.date: 2/13/2026
+  author: wwlpublish
+  ms.author: riswinto
+  ms.topic: unit
+azureSandbox: false
+labModal: false
+durationInMinutes: 6
+content: |
+  [!include[](includes/common-identity-misconfigurations-ai.md)]

learn-pr/wwl-sci/entra-ai-understand/human-workload-identities-ai-environments.yml

@@ -0,0 +1,15 @@
+### YamlMime:ModuleUnit
+uid: learn.wwl.entra-ai-understand.human-workload-identities-ai-environments
+title: Human and workload identities in AI workloads
+metadata:
+  title: Human and workload identities in AI workloads
+  description: "Human and workload identities in AI workloads."
+  ms.date: 2/13/2026
+  author: wwlpublish
+  ms.author: riswinto
+  ms.topic: unit
+azureSandbox: false
+labModal: false
+durationInMinutes: 5
+content: |
+  [!include[](includes/human-workload-identities-ai-environments.md)]

learn-pr/wwl-sci/entra-ai-understand/identity-control-layer-ai-solutions.yml

@@ -0,0 +1,15 @@
+### YamlMime:ModuleUnit
+uid: learn.wwl.entra-ai-understand.identity-control-layer-ai-solutions
+title: Identity as the control layer for AI solutions
+metadata:
+  title: Identity as the control layer for AI solutions
+  description: "Identity as the control layer for AI solutions."
+  ms.date: 2/13/2026
+  author: wwlpublish
+  ms.author: riswinto
+  ms.topic: unit
+azureSandbox: false
+labModal: false
+durationInMinutes: 5
+content: |
+  [!include[](includes/identity-control-layer-ai-solutions.md)]

learn-pr/wwl-sci/entra-ai-understand/includes/authentication-flows-microsoft-foundry.md

@@ -0,0 +1,62 @@
+Understanding that identity governs access isn't enough. You also need to understand how an identity proves who it is when calling an AI endpoint.
+
+Every request to an AI endpoint must include valid authentication credentials. Microsoft Foundry relies on industry-standard OAuth 2.0 flows and Microsoft Entra ID to issue and validate access tokens.
+
+At a high level, authentication answers three questions:
+
+- Who is calling the model?
+- From where is the request originating?
+- What credential is being presented?
+
+## OAuth 2.0 and token issuance
+
+AI endpoints use OAuth 2.0 to authenticate callers. When a user, application, or workload attempts to access a protected AI resource, Microsoft Entra ID evaluates the request and issues an access token if authentication succeeds.
+
+That token represents the authenticated identity. It contains claims about:
+
+- The identity
+- The tenant
+- Assigned roles or permissions
+- Token lifetime
+
+The caller includes the access token in requests to the AI endpoint. The service validates the token before processing the request.
+
+For example, a web application that calls an AI endpoint uses its service principal to request a token from Microsoft Entra ID. If authentication succeeds, Microsoft Entra issues an access token. The application includes that token in its request, and the AI endpoint validates it before processing the prompt.
+
+If the token is invalid, expired, or improperly scoped, the request fails before reaching the model.
+
+## Interactive and non-interactive authentication
+
+Authentication flows differ depending on who or what is calling the endpoint.
+
+Interactive authentication typically involves a human user. For example:
+
+- A developer signs in to deploy a model through Microsoft Foundry.
+- An administrator configures AI resources in the Azure portal.
+
+In these cases, the user authenticates through Microsoft Entra ID, and an access token is issued for that session.
+
+Non-interactive authentication is used by applications and workloads. Examples include:
+
+- A web application calling a model endpoint
+- An automation workflow deploying updates
+- A backend service retrieving embeddings
+
+In these scenarios, authentication occurs without human interaction. The application uses a service principal or managed identity to obtain an access token from Microsoft Entra ID.
+
+At runtime, the AI endpoint doesn't distinguish between human and application requests. It validates the token and evaluates authorization based on the identity represented in that token.
+
+## Token flow between client and AI endpoint
+
+The authentication sequence follows a consistent pattern:
+
+1. The client requests an access token from Microsoft Entra ID.
+1. Microsoft Entra ID authenticates the caller and issues a token if the request is valid.
+1. The client includes the token in the request to the AI endpoint.
+1. The endpoint validates the token before evaluating authorization.
+
+Only after successful authentication and authorization does the service process the model request.
+
+This flow ensures that every AI interaction in Microsoft Foundry is tied to a verified identity and evaluated against assigned permissions.
+
+Understanding this sequence prepares you to analyze authentication failures, token misuse, and access control misconfigurations in AI environments. It also clarifies how different identity types authenticate and why that distinction matters.

learn-pr/wwl-sci/entra-ai-understand/includes/common-identity-misconfigurations-ai.md

@@ -0,0 +1,85 @@
+Strong authentication and well-defined roles don't guarantee secure AI workloads. Identity design decisions determine whether access boundaries hold under pressure.
+
+Identity design failures cause most AI security incidents, not flaws in the model itself. Common drivers include misconfigured identities, excessive permissions, and weak enforcement controls.
+
+Understanding common misconfigurations helps you recognize risk patterns early.
+
+## Overprivileged application identities
+
+Service principals and managed identities often receive broad permissions for convenience.
+
+For example:
+
+- Assigning contributor access at the subscription level
+- Granting both management and data plane permissions when only one is required
+- Reusing a single application identity across multiple workloads
+
+Because application identities operate without human interaction, excessive permissions can enable automated misuse at scale.
+
+When an overprivileged identity is compromised, the blast radius extends to every resource within its assigned scope.
+
+## Broad scope assignments
+
+Scope selection directly affects blast radius.
+
+Assigning roles at the subscription level might simplify administration, but it broadens access beyond what's necessary. A compromised identity with subscription-level permissions can modify or access multiple AI resources across environments.
+
+Limiting scope to a specific resource group or AI endpoint narrows the scope of access and aligns more closely with least-privilege principles.
+
+Convenience shouldn't override scope discipline.
+
+## Shared credentials and secret management
+
+Application identities that rely on shared secrets introduce additional risk.
+
+Embedding credentials in code, storing them in unsecured configuration files, or failing to rotate secrets increases the likelihood of compromise.
+
+Managed identities reduce some of this risk by removing the need to manage credentials directly. However, they don't eliminate the need for proper role assignment and scope control.
+
+Secret management failures often surface long after initial deployment, when credentials are reused across environments or teams.
+
+## Mixing development and production identities
+
+Using the same identity for development and production workloads expands the potential scope of a compromise.
+
+Development environments often have broader permissions and less restrictive controls. If that identity also has production access, a compromise in development can affect production systems.
+
+Separating identities by environment limits lateral movement and narrows the scope of a compromise.
+
+Environment boundaries should be reflected in identity boundaries.
+
+## Token handling and leakage risks
+
+Access tokens represent authenticated identities. If tokens are logged, exposed in client-side code, or transmitted insecurely, they can be replayed until expiration.
+
+Short token lifetimes and secure storage practices reduce this risk. Monitoring unusual token usage patterns also helps detect misuse.
+
+Authentication doesn't eliminate risk. It defines the boundary of trust.
+
+## Missing Conditional Access enforcement
+
+Authentication alone doesn't guarantee secure access conditions.
+
+If Conditional Access policies aren't applied to relevant identities, attackers might authenticate successfully without meeting device compliance, location, or multifactor requirements.
+
+Conditional Access strengthens identity enforcement by evaluating context in addition to credentials.
+
+Without it, identity security relies solely on credential protection.
+
+Certain operational symptoms often point back to identity design decisions. Unexpected model deployments can indicate excessive management plane permissions, while unusual model invocation patterns or data access spikes might suggest overly broad data plane access. When investigating AI incidents, examining identity scope and role assignments is often more revealing than inspecting the model itself.
+
+## Closing the loop
+
+Identity architecture defines who can access AI resources, what they can do, and where that access applies.
+
+Misconfigurations weaken those boundaries.
+
+Designing identity intentionally means:
+
+- Assigning only required permissions
+- Limiting scope appropriately
+- Separating environments
+- Protecting credentials
+- Enforcing contextual access controls
+
+AI security depends on identity discipline. The tools that monitor posture and detect risk build on these foundations, but they don't replace them.

learn-pr/wwl-sci/entra-ai-understand/includes/human-workload-identities-ai-environments.md

@@ -0,0 +1,69 @@
+AI endpoints don't distinguish between human and application requests at runtime. They validate tokens and evaluate permissions based on the identity presented.
+
+For security design, the type of identity matters.
+
+Understanding the differences between **human**, **application**, and **managed identities** helps you assign permissions correctly and reduce risk.
+
+## Human identities
+
+Human identities represent individual users authenticated through Microsoft Entra ID.
+
+These identities are used when a person directly interacts with AI resources. Examples include:
+
+- A developer deploying or updating a model
+- An administrator configuring resource settings
+- A security analyst reviewing posture or activity
+
+Human identities are typically authenticated through interactive sign-in. Conditional Access, multifactor authentication, and device compliance policies commonly apply to these sessions.
+
+Because human identities represent real individuals, their permissions should reflect job responsibilities and follow least-privilege principles.
+
+Overassigning permissions to user accounts increases risk, particularly in the management plane.
+
+## Application identities
+
+Application identities represent software rather than people. In Microsoft Entra ID, these are typically implemented as service principals associated with application registrations. An application registration defines the application globally, while a service principal represents that application as a security identity within a specific tenant.
+
+They're used when software calls an AI endpoint directly. Examples include:
+
+- A web application submitting prompts
+- A backend service retrieving embeddings
+- An automation workflow deploying updates
+
+Authentication occurs through non-interactive flows. The application presents credentials, and Microsoft Entra ID issues an access token for that identity.
+
+Application identities shouldn't use shared secrets embedded in code or configuration without proper protection. Excessive permissions assigned to a service principal can allow broad, automated misuse of AI resources.
+
+## Managed identities
+
+Managed identities are a specialized type of application identity. They're designed to reduce credential management overhead.
+
+When you enable a managed identity on an Azure resource, Microsoft Entra ID automatically creates and manages the associated identity. The platform handles credential rotation and lifecycle management.
+
+Managed identities are appropriate when:
+
+- An Azure-hosted resource needs to access an AI endpoint
+- You want to avoid storing credentials in application code
+- You want tighter integration with Azure role assignments
+
+Managed identities reduce the risk associated with secret management. However, they still require careful role assignment and scope control.
+
+## Choosing the appropriate identity model
+
+The appropriate identity type depends on who or what is accessing the AI resource.
+
+Use a human identity when a person is directly performing administrative or development tasks.
+
+Use an application identity when software must authenticate independently.
+
+Use a managed identity when the workload runs in Azure and can rely on platform-managed credentials.
+
+Each identity type introduces different security considerations:
+
+- Human identities require strong authentication controls.
+- Application identities require strict permission boundaries.
+- Managed identities require careful scope assignment.
+
+The identity type you choose affects the potential blast radius if that identity is compromised.
+
+Understanding these distinctions allows you to design access intentionally rather than defaulting to broad or convenient configurations. The next step is defining what those identities are actually permitted to do and where those permissions apply.

learn-pr/wwl-sci/entra-ai-understand/includes/identity-control-layer-ai-solutions.md

@@ -0,0 +1,48 @@
+Securing AI workloads starts with identity. Before configuring roles or conditional access policies, you need to understand how authentication and authorization govern every interaction with an AI service.
+
+Every prompt submitted to a model, every deployment, every configuration change, and every API call requires an authenticated identity. AI services are designed to enforce identity-based access and don't support anonymous interaction by design.
+
+If identity controls access to Azure resources, it also determines how AI systems are used. That makes identity the control layer for AI security.
+
+Before evaluating model safety settings or data protections, start with a more fundamental question:
+
+**Who is allowed to access the AI service, and under what conditions?**
+
+## Why identity comes first in AI security
+
+AI services expose authenticated endpoints. Access to AI services isn't anonymous. A user, application, or managed workload must present credentials that Microsoft Entra ID validates.
+
+Once authenticated, authorization determines what that identity can do:
+
+- Deploy or modify a model
+- Invoke a model endpoint
+- Access training data
+- Change configuration settings
+
+These decisions occur before the AI service processes a request.
+
+Authentication verifies identity. Authorization enforces assigned permissions. Only after both steps succeed does the AI service process the request.
+
+In many real-world deployments, identity design issues cause more security failures than the model itself. Common examples include:
+
+- Excessive permissions
+- Broad role assignments
+- Shared credentials
+- Unmanaged service principals
+
+When identity is misconfigured, the AI environment inherits that weakness.
+
+## Identity across AI development and runtime
+
+AI solutions are often developed and deployed using services like Microsoft Foundry. These services integrate directly with Microsoft Entra ID for authentication and authorization.
+
+Identity is present at every stage:
+
+- Developers authenticate to create and configure resources.
+- Applications authenticate to call model endpoints.
+- Automation workflows authenticate to deploy updates.
+- Security teams authenticate to review posture and investigate activity.
+
+Security platforms like Microsoft Defender for Cloud rely on identity context to evaluate risk and surface misconfigurations. Without a clear identity architecture, posture insights lack meaningful context.
+
+Secure AI access rests on four elements: identity, authentication, authorization, and scope. Each layer builds on the previous one. When identity design is sound, these layers work together to create predictable and enforceable access boundaries.

learn-pr/wwl-sci/entra-ai-understand/includes/introduction.md

@@ -0,0 +1,25 @@
+Most AI security conversations focus on model behavior, data exposure, or runtime misuse. In AI workloads running in Azure, identity architecture often determines whether those risks are even possible.
+
+AI workloads don't change how Microsoft Entra ID works. What changes is how identity decisions play out once models are deployed, invoked at scale, and integrated into automated pipelines. The separation between management and data plane operations, combined with scoped role assignments, introduces risk patterns that aren't obvious in traditional application deployments.
+
+In AI environments, identity isn't just about signing in to a portal. It defines what actions are possible across deployment and runtime:
+
+- Who can deploy or modify models
+- Who can invoke endpoints and retrieve data
+- How applications and services authenticate during execution
+- How far permissions extend across subscriptions, resource groups, and individual AI resources
+
+Small gaps between identity type, role assignment, and scope can quietly expand the blast radius. Those gaps often surface only during an incident or investigation.
+
+## Learning objectives
+
+By the end of this module, you'll be able to:
+
+- Explain identity as the control layer for AI solutions in Azure
+- Distinguish between management plane and data plane access in AI workloads
+- Describe authentication flows used by AI endpoints integrated with Microsoft Entra ID
+- Distinguish between human and workload identities
+- Interpret role assignments and scope boundaries across AI resources
+- Recognize common identity design patterns that increase AI risk
+
+Once identity behavior in AI workloads is clear, access decisions become intentional rather than automatic. That clarity is essential when designing role assignments, enforcing least privilege, and applying Conditional Access in AI environments.