Foundry Agents vs. Copilot Studio Agents. Blueprints vs. Governance Policies. Stop Confusing Them.
Microsoft is shipping agent infrastructure faster than most organizations can absorb it. In the last 90 days, I have had the same conversation with at least six clients: “We built an agent in Copilot Studio, now someone on the dev team built one in Foundry, and nobody knows which controls apply to what.”
If that sounds familiar, this breakdown is for you.
I want to clarify two sets of concepts that are getting tangled together as organizations spin up their agent strategies. First, the difference between building agents in Microsoft Copilot Studio versus Microsoft Foundry (formerly Azure AI Foundry). Second, the difference between Entra Agent ID Blueprints and Agent 365 Governance Policies, and why you need both.
Copilot Studio vs. Foundry: Two Builders, Different Jobs
The simplest way to think about this: Copilot Studio is where your business users and Power Platform makers build agents. Foundry is where your developers and data scientists build agents. Both produce agents that can operate inside your Microsoft 365 environment, but the build experience, the level of control, and the intended complexity are different.
Copilot Studio is a low-code platform rooted in Power Platform. You get a visual canvas for designing dialog flows, access to 1,000+ Power Platform connectors, and tight integration with Microsoft 365 and Teams. A business analyst can have a working agent deployed to Teams in hours. I have seen IT helpdesk agents handling password reset workflows go from concept to production in under two weeks using Copilot Studio with a knowledge base of a few hundred articles.
The tradeoff is ceiling. Copilot Studio works well for conversational agents grounded in Microsoft 365 data, departmental automation, and scenarios where the knowledge base stays under roughly 500 documents. You do not get to choose your underlying model, you do not get fine-grained prompt tuning, and you do not get multi-model orchestration.
Microsoft Foundry (the new name for Azure AI Foundry as of early 2026) is code-first. You get access to a catalog of over 11,000 models, including OpenAI GPT-4o, Phi, Meta Llama, Mistral, and NVIDIA models, with provisioned throughput and model routing. Foundry gives you full control over prompt engineering, temperature settings, RAG pipelines using Foundry IQ and Azure AI Search, and multi-agent orchestration patterns. Foundry Agent Service handles conversation orchestration, tool integration, safety controls, and observability from development through production.
The tradeoff is speed and skill. You need developers. You need Azure infrastructure. You need someone who understands token economics, evaluation frameworks, and model selection. A vehicle manufacturer I read about had several thousand technical manuals and needed an agent that could handle that scale. Copilot Studio was not a fit. Foundry was.
The real-world pattern I am seeing: Organizations do not pick one. They use both. Developers build specialized backend logic and data retrieval agents in Foundry. Makers assemble the user-facing experience in Copilot Studio. The two platforms are designed to be interoperable. Foundry handles the heavy lifting. Copilot Studio handles the last mile to Teams, Outlook, and SharePoint.
The decision criteria map cleanly:
Your users live in M365, you need quick wins, low-code speed, Power Platform connectors, and governance baked into the platform: Copilot Studio.
You need custom models, multi-agent orchestration, enterprise RAG over large data sets, or deployment outside M365 channels: Foundry.
You need both of those things: Both. That is not a sign of confusion. It is how Microsoft designed the stack.
Blueprints vs. Governance Policies: The Identity Layer vs. The Control Plane
This is where the confusion gets thicker. Microsoft introduced Entra Agent ID Blueprints and Agent 365 Governance Policies at roughly the same time, and people are treating them as interchangeable. They are not. They solve different problems at different layers of the stack.
Entra Agent ID Blueprints
An agent identity blueprint is an object in Microsoft Entra ID. It is the template from which agent identities are created. Think of it the same way you think about an app registration, but for agents specifically.
A blueprint defines four things:
Authentication foundation. The blueprint holds the OAuth client ID and credentials that agent identities use to request access tokens. Individual agent identities do not have their own credentials. They inherit them from the blueprint.
Shared configuration. Properties like appRoles, optional claims, and verified publisher are set at the blueprint level and inherited by every agent identity created from it.
Permissions baseline. OAuth permissions granted to a blueprint flow down to all agent identities it creates. You can also assign role-specific permissions directly to individual agent identities for scoping.
Policy container. Conditional Access policies applied to a blueprint take effect for every agent identity under it. Disabling a blueprint kills authentication for all its agent identities at once.
When you create an agent in Foundry, the platform automatically provisions a default blueprint and default agent identity for the project. When you publish that agent, Foundry creates a dedicated blueprint and identity so the agent authenticates with its own unique credentials.
For multitenant agents, blueprints work like app registrations: a blueprint principal gets created in each tenant, allowing agent identities to be provisioned locally.
The key mental model: Blueprints are identity infrastructure. They answer “who is this agent, how does it authenticate, and what permissions does it inherit?”
Agent 365 Governance Policies
Agent 365 is the control plane for AI agents. It goes GA on May 1, 2026, at $15 per user per month standalone, or included in the new Microsoft 365 E7 bundle at $99 per user per month.
Agent 365 governance policies are the tenant-level settings you configure in the Copilot Control System within the Microsoft 365 admin center. These policies answer a different set of questions than blueprints.
Governance policies control:
Agent access. Who can use which agents in your tenant.
Agent sharing. Whether creators can share agents with other users.
Agent publishing. The admin approval workflow that agents go through before becoming available tenant-wide. An agent built in Copilot Studio goes through a tenant publishing pipeline that requires admin approval before it reaches users.
Lifecycle management. Rules-based automation that expires inactive agents, flags ownerless agents, or blocks agents that trigger risk signals.
Billing and consumption. Pay-as-you-go and capacity pack configurations tied to agent usage.
Security integrations. Agent 365 connects to Defender for security monitoring, Purview for data governance and DSPM for AI, and Entra for identity. Comprehensive audit logs capture agent interactions across systems.
The key mental model: Governance policies are operational controls. They answer “who can deploy agents, what approval gates exist, how do we track usage, and how do we enforce lifecycle hygiene?”
Why You Need Both
Blueprints without governance policies means your agents have strong identity foundations but no operational guardrails. An agent with a well-configured blueprint can still be shared to the wrong audience, rack up uncontrolled consumption costs, or persist long after its business purpose expires.
Governance policies without blueprints means your operational controls exist, but the agents underneath them lack proper identity infrastructure. You cannot apply Conditional Access to an agent that does not have an Entra Agent ID. You cannot enforce least-privilege permissions if agents are authenticating through shared service principals instead of dedicated agent identities.
The layering works like this: Blueprints set the identity and authentication foundation per agent type. Governance policies set the operational rules across all agents at the tenant level, regardless of where those agents were built. Agent 365 is designed to govern agents regardless of their build platform, whether that is Copilot Studio, Foundry, or a third-party framework.
Where Is Microsoft Heading with This?
I think the next 12 months will collapse the admin experience. Right now, you configure blueprints in Entra, governance policies in the M365 admin center, security monitoring in Defender, and data controls in Purview. That is four admin surfaces for one agent. Microsoft has been consolidating admin experiences aggressively, and I expect the Agent 365 control plane to become the single pane of glass that pulls blueprint status, governance policy compliance, security posture, and data risk into one view.
The organizations getting ahead of this are doing three things now: inventorying agents using the Entra Agent Registry, applying blueprint-level identity and Conditional Access policies at agent onboarding, and requiring admin approvals for all tenant-published agents.
Start there. The tooling will catch up to the ambition, but the governance discipline you build now will compound.
Caleb McDowell is a Microsoft Security evangelist and highly certified practitioner. He runs a Microsoft Security Services practice helping organizations deploy and operationalize the Microsoft E5 security stack. Follow on LinkedIn or subscribe at calebamcdowell.substack.com.
Great article