Azure AI Foundry Security: CISO Hardening Guide 2026

Azure AI Foundry security is one of the most frequently misunderstood areas in enterprise AI deployments today. Many security teams assume that existing Azure OpenAI Service controls carry over to Foundry, but the two platforms have fundamentally different architectures, permission models, and attack surfaces. This guide gives CISOs a clear-eyed view of what changed, what is at risk, and how to harden Foundry deployments before incidents force that conversation.

You will learn how Azure AI Foundry differs from Azure AI Studio and Azure OpenAI Service from a security standpoint, what CVE-2026-35435 revealed about Foundry's agent isolation model, how the July 2026 Agent 365 transition broke existing blocking rules for many tenants, and which technical controls close the most critical gaps.

Azure AI Foundry vs. Azure OpenAI Service: The Security Architecture Gap

Microsoft renamed Azure AI Studio to Azure AI Foundry in late 2024, but the rebrand understates the scope of what changed. Azure AI Foundry is not a cosmetic update to Azure OpenAI Service. It is a unified platform that wraps Azure OpenAI as one component alongside a model catalog with over 200 models from third-party providers, Prompt Flow pipeline orchestration, Azure AI Agent Service for non-human identity management, fine-tuning infrastructure, and the Foundry Control Plane that governs hub and project isolation.

Each of these components introduces attack surface that does not exist in a standalone Azure OpenAI Service deployment:

Model Catalog (200+ models): The catalog includes open-source models from multiple providers, fine-tuned variants, and models hosted by Microsoft's compute infrastructure. Microsoft applies backdoor detection and model integrity checks before listing, but the review process cannot guarantee safety for every update cycle. An adversary who compromises a catalog-listed model variant or publishes a model with a hidden trigger can reach enterprise tenants that adopt the model without additional vetting. This is a supply chain risk distinct from using a Microsoft-managed GPT-4o endpoint.

Prompt Flow pipelines: Prompt Flow allows enterprises to build multi-step LLM orchestration chains, connecting models to tools, APIs, and data sources. Each connection is a potential injection point. An attacker who controls one input to a Prompt Flow node can attempt to redirect the entire chain's behavior, similar to how Server-Side Request Forgery (SSRF) works in traditional web applications but operating at the model context layer. In practice, Prompt Flow pipelines that consume external data (SharePoint, web retrieval, customer inputs) without input sanitization are vulnerable to indirect prompt injection.

Azure AI Agent Service: This introduces non-human identities with managed identity assignments and Azure RBAC permissions. Unlike a human user who logs in with MFA, a Foundry agent runs continuously with assigned permissions. An over-privileged agent or one whose managed identity can be escalated represents a persistent threat: attackers who compromise an agent's execution context inherit its permissions without triggering identity-based alerts.

Foundry Control Plane: The hub and project isolation model governs which teams can access which models and data. Misconfigured hub-level permissions can allow cross-team data exfiltration through shared resources, particularly when multiple projects share the same storage account or key vault without sufficient scoping.

CVE-2026-35435 and the July 2026 Agent 365 Transition

Two events in 2026 changed the Azure AI Foundry security landscape for every enterprise tenant, and many security teams missed at least one of them.

CVE-2026-35435 was disclosed on May 7, 2026. The vulnerability is an improper access control flaw in Azure AI Foundry M365 published agents. An unauthenticated attacker with network access can exploit it to escalate privileges over published agent workflows and connectors, reaching resources the agent was granted permission to access. CVSS scores reported range from 8.6 to 10.0 depending on the source, with Microsoft's own assessment flagging exploitation as more likely. At the time of disclosure, Microsoft confirmed the vulnerability had already been exploited in the wild.

The immediate implication for security teams: any organization that has published Foundry agents to Microsoft 365 without enforcing strict network boundaries and without applying the May 2026 mitigations is at risk. The fix involves restricting agent publication permissions, applying the Agent 365 policy controls described below, and auditing which agents have already been published and what managed identity permissions they hold.

