TL;DR
Azure security best practices start with identity, not the network, as the real control boundary. Enforce multi-factor authentication and least-privilege access through Azure RBAC and Privileged Identity Management first. Encrypt data at rest and in transit, and manage every key and secret through Azure Key Vault instead of application code. Segment networks with Network Security Groups and Azure Firewall, and keep sensitive services off the public internet using private endpoints. Turn on Microsoft Defender for Cloud, Microsoft Sentinel, and Azure Policy so security becomes a continuously monitored operating model, not a one-time setup. Enterprises running Azure OpenAI or AI agents need the same identity, access, and audit controls extended to those workloads, not a separate security model.
Key Takeaways Identity is the real perimeter in Azure; MFA, least-privilege RBAC, and Privileged Identity Management matter more than any single network control. Azure’s shared responsibility model means Microsoft secures the platform, but customers own identity, data, configuration, and application security. Data protection requires encryption at rest and in transit plus centralized key management in Azure Key Vault, not default settings alone. Microsoft Defender for Cloud, Microsoft Sentinel, and Azure Policy turn security from a one-time setup into a continuously monitored operating model. Compliance frameworks like ISO 27001, SOC 2, and NIST map cleanly onto Azure controls when governance is designed in from the start, not bolted on later. Kanerika, a Microsoft Solutions Partner for Data & AI, has helped a leading bank design a governed Microsoft Purview program that gave it centralized visibility into where sensitive data lived and who could access it. The Attack That Never Needed a Zero-Day Identity-based attacks against enterprise cloud accounts rose 32 percent in the first half of 2025 alone, according to Microsoft’s 2025 Digital Defense Report . More than 97 percent of them were password attacks, not sophisticated exploits.
None of that required a zero-day vulnerability or a gap in Azure’s own infrastructure. It required one over-permissioned account, one missing MFA prompt, one secret sitting in a config file. Microsoft’s own research found that phishing-resistant MFA alone can stop over 99 percent of these attacks.
That gap between what Azure can secure and what most tenants actually configure is where this guide lives. It walks through the identity, network, data, workload, monitoring, governance, and AI controls that turn a default Azure subscription into a defensible enterprise environment. It also covers the compliance mapping and delivery model that make those controls stick.
What Azure Security Actually Means for Enterprises Azure security is not a single setting or a one-time deployment checklist. It is a continuous operating model. It spans who can access what, how workloads talk to each other, how data is protected, and how quickly a misconfiguration gets caught. Microsoft’s own Well-Architected Framework security pillar frames this the same way, as an ongoing discipline layered across every decision rather than a checkbox applied once at deployment.
Most enterprises adopting Azure already run mixed estates, data platforms, AI workloads, and hybrid connections back to on-premises systems. Every one of those surfaces needs its own controls. None of them are secure by default just because they run on Azure’s infrastructure.
Enterprises weighing Azure against AWS or Google Cloud often assume security posture is roughly interchangeable across providers. In reality, the controls differ enough in naming and default behavior that a team moving between clouds without adjusting its playbook usually ends up under-protected somewhere.
The Shared Responsibility Model, in Practice Microsoft secures the physical data centers, the hypervisor, and the underlying network fabric. However, everything a customer puts on top of that, identities, configurations, applications, and data, stays the customer’s job.
Where that line falls shifts by service model. The table below breaks down who owns what across infrastructure, platform, and software services.
Layer IaaS (Virtual Machines) PaaS (App Service, Azure SQL) SaaS (Microsoft 365, Dynamics) Physical datacenter, network fabric Microsoft Microsoft Microsoft Operating system and runtime Customer Microsoft Microsoft Network controls, NSGs, firewalls Customer Customer Shared Identity, access, and permissions Customer Customer Customer Applications and configuration Customer Customer Customer (config only) Data classification and protection Customer Customer Customer
Identity and data protection stay with the customer across every service model. That is exactly why the sections below start with identity rather than infrastructure.
Why Identity Replaced the Network Perimeter Enterprise workloads no longer sit behind one firewall. Instead, employees connect from home networks, contractors use personal devices, and AI agents call Azure APIs on their own schedule.
Microsoft’s own Azure security best practices and patterns documentation groups its guidance around identity, data, networking, and operations, in that order. Identity comes first because it is the boundary that actually travels with the user or the workload, not a fixed location on a network diagram.
Kanerika Service
Azure Cloud Security Assessment
Kanerika is a Microsoft Solutions Partner for Data & AI that benchmarks Azure environments against the Microsoft Cloud Security Benchmark and maps every gap to the compliance framework that matters to you.
Explore Azure Security Services Build Identity Security Around Least Privilege, Not Convenience Most Azure breaches Kanerika’s teams review trace back to permissions, not exploits. Typically, an account had more access than its job required, and nobody noticed until something went wrong. The sections below cover each individual control; Kanerika’s guide to Azure identity management walks through how they fit together as one governed access model.
Enforce Multi-Factor Authentication Everywhere MFA is the single most effective control in this entire guide. Require it for every account, not just administrators. Prioritize phishing-resistant methods like FIDO2 security keys or certificate-based authentication over SMS codes.
Conditional Access policies in Microsoft Entra ID let you require MFA based on risk signals rather than blanket rules. For example, a login from a known device on a corporate network can skip a redundant prompt, while a login from an unfamiliar country triggers a hard stop.
Apply Azure RBAC With Scoped, Not Broad, Permissions The most common mistake enterprises make is granting Owner or Contributor at the subscription level because it is faster than scoping access properly. As a result, that single decision turns every compromised account into a subscription-wide incident.
Scope roles to the resource group or resource level whenever possible. For instance, a developer who needs to deploy to one resource group should get Contributor on that resource group, not Owner on the subscription that resource group lives in.
Use Privileged Identity Management for Just-in-Time Access Standing administrative access is a liability, even when it is correctly scoped. Instead, Microsoft Entra Privileged Identity Management converts permanent admin roles into eligible roles that require activation, approval, and a time limit.
PIM activation logs also give security teams a real audit trail of who elevated privileges, when, and why, which matters as much for compliance evidence as it does for incident response. That same audit trail is the first thing a team investigating insider risk asks for, since most insider incidents involve an account that technically had legitimate access.
Retire Standing Credentials With Managed Identities Application secrets embedded in code or configuration files are one of the most preventable causes of breach in any cloud environment. Fortunately, Azure Managed Identity eliminates that risk by letting a resource authenticate to other Azure services without any credential a developer has to manage.
Pair managed identities with Azure Key Vault for anything that genuinely needs a secret, API keys for third-party services, connection strings, certificates, so nothing sensitive ever lives in source control.
Design Azure Network Security With Zero Trust Segmentation Network controls in Azure work best as a second layer behind identity, not a replacement for it. The goal is to make lateral movement difficult even after a single account or workload is compromised.
Default-Deny Network Security Groups Network Security Groups filter traffic at the subnet and network interface level. Therefore, start every NSG from a default-deny posture and add explicit allow rules only for traffic you can name a business reason for.
Review NSG rules on a set schedule, not just at deployment. Otherwise, rules added for a one-time troubleshooting session have a way of staying open indefinitely if nobody owns cleaning them up.
Centralize Traffic Control With Azure Firewall Azure Firewall gives enterprises a single, centrally managed point for filtering traffic across multiple virtual networks and subscriptions, with built-in threat intelligence that blocks traffic to known-malicious IP addresses and domains automatically.
For enterprises running multiple landing zones, routing egress traffic through one hub firewall is far easier to audit than managing NSG rules independently across dozens of spokes. Enterprises actively controlling cloud spend as part of an Azure cost optimization program should also check firewall SKU sizing, since over-provisioned firewall throughput is a common source of avoidable spend.
Keep Sensitive Services Off the Public Internet With Private Endpoints Azure Storage, Azure SQL, Key Vault, and Azure AI services all support private endpoints. Specifically, these assign the service a private IP address inside your virtual network instead of a publicly routable one.
A resource with no public endpoint cannot be found by internet scanning tools looking for exposed storage accounts, which remains one of the most common ways enterprise data ends up in a breach disclosure.
Add a Web Application Firewall for Internet-Facing Apps Any application that does need to be internet-facing should sit behind Azure Web Application Firewall. WAF policies block SQL injection, cross-site scripting, and known bot patterns before they ever reach application code.
Protect Data at Rest, in Transit, and in Use Azure encrypts most data by default, but default encryption is not the same as a governed data protection program. Consequently, enterprises still need to manage keys, classify sensitive data, and verify encryption is actually enforced rather than assumed.
Encrypt Everything by Default, Verify It Explicitly Storage Service Encryption protects Azure Storage at rest. Transparent Data Encryption protects Azure SQL databases. Azure Disk Encryption protects VM disks. All three are enabled by default on new resources, but legacy resources migrated from other platforms sometimes are not.
Enforce TLS for every connection in transit, and use Azure Policy to flag or block any resource that allows unencrypted HTTP traffic or outdated TLS versions. Enterprises still running Azure SQL Database alongside newer platform services should confirm TDE is active on every instance, since databases migrated years ago sometimes predate the default-on policy.
Centralize Secrets and Keys in Azure Key Vault Azure Key Vault should be the only place application secrets, connection strings, and encryption keys live. For regulated workloads, Key Vault Managed HSM adds FIPS 140-2 Level 3 validated hardware protection. It also lets the enterprise hold its own customer-managed keys instead of relying solely on Microsoft-managed keys.
Classify and Govern Data With Microsoft Purview Encryption protects data from unauthorized access. However, it does nothing to tell you where sensitive data actually lives across dozens of storage accounts, databases, and file shares. That is the gap Microsoft Purview closes.
Case Study
Centralized Data Governance for a Leading Bank
Kanerika designed and implemented a Microsoft Purview governance program that gave a leading bank centralized visibility into where sensitive data lived, who could access it, and how classification was enforced.
Read the Case Study → Purview scans Azure data estates, applies sensitivity labels automatically based on pattern matching, and gives compliance teams a real inventory of where regulated data sits instead of a best guess from three years ago. Kanerika’s own guide to Microsoft Purview covers setup and licensing in more depth for teams starting from zero.
Secure the Workloads Running on Azure Identity, network, and data controls only work if the compute layer underneath them is also hardened. After all, a patched, correctly configured VM or container is what actually enforces every policy layered on top of it.
Workload security also extends to how workloads get onto Azure in the first place. Enterprises mid-way through an Azure to Microsoft Fabric migration or an AWS to Azure migration often inherit whatever security posture the source platform had, good or bad, unless someone deliberately re-baselines it during the move.
Virtual Machine Hardening Restrict direct internet access to management ports like RDP and SSH, and use Azure Bastion or just-in-time VM access instead of leaving port 3389 open to the internet. In addition, keep automatic patching enabled, and deploy Microsoft Defender for Endpoint on every VM that handles sensitive workloads.
Container and Kubernetes Security in AKS Scan container images for vulnerabilities before deployment, not after. Azure Kubernetes Service supports Microsoft Entra Workload ID, which replaces static secrets inside pods with short-lived, automatically rotated tokens.
Enable Azure Policy for Kubernetes to enforce pod security standards cluster-wide. Use network policies to restrict which pods can talk to which, not just which nodes can talk to the internet. Isolate multi-tenant clusters with namespaces and resource quotas, never shared trust boundaries. Azure App Service and PaaS Security Enforce HTTPS-only traffic and require client certificates for service-to-service calls where appropriate. Use deployment slots with staging environments isolated from production credentials. App Service authentication should route through Microsoft Entra ID rather than a custom login system whenever the application supports it.
Teams comparing Azure Databricks against Snowflake for a data platform workload should factor security operating model into that decision too. Each platform inherits different pieces of Azure’s identity and network controls, and that changes how much configuration your team owns directly.
Turn On Continuous Monitoring and Threat Detection Every control covered so far is a point-in-time configuration. Meanwhile, monitoring is what tells you when that configuration drifts, gets bypassed, or stops being enough.
Microsoft Defender for Cloud as the Posture Baseline Microsoft Defender for Cloud continuously assesses your environment against the Microsoft Cloud Security Benchmark. It surfaces a secure score with specific, prioritized recommendations. Treat that score as an operating metric, reviewed monthly, not a one-time report generated for an audit.
Microsoft Sentinel for SIEM and Incident Response Microsoft Sentinel aggregates signals across Azure, Microsoft 365, and third-party tools into one place. It then applies analytics rules to surface genuine threats instead of raw log noise. Automated playbooks can isolate a compromised account or disable a leaked credential within minutes of detection, instead of waiting for a human to notice an alert.
Azure Monitor and Diagnostic Logging Enable diagnostic logging on every resource that supports it, not just the ones an auditor is likely to ask about. As a result, activity logs, authentication logs, and application logs stop being noise. Instead, they turn “we think something happened” into “here is exactly what happened and when.” Teams that already track platform health through Azure monitoring tools should extend the same dashboards to cover security signals instead of running a separate, disconnected monitoring stack.
Watch on YouTube
Elevating Enterprise Productivity and Security with Copilot and Purview
Kanerika walks through how Microsoft Purview and Copilot work together to strengthen enterprise data security and productivity, directly relevant to the governance controls in this guide.
Monitoring is also the layer that supports recovery, not just detection. A tested Azure disaster recovery plan depends on the same diagnostic logs and alerting to confirm a failover actually worked, not just that it was triggered.
Enforce Governance With Azure Policy and Landing Zones Controls that depend on every engineer remembering to configure them correctly will eventually fail. Instead, governance is what makes secure configuration the default path rather than a manual step someone can skip.
Azure Landing Zones as the Secure Foundation An Azure landing zone defines the management group hierarchy, subscription structure, identity baseline, and networking model before a single workload gets deployed into it. Enterprises that skip this step end up retrofitting governance onto a sprawling, inconsistent environment years later, which is a far more expensive project than doing it first.
Teams provisioning landing zones through infrastructure as code should review Kanerika’s guide to Azure Bicep for patterns that keep security baselines version-controlled and repeatable. Instead, this beats manually clicking through the portal for every new subscription. Teams standardized on multi-cloud tooling instead can apply the same version-controlled, repeatable approach with Azure Terraform .
Azure Policy for Automated Guardrails Azure Policy can prevent a storage account from ever being created with public access enabled. It can also block deployments to unapproved regions and flag any resource missing required tags. Assign policies at the management group level so new subscriptions inherit guardrails automatically instead of relying on a checklist someone has to remember to run. Enterprises tracking spend under a Microsoft Azure Consumption Commitment often find governance guardrails double as cost guardrails, since ungoverned resource sprawl drives both risk and unplanned spend at the same time.
Mapping Azure Controls to ISO 27001, SOC 2, and NIST Compliance frameworks are not a separate workstream from security controls. In fact, most of what auditors ask for maps directly onto controls this guide already covers, once someone documents the mapping.
Framework What It Requires Mapped Azure Controls ISO 27001 Documented information security management system, risk treatment Azure Policy baselines, Purview classification, Defender for Cloud secure score SOC 2 Access controls, monitoring, change management, incident response RBAC and PIM audit logs, Sentinel incident workflows, Azure Monitor logging NIST CSF Identify, protect, detect, respond, recover functions Landing zone governance, encryption and Key Vault, Defender and Sentinel, backup and DR HIPAA PHI access logging, encryption, business associate controls Private endpoints, Purview sensitivity labels, Key Vault Managed HSM
Kanerika holds ISO 27001, ISO 27701, and SOC 2 Type II certifications itself, so this mapping reflects controls Kanerika’s own teams operate under, not a theoretical exercise.
Checklist
Microsoft Azure Checklist
A practical, print-ready checklist covering identity, network, data, and monitoring configuration for teams standing up or auditing an Azure environment.
Get the Checklist → Securing Azure AI and Agentic Workloads Every top-ranking guide on this topic was written before enterprises put real production traffic through Azure OpenAI and autonomous AI agents. That gap matters, because those workloads need every control above extended to a new attack surface, not a separate security model bolted on afterward.
Controlling Access to Azure OpenAI and AI Resources Authenticate every call to Azure OpenAI through Microsoft Entra ID rather than a shared API key passed around in application config. Scope RBAC roles narrowly, a service that only needs to call one deployed model should not hold Contributor on the entire Cognitive Services resource. Kanerika’s AI governance services apply this same scoping discipline to every model and agent an enterprise puts into production, not just the ones a security review happens to catch.
Preventing Data Leakage From AI Applications AI applications create two new leakage paths traditional apps do not have. In particular, sensitive data can enter a prompt, or a model response can surface information the requesting user should not see. Both need the same Purview classification and DLP policies applied to any other data store, extended to cover prompt logs and retrieval sources.
A model that retrieves ungoverned or inconsistent source data introduces a related risk worth planning for separately. Kanerika’s breakdown of LLM hallucination on enterprise data covers why this happens and what actually fixes it, which matters as much for AI security as prompt-level access controls do.
Governing Autonomous AI Agents on Azure An AI agent that can take actions, updating records, sending communications, triggering workflows, needs its own identity and its own scoped permissions. It also needs a full audit trail of every action it takes, the same as a human employee would. Human approval workflows for higher-risk actions are not optional caution here, they are the control that keeps an agent’s mistake from becoming an incident. This is the same governance discipline behind Kanerika’s agentic AI services and Klara, Kanerika’s document intelligence and compliance agent, which enforces a playbook and keeps a human in the loop rather than acting on standing, unscoped permissions.
Enterprises unsure how ready their environment is for any of this can run Kanerika’s AI Maturity Assessment before committing to a full AI security program. In short, it scores identity, data, and governance readiness in roughly fifteen minutes.
The Azure Security Best Practices Checklist Use this as a working checklist, not a one-time audit. Review it quarterly as your Azure estate grows. Kanerika’s full Microsoft Azure checklist covers additional configuration items beyond security for teams standing up a new environment end to end.
Identity
MFA enforced for every account, with phishing-resistant methods for privileged roles RBAC scoped to resource group or resource level, not subscription-wide PIM configured for all standing administrative roles Managed identities used instead of embedded application credentials Network
NSGs reviewed on a set schedule, default-deny posture confirmed Azure Firewall centralizing egress traffic across landing zones Private endpoints enabled for storage, SQL, and Key Vault WAF deployed in front of every internet-facing application Data and Workloads
Encryption at rest and in transit verified, not assumed, on legacy resources Secrets and keys centralized in Azure Key Vault Data classified and labeled through Microsoft Purview VM patching, container scanning, and App Service HTTPS-only confirmed Monitoring and Governance
Defender for Cloud secure score reviewed monthly Sentinel analytics rules and automated playbooks configured Azure Policy guardrails assigned at the management group level Compliance mapping documented against ISO 27001, SOC 2, or NIST as required Common Azure Security Mistakes That Undo Good Controls Kanerika’s teams see the same handful of mistakes repeat across enterprise Azure environments, usually not because the controls above are unknown, but because they get skipped under deadline pressure.
On-Demand Webinar
Data Security Risks in AI: Microsoft Purview for Data and AI
An on-demand session on managing data security risk as enterprises adopt AI on Microsoft’s platform, covering the same Purview-based controls this guide applies to Azure AI workloads.
Watch the Webinar → Treating security as an infrastructure-only problem. Identity, applications, data, and AI workloads all need their own controls, not just the network.Granting broad permissions to move faster. Every subscription-wide Owner role granted for convenience becomes a governance debt someone has to pay down later.Porting on-premises habits to the cloud. Flat networks, VPN-only access models, and manual change approval processes do not scale to a dynamic cloud environment.Deploying AI without governance. Unmanaged Copilot connectors and AI agents with standing, broad permissions are the fastest-growing source of new exposure Kanerika sees in 2026 engagements.An AI auditing framework catches most of these mistakes before they reach production, since it forces the same permission and data-access review this guide recommends for every other Azure workload.
How Enterprises Roll Out These Controls Without Stalling the Business Reading a controls list is easy. By contrast, rolling all of it out across a live enterprise environment without breaking production workloads or burning out the security team is the actual challenge.
Step 1: Assess the Current Security Posture Run Defender for Cloud’s secure score, review RBAC assignments for scope creep, and identify which compliance frameworks the business actually needs to satisfy. Most enterprises are surprised by how much of this Azure already surfaces for free once someone actually looks.
Step 2: Design the Target Architecture Define the landing zone, identity baseline, and network segmentation model before touching existing workloads. Trying to redesign governance and migrate workloads in the same motion is how both efforts stall.
Step 3: Implement in Priority Order, Not Everything at Once MFA and RBAC scoping deliver the highest risk reduction per hour of work, so start there. Network segmentation, Key Vault consolidation, and Defender and Sentinel rollout follow once identity is genuinely under control.
Step 4: Monitor, Measure, and Keep Governance Current Security posture degrades the moment nobody is watching it. Therefore, recurring policy reviews, secure score tracking, and quarterly access reviews are what keep day-one controls from quietly eroding by day two hundred.
Talk to Kanerika
Not Sure Where Your Azure Environment Stands?
A short working session with Kanerika’s Azure security specialists turns this checklist into a scoped plan for your actual environment, identity model, and compliance obligations.
Schedule a Demo → How Kanerika Helps Enterprises Secure and Govern Azure Environments Kanerika is a Microsoft Solutions Partner for Data & AI with an Advanced Specialization in Data Warehouse Migration to Microsoft Azure and a Major Contender ranking in Everest Group’s Microsoft Azure Services PEAK Matrix Assessment 2026. Azure security work runs through the same four-stage delivery model across every engagement, assess, design, build and migrate, and govern.
The assessment stage benchmarks the current environment against the Microsoft Cloud Security Benchmark and Defender for Cloud’s secure score, then maps every gap to a named compliance framework the client actually needs to satisfy. The design stage defines the landing zone, identity baseline, and network segmentation model before any workload moves. This step also draws on the same data strategy consulting and data engineering disciplines Kanerika applies across every Azure engagement. In fact, it is the step most in-flight Azure environments skipped the first time around. Build and migrate work follows the same secure-by-design model Kanerika uses across its migration accelerator practice.
Governance is where Kanerika’s Microsoft Purview expertise does the most work. Kanerika’s kanGovern, kanComply, and kanGuard data governance services are all delivered on Purview, covering data classification, regulatory compliance mapping, and unauthorized access prevention as one connected program instead of three separate tools nobody maintains.
Listen on Spotify
How Do Fortune 500 Companies Actually Govern Their Data Migrations?
A leading bank engaged Kanerika to bring exactly this kind of structure to a fragmented data environment. Kanerika designed and implemented a Microsoft Purview governance program that gave the bank centralized visibility into where sensitive data lived, who could access it, and how classification policies were enforced across the estate, replacing manual, spreadsheet-driven governance with a system that scales as the bank’s Azure footprint grows.
Wrapping Up Azure gives enterprises every control this guide covers. However, it does not turn them on by default, and it does not scope them correctly on its own.
Start with identity, extend the same discipline to data, network, and workloads, then layer monitoring and governance on top so drift gets caught instead of discovered during an audit or a breach. AI workloads need that same rigor from day one, not as an afterthought once something goes wrong.
Frequently Asked Questions
What is the Azure shared responsibility model? Microsoft secures the physical infrastructure, hypervisor, and network fabric underneath Azure. Customers are responsible for identities, access policies, applications, data protection, and configuration on top of that, regardless of whether they run IaaS, PaaS, or SaaS services. The split shifts by service model, but identity and data protection always stay with the customer.
What are the most important Azure security best practices? Enforce multi-factor authentication and least-privilege RBAC first, since identity is the real control boundary in Azure. Encrypt data at rest and in transit, centralize secrets in Azure Key Vault, segment networks with NSGs and Azure Firewall, and turn on Microsoft Defender for Cloud and Microsoft Sentinel for continuous monitoring. Governance through Azure Policy and landing zones makes these controls stick as the environment grows.
Is Azure secure by default? Azure encrypts most data at rest and in transit by default and secures its own physical infrastructure, but that is not the same as a secure tenant. Identity, network segmentation, RBAC scoping, and monitoring all require deliberate configuration. A default Azure subscription is a secure starting point, not a finished security program.
What is the difference between Azure Policy and Azure RBAC? Azure RBAC controls who can do what within Azure, granting permissions like read, write, or delete on specific resources. Azure Policy controls what configurations are allowed to exist, blocking or flagging resources that violate a rule, such as a publicly accessible storage account. Most enterprises need both working together, not one instead of the other.
What is Microsoft Defender for Cloud and do I need it? Microsoft Defender for Cloud continuously assesses your Azure environment against the Microsoft Cloud Security Benchmark and produces a secure score with prioritized recommendations. Any enterprise running production workloads on Azure needs it, since it is the primary way to know your security posture is drifting before an incident reveals it.
How does Azure support SOC 2, ISO 27001, and NIST compliance? Azure controls map directly onto these frameworks once documented: Azure Policy baselines and Purview classification support ISO 27001’s risk treatment requirements, RBAC and Sentinel audit logs support SOC 2’s access and monitoring criteria, and landing zone governance plus Defender and Sentinel support NIST CSF’s identify, protect, detect, and respond functions. The mapping has to be built deliberately, since Azure does not generate compliance evidence on its own.
How can enterprises secure Azure AI workloads and AI agents? Authenticate every call to Azure OpenAI through Microsoft Entra ID instead of shared API keys, and scope RBAC roles narrowly to each specific model or agent. Apply Purview classification and DLP policies to prompts and retrieval sources the same way you would any other data store. AI agents that can take actions need their own identity, scoped permissions, and a full audit trail, with human approval required for higher-risk actions.
How do Network Security Groups differ from Azure Firewall? Network Security Groups filter traffic at the subnet and network interface level within a single virtual network, working best as distributed, resource-level rules. Azure Firewall is a centrally managed service that filters traffic across multiple virtual networks and subscriptions, adding threat intelligence based blocking. Most enterprise architectures use NSGs for local segmentation and Azure Firewall for centralized egress control.
