On November 18, 2025, at Microsoft Ignite, Microsoft rebranded Azure AI Foundry as Microsoft Foundry. The third rename in two years for the same underlying technology, the announcement created real confusion across enterprise IT and security teams: is this a cosmetic rebrand or a meaningful architectural shift? And more importantly, what does it mean for your organization's data security posture?
This guide answers both questions with facts, with a dedicated focus on what Microsoft Foundry changes, and what it does not change, about access management and permissions in Microsoft 365.
What Is Microsoft Foundry?
According to Microsoft's official documentation, Foundry is "a unified Azure platform-as-a-service offering for enterprise AI operations, model builders, and application development."
In practice, it is the platform where developers and IT teams build, deploy, and operate AI applications and agents at enterprise scale.
The platform has evolved rapidly since its initial release:
- November 2023: Azure AI Studio launched in Public Preview
- November 2024 (Ignite 2024): rebranded as Azure AI Foundry, with a first consolidation of Azure AI services
- November 2025 (Ignite 2025, November 18): rebranded as Microsoft Foundry, with a strategic shift positioning AI agents as first-class citizens in the Microsoft ecosystem
Dropping "Azure" from the product name is deliberate. It signals that Foundry is no longer just another Azure service. Microsoft now positions it as the third strategic pillar of its product portfolio, alongside Microsoft 365 and Microsoft Fabric.
Microsoft Foundry Key Components
Microsoft Foundry brings several previously distinct services together under a single portal, accessible at ai.azure.com.
Foundry Agent Service is the production runtime for AI agents. Reaching general availability on March 16, 2026, it enables teams to build agents that reason, plan, and act across tools, data, and enterprise workflows. It is built on the OpenAI Responses API and compatible with open-source frameworks including LangGraph.
Foundry Control Plane is the centralized governance dashboard. It gives IT teams full visibility across all agents, models, tools, and data deployed within an Azure subscription. It is the single point of control for managing access, monitoring performance, and enforcing security policies.
Foundry IQ is the knowledge layer that connects agents to enterprise data. It supports internal data sources including SharePoint, OneLake, and Azure Blob Storage, with access control list (ACL) synchronization and support for Microsoft Purview sensitivity labels. In practice, an agent connected to Foundry IQ can query your SharePoint documents and return only the content the user is actually authorized to access.
The model catalog provides access to over 11,000 models: OpenAI's GPT-5 family, Anthropic's Claude, xAI's Grok, Microsoft's Phi-4, NVIDIA Nemotron models, and more. Azure is currently the only cloud simultaneously offering models from both OpenAI and Anthropic.
Foundry Local enables running models directly on local machines or in sovereign, air-gapped environments with no cloud dependency. Reaching general availability in April 2026, it addresses the sovereignty and compliance requirements of organizations that cannot expose their data to external cloud services.
Microsoft Foundry and Microsoft 365: A Direct Connection
Microsoft Foundry does not operate in isolation. Its integration with Microsoft 365 is native and deep, which is precisely the central concern for security teams. [ADAPTED FROM FR]
Foundry agents can be published directly to Microsoft 365 Copilot, Microsoft Teams, or BizChat with one click. They authenticate using Microsoft Entra ID via the On-Behalf-Of (OBO) delegated identity mechanism. This means agents act on behalf of the signed-in user, inheriting that user's permissions.
Foundry IQ natively accesses SharePoint and OneLake data. When an agent queries a knowledge base connected to SharePoint, the platform enforces the user's permissions: the agent cannot surface documents the user is not authorized to see.
The critical point is this: Foundry agents inherit existing M365 permissions. Where those permissions are properly configured, security is maintained. Where they are not, agents will replicate the same exposure, with the speed and precision of an industrial AI engine.
Data Security and Governance Implications
This is what CISOs and IT administrators need to assess before any Microsoft Foundry deployment.
Foundry Amplifies Existing M365 Permission Gaps
Foundry IQ synchronizes ACLs from SharePoint and OneLake so agents respect user access rights. But that synchronization mirrors the actual state of permissions. If a user unknowingly has access to a directory containing sensitive HR data because a share was never revoked, the Foundry agent will access it too. The agent's ability to proactively retrieve, synthesize, and surface information makes that kind of exposure far more visible than in typical human usage.
This is the same dynamic observed with Microsoft 365 Copilot: AI does not grant new permissions, but it surfaces and amplifies poorly governed ones.
A few numbers that frame the stakes: [US CONTEXT ADDED]
- Generative AI is now involved in 32% of data security incidents, according to the 2026 Microsoft Data Security Index
- 80% of data breaches originate from internal errors, not external attacks
- The average cost of a data loss event for a mid-market organization is estimated at $2.5M
What Foundry Delivers Natively on Security
It would be inaccurate to present Microsoft Foundry as a platform without safeguards. Foundry ships with a substantial, enterprise-grade security stack that continues to evolve.
Unified RBAC under the Microsoft.CognitiveServices namespace lets teams manage access to models, agents, tools, and data through a single, consistent control model aligned with Azure. Native integration with Microsoft Defender and Entra ID handles identity protection and monitoring. Foundry Control Plane centralizes governance across all agents deployed within a subscription.
Since March 2026, integrations with Palo Alto Networks Prisma AIRS and Zenity have reached general availability. They provide real-time detection of prompt injection, sensitive data leakage, malicious content, and tool misuse, directly within Foundry workflows.
Microsoft Purview is integrated for regulatory compliance, including GDPR, HIPAA, and the EU AI Act. Sensitivity labels are extracted during indexing and enforced at every query. [US CONTEXT ADDED: For US organizations subject to HIPAA or CMMC, Purview label enforcement provides the auditability layer required for compliance documentation.]
What Foundry Does Not Solve: Upstream M365 Governance
This is the most important point for any CIO or CISO preparing to deploy Foundry agents.
An organization's data security posture is not limited to the security of its AI platform. Foundry secures agents and their runtime behavior. It does not fix upstream M365 permissions. An overshared SharePoint site that has been exposed for years, anonymous links that were never revoked, external guest access that became stale: Foundry IQ synchronizes those states as-is.
Microsoft's own documentation is explicit: "User-level access controls are only enforced when explicitly configured for synchronization." In other words, the security of the entire chain depends on the quality of M365 governance that exists before the first agent is ever deployed.
How to Prepare Your M365 Environment Before Deploying Microsoft Foundry
The prerequisite is not narrowly technical. There is no infrastructure to install. It is a governance prerequisite: ensuring that M365 access rights actually reflect what should be shared, with whom, and for how long.
In practice, this means:
- Identify high-risk shares: anonymous links, "entire organization" shares, inactive external guest access, sensitive data sitting in public spaces. Mapping the tenant is the unavoidable starting point.
- Involve data owners directly: IT cannot correct years of accumulated permissions alone. Remediation has to come from users themselves, who are the only ones who can judge whether a share is still legitimate. Empowering data owners is the condition for effective, lasting remediation.
- Tighten external sharing controls in Microsoft 365: external sharing is consistently the most underestimated exposure vector, and one of the first that Foundry agents are likely to replicate.
- Establish periodic governance cycles: not a one-time audit before deployment, but recurring campaigns every six months, so permission quality keeps pace with the natural evolution of the tenant.
IDECSI's DETOX for M365 is a turnkey program built specifically for this prerequisite: full tenant scan, user-level remediation for data owners on their own shares, results measurable in weeks, with no heavy IT lift. Over one million users have completed the process, averaging seven remediations per user, with up to 50% of risks eliminated in the first campaign.
Conclusion
Microsoft Foundry represents a structural shift in Microsoft's enterprise AI strategy. It is not a simple rebrand: it is a production platform for deploying AI agents capable of acting across your organization's full data and workflow landscape.
For IT and security teams, the question is not whether Foundry is secure in itself. It is. The question is whether the M365 environment it builds on is well-governed enough to trust. A well-configured agent running on a poorly governed tenant is still an agent accessing the wrong data.
Assess your M365 tenant readiness before deploying your first Foundry agents. It is the prerequisite that most organizations skip, and the one that determines whether AI becomes a productivity asset or a liability.
[Request an IDECSI Demo]