The July 1, 2026 Agent 365 Transition compounded the risk for organizations that had not been tracking Microsoft's licensing changes. Prior to July 1, 2026, AI agent discovery and security posture management for Foundry agents were covered under Defender CSPM. Effective July 1, 2026, this coverage moved to a Microsoft Agent 365 license. For tenants that had configured blocking rules under the previous experience: those rules stopped enforcing on July 1. Tenants had to manually reconfigure equivalent rules under the new Settings > Security for AI > Policies & rules path in Defender XDR.

The new AgentsInfo table in Advanced Hunting provides a unified schema for agent inventory and governance across Copilot Studio, Microsoft Foundry, Microsoft 365 Copilot, third-party agents, and endpoint-discovered agents. For security teams who missed the transition, running a query against AgentsInfo is the fastest way to understand current agent exposure.

AgentsInfo
| where AgentType == "MicrosoftFoundry"
| project AgentName, PublishedStatus, ManagedIdentityObjectId, LastSeen
| order by LastSeen desc

The Four Primary Attack Vectors in Azure AI Foundry

Understanding the attack surface in concrete terms helps security teams prioritize controls. In Azure AI Foundry deployments, four vectors account for the majority of exploitable risk.

Prompt injection through model catalog and Prompt Flow inputs: Any Foundry pipeline that processes external or user-controlled input is potentially vulnerable to prompt injection. A common pattern in enterprise deployments is a Prompt Flow pipeline that retrieves documents from SharePoint or Azure AI Search and injects them into model context before responding to a user query. An attacker who can insert malicious text into those documents can redirect model behavior: exfiltrating conversation context, calling unauthorized tools, or manipulating the agent's output to deceive downstream systems or users.

Microsoft's prompt injection-based RCE research (May 2026) demonstrated that prompt injection combined with unsafe tool execution can reach host-level RCE in agent frameworks. Azure AI Foundry pipelines that call external tools or execute code (Python tool nodes in Prompt Flow, for example) face this risk directly.

Supply chain risk in the model catalog: Microsoft applies security scanning before catalog listing, but enterprises that pull third-party or open-source models from the catalog should not treat this as a complete clearance. The research literature on LLM backdoor attacks shows that fewer than 100 poisoned training samples can embed a hidden trigger in a fine-tuned model's weights without affecting performance on standard benchmarks. A model that passes Microsoft's integrity checks may still carry a trigger that activates only on specific inputs in a production environment. The risk is highest for enterprises that adopt fine-tuned variants of base models from the catalog without additional pre-deployment vetting.

Managed identity lateral movement via Azure AI Agent Service: Each Foundry agent is assigned a managed identity backed by Entra ID. If an agent is granted permissions beyond what its specific task requires, and an attacker compromises the agent's execution (through prompt injection, for example), they inherit the agent's identity scope. A common misconfiguration is assigning the Contributor role at the resource group level rather than scoping managed identity permissions to the minimum required resources. In a compromised state, an over-privileged agent managed identity can access Azure Key Vault secrets, read from connected storage accounts, or call other Azure APIs without triggering standard identity alerts.

Foundry Control Plane misconfigurations and cross-project data exposure: The hub-and-project model in Azure AI Foundry allows organizations to group related AI projects under a shared hub that manages common resources. When shared storage accounts or key vaults are attached at the hub level without per-project access scoping, a team with legitimate access to one project can potentially reach data from another project through the shared resource. This is particularly relevant in multi-tenant or multi-business-unit deployments where different teams use the same Foundry hub for cost efficiency.

Network Isolation and Identity Hardening

The most impactful controls for Azure AI Foundry security involve network isolation and managed identity scoping. Foundry does not restrict public endpoints by default; this must be configured explicitly.

Private Endpoint deployment: Deploy Private Endpoints for every Foundry resource: the hub, storage accounts, Azure Key Vault, Azure AI Search, container registries, and any Azure OpenAI instances connected to Foundry. Microsoft Foundry supports both managed virtual networks (Microsoft-managed private IPs) and customer-managed VNets where the agent client is injected into a subnet you control. For regulated workloads, customer-managed VNets provide greater control over routing and DNS. The managed VNet option is simpler to configure but gives less visibility into network flows.

