Azure AI Foundry Security: Agent Security, Baseline and Best Practices for Microsoft Foundry
Microsoft Foundry, still searched for as Azure AI Foundry, ships more platform security than most teams use. The gap is not the platform. It is the row in Microsoft own responsibility matrix that never moves off your side of the table.
Direct answer
Azure AI Foundry, renamed Microsoft Foundry at Ignite in November 2025, is a well secured platform. It supports private endpoints and managed network isolation, Microsoft Entra Agent ID for agent identity, Prompt Shields and Azure AI Content Safety for jailbreak and prompt injection detection, Defender for Cloud AI posture management and threat protection, and Purview DSPM for AI. Agent data is stored at rest inside your own tenant in the Azure OpenAI resource you create, in the same geography, double encrypted with AES-256 and optionally with a customer managed key. Prompts and completions are not available to other customers and are not used to improve OpenAI, Meta, Cohere or Mistral models. The part buyers miss sits in Microsoft own AI agent shared responsibility model, updated in August 2026. For a PaaS agent built on Foundry Agent Service, Microsoft writes that you own the agent instructions, tool and plugin selection, tool permissions, orchestration logic, memory design, and the agent identity and authorization. Three rows are marked Customer for every deployment model Microsoft lists, including fully managed SaaS: human in the loop approval for high impact actions, acceptable use and accountability for actions, and customer data. Microsoft states the principle directly: autonomy never reduces accountability. The comparison table further down has rows where the honest answer is that the native Foundry control is the right purchase and we are not the thing you need.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A Foundry agent usually starts as a demo that worked too well. It answers questions over a SharePoint index, someone adds a Logic App so it can file the ticket instead of describing it, then an OpenAPI tool so it can update the record, then a Bing grounding tool so it can read the vendor page first. Nothing in that sequence is a mistake, and every step passed review on its own. What changed is the blast radius: the agent now reads untrusted text from the open web and holds a token that can write to a system of record. The Azure portal will show you the deployment, the content filter configuration and the diagnostic logs. It will not show you a single screen that answers the question an auditor asks first, which is who decided this agent was allowed to perform this action on this record, and what stopped it from performing the next one.
How Agentshield handles it
Use the Foundry controls properly first, because most of them are free with the subscription and nothing you buy later replaces them. Deploy with managed network isolation and private endpoints rather than a public endpoint, authenticate with managed identity instead of API keys, register every agent in Microsoft Entra Agent ID so the directory of agent identities is real rather than tribal knowledge, turn on Prompt Shields and configure content filtering on both input and output, and enable diagnostic logging to Azure Monitor so token usage and filter results are queryable. Then add the layer Microsoft tells you to build yourself. In the Azure AI security best practices guidance, the recommended way to get human review of a high risk action is to design a Logic Apps or Power Automate workflow that pauses for approval, which means the approval gate is an application you now own, maintain and audit. The alternative is to put that control in the action path as configuration: a scoped identity per agent so a hijacked prompt cannot reach a tool the agent was never granted, a policy that denies out of scope tool calls before they execute rather than filtering the text that requested them, an approval gate on irreversible operations such as payments, deletions and production writes, and an append only record of attempted and blocked actions held somewhere the agent host cannot rewrite. Foundry governs the model and the network. The second layer governs the action.
The controls
The controls that secure the agents your teams build in Microsoft Foundry, and the tools those agents call.
Is Azure AI Foundry secure? What Microsoft Foundry covers in 2026
Yes, and it is worth being specific about why, because a lot of writing on this topic is vague enough to be useless at procurement time. Foundry inherits the Azure security stack rather than reinventing it, so the controls a security team already knows how to operate mostly apply. The table below lists the native controls that matter for an agent workload and what each one actually does.
| Control | What it does | Where it sits |
|---|---|---|
| Managed network isolation and private endpoints | Removes the public endpoint and routes traffic through your virtual network, with outbound control on the managed network | Network |
| Microsoft Entra Agent ID | Gives agents a first class identity type in the directory, unified across Copilot Studio and Foundry, so agents are enumerable and their lifecycle is managed | Identity |
| Prompt Shields and Azure AI Content Safety | Detects jailbreak and prompt injection attempts in input, with output filtering as a second stage | Model input and output |
| Defender for Cloud, AI posture and threat protection | Discovers AI workloads, builds an AI bill of materials, runs attack path analysis, and detects prompt injection and anomalous API usage at runtime | Posture and detection |
| Purview DSPM for AI and sensitivity labels | Reports on AI activity, applies DLP policy to data in prompts, and flags oversharing risk | Data |
Two things follow from that list. The first is that a team running Foundry with private endpoints, managed identity, Entra Agent ID, Prompt Shields and Defender enabled has a stronger baseline than most self hosted agent stacks will ever reach. If you are choosing between configuring these and buying anything, configure these. They are the better spend.
The second is that every control in the table operates on the model, the network, the data or the posture. None of them operates on the action. Prompt Shields inspects the text arriving at the model and is good at it, but a prompt injection that survives the shield is stopped by nothing further along, because the tool call that follows is not evaluated against a policy. Defender will tell you it happened. That distinction, detection versus interception, is the whole subject of the next section, and Microsoft documents it more plainly than we could.
The Azure AI Foundry security baseline: what Microsoft says you own
In August 2026 Microsoft published an AI agent shared responsibility model, separate from the older cloud and generative AI versions, specifically because agents act. It is the single most useful document for anyone evaluating Foundry security, and it is unusually direct about where Microsoft stops.
Foundry Agent Service is what Microsoft classifies as a PaaS agent. For that tier the document states, in its own words, that Microsoft provides the runtime, model hosting, and platform safety controls, and that you own the agent instructions, tool and plugin selection, tool permissions, orchestration logic, memory design, and the agent identity and authorization. That is not a caveat buried in a footnote. It is the definition of the tier.
The accompanying matrix marks each responsibility Customer, Microsoft or Shared. These are the agent specific rows for a PaaS agent on Foundry Agent Service, reproduced from Microsoft documentation.
| Responsibility | PaaS agent on Foundry | Fully managed SaaS agent |
|---|---|---|
| Agent instructions, system prompt and scope | Customer | Shared |
| Tool, plugin and connector selection | Customer | Shared |
| Per tool permissions, least privilege | Customer | Shared |
| Human in the loop approval for high impact actions | Customer | Customer |
| Per action authorization checks | Shared | Shared |
| Action audit logging and monitoring | Shared | Shared |
| Agent runtime and orchestrator platform | Microsoft | Microsoft |
Read the second column on its own and the shape is clear. Microsoft owns the runtime. You own what the agent is allowed to do with it. Now read across to the third column, which is the most managed option Microsoft offers, and notice which row does not move: human in the loop approval for high impact actions stays Customer whether you build the agent yourself, buy a managed one, or publish it through Copilot Studio. Microsoft lists it again under responsibilities you always retain, alongside authorization of actions and accountability for what the agent does, and closes the section with a sentence worth quoting at anyone who thinks a managed platform absorbs this risk: autonomy never reduces accountability.
The same document names the top risk in the agent model as prompt injection that drives actions, excessive agency, and the confused deputy problem, and its recommended mitigation for the tools layer is authorization on every action, not only at session start. That is a specific engineering requirement. A content filter does not satisfy it, because a filter evaluates text and this requires evaluating an action against a policy at the moment it is attempted, which is exactly what per agent tool permissions and approval gates are for.
Azure AI Foundry data security: what Foundry Agent Service stores and three scope limits
The data story is genuinely strong and is often described worse than it deserves. Microsoft states that your prompts and completions and your data are not available to other customers, are not available to OpenAI, Meta, Cohere or Mistral, and are not used to improve those models. Data that Agent Service stores lives at rest in the Azure OpenAI resource created in your own tenant, in the same geography as that resource, double encrypted by default with AES-256, and it can be deleted by you at any time.
Three limits are worth knowing before you write Foundry into a data protection impact assessment. None of them is a flaw. Each is a boundary Microsoft documents, and a boundary you can only manage if you know it exists.
| Limit | What Microsoft documents | What it means for you |
|---|---|---|
| Customer managed keys and preview features | Data can optionally be encrypted with a customer managed key, except that preview features may not support customer managed keys | A CMK requirement in a contract does not automatically hold for every preview capability you enable |
| Grounding with Bing Search | The tool has separate data collection and privacy terms, and the services are Microsoft as controller services and thereby excluded from the Microsoft Products and Services Data Protection Addendum | The DPA that covers Agent Service does not extend to what the grounding tool processes, so a web grounded agent has a second data path to account for |
| Threads, messages and runs | Using stateful entities creates a data store that persists message history and other content | Conversation history is durable by design, so retention and deletion need an owner rather than an assumption |
One detail cuts the other way and is worth crediting. When an agent uses the Model Context Protocol tool, Microsoft states that the data you pass in headers is only available for the current run and will not persist. That is a sensible default for the place teams most often put credentials, and it is better than several competing implementations. If MCP is how your agents reach internal systems, the wider surface is covered in our guide to MCP server security.
For regulated buyers, two answers come up constantly. Foundry is available in Azure Government for US federal, state and local agencies, though Foundry Agent Service has its own feature availability page for that cloud, so parity with commercial regions should be checked feature by feature rather than assumed. On HIPAA, the business associate agreement is provided through the Microsoft Products and Services Data Protection Addendum and applies for customers on an Enterprise Agreement, Microsoft Customer Agreement or CSP without being separately activated in the portal. Eligibility still depends on how you deploy: US regions, encryption, role based access control and private networking are configuration choices, not defaults that arrive on their own.
Azure AI Foundry vs Microsoft Foundry: what the rename changed for your security review
They are the same product. Microsoft announced at Ignite on 18 November 2025 that Azure AI Foundry is now Microsoft Foundry, dropping Azure from the name to position agents as a pillar alongside Microsoft 365 and Fabric rather than as one more Azure service. That is the second rename in consecutive years: Azure AI Studio became Azure AI Foundry at Ignite in 2024, and Azure AI Foundry became Microsoft Foundry at Ignite in 2025.
| Name | Period | What to know |
|---|---|---|
| Azure AI Studio | Until Ignite 2024 | Documentation under this name predates the agent platform entirely |
| Azure AI Foundry | Ignite 2024 to Ignite 2025 | Still the name most people search for, and the name on most third party security write ups |
| Microsoft Foundry | Since 18 November 2025 | The current name, and where Microsoft publishes current security documentation |
For a security review this matters more than a branding change normally would, for one practical reason. Microsoft moved its documentation to the new name, so the current agent security, data privacy and Azure Government pages live under the Foundry path, while a large amount of third party guidance still describes the platform as Azure AI Foundry and was written before the agent shared responsibility model existed. If you are working from a security baseline document, a vendor questionnaire response or an internal architecture review that predates November 2025, check its date before trusting it. The AI agent shared responsibility model discussed above was updated in August 2026 and did not exist when most Azure AI Foundry security articles were written.
The other question in this cluster is how Foundry compares with AWS Bedrock. At the level that matters here they converge: both give you a managed agent runtime, hosted models, network isolation, an identity system and content filtering, and both draw the line at the same place. Neither one authorizes an individual tool call against your policy or holds an irreversible action for a named human. That is a property of managed agent platforms in general rather than a Microsoft shortcoming, which is why the control we are describing is portable across them.
Azure AI Foundry security best practices, and where a second layer earns its place
Below is an honest split. The left column is what Foundry does natively and where buying anything else would be waste. The right column is the row Microsoft assigns to you. Three of the six rows say use the native control, because that is the truthful answer.
| Requirement | Microsoft Foundry native | Agentshield | Honest verdict |
|---|---|---|---|
| Network isolation and private access | Managed network isolation, private endpoints, managed identity | No | Use Foundry. This is Azure doing what Azure is good at |
| Jailbreak and prompt injection detection in the prompt | Prompt Shields, Content Safety, Defender for AI Services | Yes, at the action boundary | Run both. Prompt Shields is the better text filter |
| Agent identity directory | Microsoft Entra Agent ID | No | Use Entra. A second identity store would be a liability |
| Denying an out of scope tool call before it executes | Not a native control, tool scope is design time | Yes, policy evaluated per call | This is the gap, and it is the row Microsoft marks Customer |
| Approval gate on an irreversible action | Build it yourself in Logic Apps or Power Automate | Yes, configuration rather than an app you maintain | Both work. One of them is a workflow you now own forever |
The approval row deserves the extra sentence. Microsoft guidance for high risk AI operations such as external data transfers or system configuration changes is to design a Logic Apps or Power Automate workflow that pauses for human review and approval before execution. That is sound advice and plenty of teams follow it. It also means the control your auditor cares about most is now a custom application with its own availability, its own change history and its own failure modes, sitting outside the agent platform. That is a reasonable choice when you have one agent and a platform team with spare capacity. It scales poorly at eleven agents and three teams.
If you are earlier in the process and still deciding whether an agent belongs in production at all, our page on enterprise agent security covers the review that comes first, and AI governance covers the policy layer above it. Teams running Foundry alongside Microsoft 365 Copilot usually need both this page and Microsoft 365 Copilot security, because the responsibility matrix genuinely differs between the PaaS and SaaS columns and the same agent policy has to cover both.
FAQ
Common questions about azure ai foundry security.
Is Azure AI Foundry secure?
Yes, as a platform. It supports private endpoints and managed network isolation, managed identity authentication, Microsoft Entra Agent ID, Prompt Shields for jailbreak detection, Defender for Cloud AI threat protection and Purview DSPM for AI. Security for an agent workload also depends on controls Microsoft assigns to you, chiefly per tool permissions and approval on high impact actions.
Is Azure AI Foundry the same as Microsoft Foundry?
Yes. Microsoft announced at Ignite on 18 November 2025 that Azure AI Foundry is now Microsoft Foundry. It is the same product under a new name, and current Microsoft security documentation is published under the Foundry path. Most people still search for the Azure AI Foundry name, which is why both appear on this page.
Is Azure AI Foundry and Azure AI Studio the same?
They are the same lineage. Azure AI Studio was renamed Azure AI Foundry at Ignite in 2024, and Azure AI Foundry was renamed Microsoft Foundry at Ignite in 2025. Documentation still carrying the Azure AI Studio name predates the agent platform, so treat it as historical rather than current guidance.
What is the Azure AI Foundry security baseline?
Microsoft publishes a security baseline for the service plus an AI agent shared responsibility model updated in August 2026. The baseline covers network isolation, role based access control, managed identity, content filtering and logging. The responsibility model is the more useful document for agents, because it states which controls remain yours.
Does Azure AI Foundry protect against prompt injection?
It detects prompt injection rather than preventing the resulting action. Prompt Shields and Azure AI Content Safety analyze input for jailbreak and injection attempts, and Defender for AI Services detects attacks at runtime. If an injection gets through, nothing native evaluates the tool call that follows against a policy, which is why Microsoft names prompt injection that drives actions as the top agent risk.
How does Azure AI Foundry agent authentication work?
Agents authenticate through Microsoft Entra, using managed identities, on behalf of tokens, or a distinct agent identity via Microsoft Entra Agent ID, which provides a unified directory of agent identities across Copilot Studio and Foundry. Microsoft recommends scoped, short lived tokens and warns against granting an agent a broad standing identity.
Is Azure AI Foundry available in Azure Government?
Yes. Microsoft Foundry is available in Azure Government for US federal, state and local government customers and their partners. Foundry Agent Service has a separate feature availability page for Azure Government, so check parity feature by feature rather than assuming a commercial region capability is present.
Is Azure AI Foundry HIPAA compliant?
The business associate agreement is provided through the Microsoft Products and Services Data Protection Addendum and applies for customers on an Enterprise Agreement, Microsoft Customer Agreement or CSP without separate activation. Compliance still depends on your deployment: US regions, encryption, role based access control and private networking are configuration choices you make.
Does Microsoft train on data sent to Foundry Agent Service?
No. Microsoft states that your prompts and completions and your data are not available to other customers, are not available to OpenAI, Meta, Cohere or Mistral, and are not used to improve those models. Note that tools which reach external services, such as Grounding with Bing Search, are governed by their own separate terms.
Is Azure AI Foundry similar to AWS Bedrock?
They are close competitors and converge on security shape. Both provide a managed agent runtime, hosted models, network isolation, an identity system and content filtering. Neither authorizes an individual tool call against your policy at execution time or holds an irreversible action for human approval, so the control gap is the same on both platforms.
More use cases