5.2 Application, Data, and Authentication Security for AI

Microsoft's skills guide groups this bullet as identify security considerations for AI systems, including application security, data security, and authentication requirements. Read that as a steering-committee agenda, not a penetration-test script. You will not configure subnets on the exam. You will be expected to know which leader decisions close the biggest holes: identity, least privilege, encryption, network isolation, secrets, logging, who can call the model, and data residency.

Authentication and identity: Entra ID first

Microsoft Entra ID (formerly Azure Active Directory) is the identity platform for users, groups, workload identities, and — for agents — Microsoft Entra Agent ID, which Microsoft positions as a directory of agent identities created across Copilot Studio and Foundry. For Foundry, role-based access control (RBAC) applies when you authenticate with Entra ID. If you instead use a key, Microsoft's Foundry RBAC documentation is blunt: the key grants full access without role restrictions. That is why transformation leaders should prefer Entra sign-in plus managed identities for applications talking to Azure services. A managed identity is an automatically managed Entra identity. It authenticates to Storage, Key Vault, and model endpoints without a password sitting in a slide deck.

Least privilege means each human and each workload gets the smallest role that still does the job, at the smallest scope. Foundry scopes include the top-level Foundry resource, a project, and even an individual agent endpoint. Built-in Foundry roles (recently renamed from Azure AI User / Owner names; role IDs unchanged) include:

Classic Azure Owner, Contributor, and Reader still matter on the control plane (create resources, deploy models). They do not automatically include chatting with agents. A subscription Owner who can delete the Foundry account still should not be your production chat identity. Do not assign leftover Cognitive Services-prefixed roles for Foundry project work; Microsoft says those roles target AI Services resources directly and do not apply to Foundry scenarios. Conditional Access (require compliant device, block risky sign-ins) belongs on the human path to Copilot and to the Foundry portal.

Application security: who can call the model

Application security for AI is mostly about the front door. The model is a powerful API. If anyone on the internet can hit it with a stolen key, you have an unmetered, unaccountable completion service sitting on your tenant data. Leader controls:

• Identity of the caller — user, app, or agent; no anonymous public endpoint for internal data.
• Tool and plugin allowlists — agents should not be able to invoke every connector "just in case."
• Rate limits and a gateway — Azure API Management is commonly placed in front of hosted language models for authentication, load balancing, and token monitoring.
• Content safety — input and output filters, including jailbreak detection, configured per deployment.
• Human approval for high-risk tool calls (refunds, vendor payments, mailbox-wide send).

A legal director should ask: if this agent is tricked, what is the blast radius? If the answer is "it can read every SharePoint site and post to any Teams channel," shrink the tools before you grow the user count.

Data security: encryption, secrets, residency, oversharing

Data security covers data at rest, in transit, and in use in prompts. Foundry architecture documentation states that Azure encrypts data at rest and in transit by default with Microsoft-managed keys using FIPS 140-2 compliant 256-bit AES. Customer-managed keys (CMK) in Azure Key Vault are available when your policy requires you to control the key; Key Vault must be in the same region, with soft delete and purge protection, and the Foundry managed identity needs crypto permissions. By default Foundry stores API-key connection secrets in a managed Key Vault; regulated teams often bring your own Key Vault so secret governance matches the rest of the estate.

Data residency has two layers leaders confuse. At rest, Foundry stores data in the designated Azure geography. Inferencing (prompts and completions) follows deployment type:

• Global types may process inference in any Azure region.
• Data zone types keep processing inside a Microsoft-specified zone (for example United States, European Union, or Asia Pacific).
• Standard / regional types process in the deployment region.
• Developer deployments carry no data-residency guarantee and are not a production residency strategy.

If legal requires EU processing, Global Standard is the wrong checkbox even if blobs stay in Europe. Foundry does not automatically fail over across regions; multi-region availability is a separate architecture choice.

Secrets do not belong in prompts, notebooks emailed to vendors, or pipeline variables in chat. Logging is mandatory and dangerous at the same time: enable diagnostic settings to Azure Monitor / Log Analytics for requests, token usage, content-filter results, and errors — and decide whether prompt bodies are retained, for how long, and who may read them. Microsoft Purview Audit captures Copilot interactions; Defender for Cloud Apps watches unsanctioned SaaS AI. Oversharing controls (labels, DLP, DSPM for AI) sit on the data path into the model, not only on the storage account.

Network isolation

Network isolation segments traffic so models, storage, and Key Vault are not on the open internet. Microsoft describes private endpoints, managed virtual networks, and bring-your-own virtual network (BYO VNet) injection for agents. Enterprises use this to meet exfiltration and regulatory standards. The leader question is binary enough for AB-731: does this workload process data that must never traverse a public endpoint? If yes, private networking is part of the business case, not an optional developer preference.

Microsoft Foundry as identity, network, and billing boundary

Think of Microsoft Foundry (blueprint name; some Microsoft Learn pages still say Azure AI Foundry) as a top-level Azure resource where IT sets networking, encryption, model deployments, and monitoring. Projects are development boundaries that reuse those deployments without each team inventing a new security model. Connected resources — Storage, Key Vault, Azure AI Search — remain separate Azure resources with their own RBAC and firewalls. Resource-level metrics include token consumption, latency, and errors across projects; project-level metrics cover evaluations and agent activity. That is why Foundry is a billing and usage boundary as well as an identity and network boundary: the CFO sees tokens and capacity at the resource, while the CISO sees one place to attach private endpoints and diagnostic settings.

Scenario. A finance controller wants every department on its own Foundry "for agility." That multiplies keys, networks, and invoices. A better pattern is one governed Foundry resource (or a small number of residency-specific resources) with projects per team, Entra roles at project scope, and a single private-network design. Agility comes from project isolation, not from unmanaged accounts.

Decisions a transformation leader actually owns

• Entra ID plus managed identities, not shared keys, for any system that sees internal data.
• Foundry Agent Consumer for staff apps; Foundry User for builders; keep Owner-level roles scarce.
• CMK and BYO Key Vault when policy requires customer-controlled keys and secret custody.
• Deployment type chosen for processing location, not only for price.
• Private endpoints when public model access is unacceptable.
• Logs on, with a retention and access policy that legal can defend.