Azure Policy for public network access: Deploy Azure Policy with a Deny effect on Microsoft.MachineLearningServices/workspaces/publicNetworkAccess, Microsoft.CognitiveServices/accounts/publicNetworkAccess, and related resource types. Policy enforcement prevents teams from inadvertently creating publicly accessible Foundry resources. Apply this policy at the subscription or management group level, not just per resource.

Managed identity scoping: Assign each Foundry agent its own managed identity rather than sharing one across agents. Scope permissions using Azure RBAC at the resource level, not the resource group or subscription level. For agents that read from Azure AI Search, the Cognitive Services User role scoped to the specific Search instance is sufficient. Granting Contributor at the hub or resource group level gives the agent far more than it needs and expands blast radius if the agent is compromised.

Key Vault configuration: Configure Azure Key Vault with the Deny public network access setting and use Private Endpoints. Rotate secrets on a schedule and enable Key Vault diagnostic logging. Foundry agents that retrieve API keys at runtime from Key Vault should use managed identity authentication rather than connection string credentials stored in Prompt Flow configuration files.

Content filtering policies: Azure AI Foundry integrates Azure AI Content Safety content filtering for models served through Azure OpenAI. Configure content filtering policies at the hub level with settings appropriate for your use case. For customer-facing deployments, apply stricter thresholds. Document your content filtering policy settings as part of your EU AI Act technical documentation package.

Audit logging and retention: Enable diagnostic settings on all Foundry resources and route logs to a Log Analytics workspace or Azure Monitor. Key log categories include AuditLogs, RequestResponse (for model invocations), and GatewayApiLogs. Set retention to at least 90 days for incident response purposes. The AgentsInfo table in Defender XDR provides agent-level inventory; pair this with resource-level diagnostic logs for a complete audit trail.

Compliance Mapping: EU AI Act, NIST AI RMF, and ISO 42001

Azure AI Foundry's built-in controls satisfy some compliance requirements but leave significant gaps that enterprises must fill independently.

EU AI Act (August 2026 and beyond): GPAI (General Purpose AI) enforcement activated August 2, 2026. The May 2026 Digital Omnibus deferred Annex III high-risk system obligations to December 2, 2027. However, documentation and transparency obligations for GPAI models are active now. If your Foundry deployment uses a GPAI model (which includes the major foundation models in the catalog), you should already have technical documentation, training data transparency records, and an AI incident logging mechanism in place. Azure AI Foundry's audit logging supports the incident logging requirement, but you must configure it. The platform alone does not satisfy Article 13 (transparency) or Article 9 (risk management) obligations.

NIST AI RMF (Govern, Map, Measure, Manage): The NIST AI RMF is a voluntary framework, but it provides a structured basis for AI risk management that aligns well with enterprise security governance. The Govern function maps to your Foundry hub permissions, content filtering policies, and managed identity scoping decisions. The Map function requires documenting the specific models, pipelines, and agents in your Foundry deployment and their associated risks. The Measure function maps directly to using PyRIT-based red teaming (discussed below) to quantify attack success rates before production. The Manage function covers your incident response procedures for Foundry-related events. Azure AI Foundry does not automate NIST AI RMF compliance; it provides the technical controls that support it.

ISO 42001 and SOC 2: ISO 42001 certifies that your organization has the right management system for AI governance, including documented policies, risk assessments, and continual improvement processes. SOC 2 Type II assessments for AI systems should include Foundry's access controls, audit logging configuration, and change management procedures for model updates. Azure AI Foundry's role-based access controls and diagnostic logging directly support SOC 2 audit requirements, but the configuration evidence must be captured and maintained by your team.

A practical approach for resource-constrained teams: build a unified control library that maps each Azure AI Foundry configuration setting to its corresponding control in NIST AI RMF, ISO 42001, and EU AI Act. Evidence is collected once from Foundry's diagnostic logs and policy assignments, then mapped to all three frameworks. This avoids duplicated assessment effort as regulatory requirements evolve.

Microsoft's Responsible AI Standard documents Microsoft's own governance approach for Foundry models. It is a useful reference for understanding which controls Microsoft applies at the platform layer versus which controls remain the enterprise's responsibility.

