entra ai understand module

Author: riswinto

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

@@ -0,0 +1 @@
+Authentication flows for AI endpoints in Microsoft Foundry

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

@@ -0,0 +1 @@
+Human and workload identities in AI workloads

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

@@ -0,0 +1 @@
+Identity as the control layer for AI solutions

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

@@ -0,0 +1,60 @@
+Understanding that identity governs access isn't enough. You also need to understand how an identity proves who it's 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.
+
+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.

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.
+
+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.

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.
+
+Understanding how identity governs AI access is the foundation for designing secure AI workloads. Every subsequent decision about access, roles, conditions, and enforcement builds on this layer.

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

@@ -0,0 +1,54 @@
+Identity determines who can access AI services. The next step is understanding where that access is enforced.
+
+Azure separates access into two distinct layers: the **management plane** and the **data plane**. Each plane controls a different category of actions, and each introduces different security risks.
+
+Understanding the distinction between these planes is essential for designing least-privilege access and avoiding misconfiguration.
+
+## Management plane access
+
+The management plane governs configuration and administrative operations. It controls how AI resources are created, modified, and managed.
+
+Examples of management plane actions include:
+
+- Creating or deleting an Azure AI resource
+- Deploying or updating a model
+- Changing network configuration
+- Assigning role-based access control permissions
+
+Management plane access is enforced through Azure role-based access control. Permissions are typically assigned at the subscription, resource group, or resource level.
+
+If a user or application has excessive management plane permissions, they can alter how an AI system is deployed or secured. This can introduce risk even if runtime access is tightly controlled.
+
+## Data plane access
+
+The data plane governs runtime interaction with the AI service. It controls how identities interact with deployed models and associated data.
+
+Examples of data plane actions include:
+
+- Submitting prompts to a model endpoint
+- Retrieving model responses
+- Accessing training or grounding data
+- Using embeddings or inference APIs
+
+Data plane access determines who can use the model and how they can interact with it.
+
+A common mistake is assuming that restricting management access is enough. An identity with broad data plane access can still expose sensitive data, misuse models, or operate outside intended boundaries.
+
+## Why the distinction matters
+
+Management plane and data plane permissions are evaluated independently. An identity might have access in one plane but not the other.
+
+This separation affects:
+
+- How you design role assignments
+- How you apply least privilege
+- How you analyze misconfigurations
+- How you interpret security alerts
+
+When investigating an AI security issue, one of the first questions should be:
+
+Was this action performed through the management plane or the data plane?
+
+That distinction shapes both risk assessment and remediation.
+
+Understanding these two planes prepares you to design access intentionally rather than granting broad permissions that span configuration and runtime activity.

learn-pr/wwl-sci/entra-ai-understand/includes/management-data-plane-ai-workloads.md

@@ -0,0 +1,60 @@
+Authentication proves identity. Authorization determines what that identity can do.
+
+In Azure environments, authorization is enforced through role-based access control. Role assignments define which actions an identity can perform and where those permissions apply.
+
+When securing AI workloads in Microsoft Foundry, role design directly affects risk exposure and blast radius.
+
+## Role-based access control in Azure
+
+Azure uses role-based access control, or RBAC (role-based access control), to grant permissions to identities. Roles contain a defined set of allowed actions. When you assign a role to an identity, you grant that identity the ability to perform those actions within a specific scope.
+
+RBAC applies to both management plane and data plane operations, though the permission models differ.
+
+Management plane permissions control administrative operations such as deploying models, modifying configuration, or assigning additional roles.
+
+Data plane permissions control runtime access to AI endpoints and associated data.
+
+Understanding which permissions apply to which plane is critical when designing access boundaries.
+
+## Scope hierarchy
+
+Every role assignment includes a scope. Scope defines where the role applies.
+
+Azure uses a hierarchical model:
+
+- Subscription
+- Resource group
+- Individual resource, such as an AI endpoint
+
+Permissions assigned at a higher scope apply to all child resources beneath that scope.
+
+For example, assigning a contributor role at the subscription level grants broad control across all resource groups and resources within that subscription. Assigning a role at the resource level limits that access to a specific AI resource.
+
+Scope selection directly affects blast radius. The broader the scope, the greater the potential impact if that identity is compromised.
+
+Designing for least privilege requires careful alignment between role permissions and scope.
+
+## Built-in and custom roles
+
+Azure provides built-in roles that cover common administrative and operational scenarios. These roles simplify configuration but might grant more permissions than necessary in tightly controlled environments.
+
+Custom roles allow you to define a specific set of permitted actions. They're useful when built-in roles exceed the level of access required.
+
+Choosing between built-in and custom roles depends on the balance between operational simplicity and precision. In AI environments where data sensitivity is high, tighter control might be appropriate.
+
+Regardless of role type, permissions should align to defined responsibilities and avoid unnecessary privilege.
+
+## Designing role assignments intentionally
+
+Role assignments should never be an afterthought.
+
+When evaluating access to AI workloads, consider:
+
+- Which identity is performing the action
+- Which plane the action affects
+- Which scope is appropriate
+- Whether the role grants more access than required
+
+Poorly designed role assignments can undermine even strong authentication controls. A correctly issued token still enables misuse if the associated permissions are too broad.
+
+Effective AI security depends on aligning identity, role, and scope in a deliberate way.