Red-Teaming Azure AI Foundry Before Production

Red-teaming AI systems before production deployment is not optional for high-risk use cases, and Azure AI Foundry now includes native tooling to support it.

AI Red Teaming Agent with PyRIT: Microsoft integrated its open-source Python Risk Identification Tool (PyRIT) into Azure AI Foundry as the AI Red Teaming Agent. PyRIT generates adversarial probes targeting safety failures, calculates Attack Success Rate (ASR) across test scenarios, and produces structured reports. The red teaming agent supports both cloud-hosted Foundry models and local on-device models (currently in public preview for local models). For every Foundry model deployment, run a PyRIT-based evaluation before promotion to production.

Manual red-teaming for Prompt Flow pipelines: PyRIT targets model-level safety risks. Prompt Flow pipelines require manual red-teaming focused on injection vectors specific to your pipeline design. Test each external data source that feeds into model context. If your pipeline retrieves from Azure AI Search, inject adversarial documents into the search index and observe whether the model follows embedded instructions. If your pipeline accepts user input that reaches tool calls, attempt to redirect tool parameters to unauthorized targets.

Model catalog vetting: Before adopting any third-party or fine-tuned model from the Foundry catalog, apply your organization's model vetting procedure. At minimum: run behavioral red-teaming with trigger-probing prompts to check for anomalous output on specific input patterns, review the model card and training data provenance documentation, and test the model in an isolated environment before granting it access to production data sources. For fine-tuned models, the NIST AI RMF Playbook provides guidance on supply chain risk management for AI model adoption.

Incident response for Foundry events: Define your Foundry-specific incident response procedures before you need them. Key scenarios to document: a Foundry agent begins making unexpected API calls (potential prompt injection execution), a model catalog model produces outputs inconsistent with its stated capabilities (potential backdoor activation), and unauthorized privilege escalation through a published M365 agent (CVE-2026-35435 class event). The AgentsInfo KQL table in Defender XDR is the fastest starting point for agent inventory and anomaly investigation during an incident.

Hardening Checklist for Azure AI Foundry

Apply these controls in priority order:

Audit agent publication status using the AgentsInfo table in Defender XDR. Identify all published M365 agents and their managed identity permission scopes. Apply CVE-2026-35435 mitigations immediately.

Reconfigure Agent 365 blocking rules under Settings > Security for AI > Policies & rules if your rules existed before July 1, 2026.

Deploy Private Endpoints for the Foundry hub, storage, Key Vault, Azure AI Search, and Azure OpenAI resources.

Apply Azure Policy denying public network access on all Foundry-related resource types at the subscription level.

Scope managed identity permissions to the minimum required resource and role, not resource group or subscription scope.

Enable diagnostic logging for all Foundry resources and route to Log Analytics with 90-day minimum retention.

Configure content filtering policies at the hub level appropriate for each deployment's risk profile.

Run PyRIT-based red teaming for every model before production promotion. Set an ASR threshold that triggers a security review before deployment.

Vet third-party catalog models with behavioral red-teaming and provenance review before granting access to production data.

Document compliance controls mapping Foundry configuration to EU AI Act technical documentation, NIST AI RMF, and ISO 42001 requirements.

Where BeyondScale Can Help

Azure AI Foundry's security posture depends on dozens of configuration decisions across the hub, projects, agents, pipelines, and connected services. Most enterprises discover gaps during incidents rather than assessments.

BeyondScale's AI security assessment covers Azure AI Foundry threat modeling, managed identity permission auditing, Prompt Flow injection testing, and model catalog vetting procedures. If you have already deployed Foundry and want to understand your current exposure, our Securetom scan can identify publicly accessible AI endpoints and misconfigured agent permissions across your Azure environment.

The pace of change in Foundry's security model, from the platform rebrand through CVE-2026-35435 and the Agent 365 transition, means that a security posture that was adequate six months ago may have significant gaps today. A structured review now costs less than a breach later.

---

For further reading:

• Microsoft's guidance on transitioning agent security to Agent 365
• NIST AI RMF Playbook for AI supply chain risk management
• Azure AI Foundry network isolation configuration