The Microsoft agent landscape

Microsoft doesn’t sell one AI product. It sells a whole shelf of them, and the names blur together: Microsoft 365 Copilot, Copilot Studio, Agent Builder, Foundry, Agent 365. It’s genuinely hard to tell where one stops and the next begins.

This guide draws the map. By the end you should be able to take any Microsoft AI product, drop it into the picture, and know roughly one thing: who is responsible for securing it, Microsoft or you. It doesn’t get into specific controls — those come in later guides. Think of this as the orientation everything else hangs off.

It helps to know the shape before you start, because the guide tells the story in two halves. Part 1 is about building agents — the five surfaces where AI gets made, and what each one leaves you to secure. Part 2 is about governing them — Agent 365, the single place you observe, govern, and secure everything from Part 1 once it exists. Almost all the confusion in this space comes from mixing those two stories up, so we keep them apart.

What to take away

Start with one question

For any Microsoft AI product, ask: how much of this did I build, and how much do I therefore have to secure? That single question orders the whole landscape. Every product sits somewhere on one line — at one end you buy something finished and switch it on, at the other you write your own agent from scratch — and it’s the same shared-responsibility line you already know from cloud.

Surface	Coding approach	Runs on
Microsoft 365 Copilot	None (ready-made)	Copilot’s orchestrator + Microsoft-hosted models
Agent Builder → declarative agents	No/low-code	Copilot’s orchestrator + models
Copilot Studio agents	Low-code	Power Platform (connectors, Dataverse)
Microsoft Foundry agents	Pro-code (PaaS)	Foundry runtime, your choice of model
GPUs & containers	Pro-code (IaaS)	Your own infrastructure

Read the table top to bottom and you move from “Microsoft built it” to “you built it.” Read the same table as security and you move from “Microsoft secures most of it” to “you secure most of it.” It’s one line, seen two ways.

One thing to hold in mind before the bottom rows pull you in: this line is only build-time responsibility — who owns the model, the logic, and the runtime. It isn’t the whole security story, because Agent 365 later adds a common layer of identity and governance across every row, no matter where an agent was built. We’ll come to that in Part 2.

Part 1 · Where agents get built

Everything in this half is about building agents — the five surfaces from the table, taken one at a time. For each, the question is the same: how much does Microsoft secure, and how much is left to you? (Part 2 picks up the other half — governing whatever you build here.)

Microsoft 365 Copilot: the finished product

This is the AI most of your users will actually touch — Copilot in Teams, Outlook, Word, and the Copilot chat. You don’t build it. Microsoft runs the model, the orchestration, and the hosting. Your job is to decide what data it can see and who is allowed to use it.

That makes securing Copilot a data problem, not an application problem. Copilot answers using your own company content through Microsoft Graph, and it only ever shows a person what that person already has permission to open. So the real work is keeping permissions clean: no oversharing, the right sensitivity labels, DLP in place, auditing switched on. Get the data hygiene right and you’ve mitigated the largest source of Copilot risk. Get it wrong and Copilot will happily surface the one file nobody should have been able to find.

Agent Builder: Copilot, tailored

Sometimes plain Copilot isn’t specific enough. So you give it extra instructions and point it at particular knowledge — an HR policy assistant, an onboarding helper, a sales-playbook agent. That tailored version is called a declarative agent. The easiest way to make one is Agent Builder, built right into the Microsoft 365 Copilot app: you describe what you want in plain language and it assembles the agent for you. Developers who want source control and a repeatable pipeline can build the same kind of agent with the Microsoft 365 Agents Toolkit instead.

The security point is simple. These agents still run on Copilot’s own model and orchestration, so they inherit all of Copilot’s security, compliance, and safety controls automatically. You’re back to the same data-and-access problem as before, with one new question: who in your organization is allowed to build and publish agents in the first place?

One exception to watch for. A custom engine agent brings its own model and can run outside Microsoft 365. It doesn’t inherit those controls, so treat it like the pro-code end of the map, not this one.

Copilot Studio: low-code agents on Power Platform

Copilot Studio is where business teams build more capable agents without really coding — a drag-and-drop canvas, a big library of prebuilt connectors, and the option to publish the result into Teams and Microsoft 365. It’s the sweet spot for department-level automation.

The thing to remember is that Copilot Studio isn’t its own island. It runs on Power Platform, and its data lives in Dataverse. So securing a Copilot Studio agent pulls you into Power Platform territory: how your environments are set up, which connectors people are allowed to use (a loose connector can quietly bridge two systems that should never touch), and the Dataverse permission model. You’re now responsible for the platform underneath the agent, not just the agent itself.

Microsoft Foundry: build it yourself

Microsoft Foundry (until recently called Azure AI Foundry) is the developer end of the map. It’s a full platform for building and running AI apps and agents: a catalog of models to pick from, a runtime to host agents, built-in tools, and the tracing, evaluation, and monitoring an engineering team expects. Its knowledge-and-grounding layer is called Foundry IQ (some of it is still in preview).

You can build in Foundry two ways. A prompt agent stays fairly hands-off — you give it instructions, choose a model, attach a few tools, and Foundry runs it for you. A hosted agent is your own code, in whatever framework you like (Microsoft Agent Framework, LangGraph, the OpenAI or Anthropic SDKs, the GitHub Copilot SDK), packaged in a container that Foundry runs with its own identity and monitoring.

By the time you’re here, almost everything is yours: the model, the logic, the tools, the prompts, and the fallout if the agent misbehaves. Foundry gives you a managed runtime and enterprise guardrails, but the agent’s behavior is your design. Go one step further and run your own GPUs and containers, and you own literally all of it.

A quick word on the SDKs

There are a lot of SDKs in this space and the names collide, so it helps to separate two different jobs.

The first job is building an agent’s logic — the prompts, the reasoning, the tool calls. That’s what a build framework does. Microsoft Agent Framework is Microsoft’s open-source framework for building agents and workflows: it combines the enterprise foundations of Semantic Kernel with many of the orchestration ideas originally developed in AutoGen, and it’s deliberately model-agnostic: you can point it at Foundry, Azure OpenAI, OpenAI, Anthropic, Ollama, and others. The GitHub Copilot SDK and third-party frameworks like LangGraph do the same job, and for Microsoft 365 agents there’s the Microsoft 365 Agents SDK. Pick whichever suits your team — the choice is about developer experience, not really about security.

The second job — making an agent you’ve already built governable — is a completely different thing, and it’s the one the name collision trips people on. We’ll get to it under Agent 365 below.

What every agent runs on: your data

Peel back every one of these products and they’re doing the same job — connecting a model to your company’s data so it can give useful, specific answers. Microsoft calls this grounding, and it’s the heart of the whole strategy. The model brings the reasoning; your data brings the facts. And your data is where the security actually lives, because the model on its own knows nothing about your business.

Each surface grounds a little differently:

• Microsoft 365 Copilot grounds on Microsoft Graph through the semantic index. Importantly, that index is permission-trimmed: it only ever returns content the person asking could already open.
• Copilot Studio agents ground on Dataverse and whatever their connectors reach.
• Foundry agents ground through Foundry IQ, which pulls from sources like Azure storage, SharePoint, OneLake, and the web. It retrieves using the identity model the solution designer chooses, and can enforce user-scoped access where that’s configured.

You’ll also hear three “IQ” names, and they all belong to this intelligence and grounding layer:

• Fabric IQ gives agents access to business and analytics data.
• Work IQ gives agents access to workplace context and organizational knowledge.
• Foundry IQ gives agents access to enterprise content and knowledge sources.

Each works on its own; where a design composes them, they give an agent a fuller picture of the organization — but that composition is an architecture you build, not something that happens automatically.

Part 2 · Governing everything you built

Everything up to here has been Part 1 — building agents. This is the other half of the story. Agent 365 is about managing agents once they exist, wherever they came from. It’s a single control plane meant to inventory and govern agents across your tenant — the ones built in Copilot Studio and Foundry, the ones an admin registered, the ones you bought from a vendor, even the ones nobody told you about — with how much you see and control depending on how deeply each agent is integrated.

The problem it solves is sprawl. Your first few agents are easy; you know each one personally. At fifty or five hundred, that familiarity is gone, and without one place to see and govern them you lose track of what each agent can reach and do. Agent 365 is Microsoft’s answer to that.

It doesn’t invent new security machinery. It uses the Microsoft tools you already run — Entra, Purview, Defender, Intune — and organizes them around agents:

Agent 365 pillar	Delivered through
Observe — every agent in one registry, incl. shadow and third-party	Entra, Microsoft 365 admin center
Govern — access, lifecycle, compliance guardrails	Entra, Purview, Microsoft 365 admin center
Secure — risk-based access, threat detection, data protection	Entra, Microsoft Defender, Microsoft Purview

The Agent 365 SDK: a governance wrapper, not a build framework

Here’s the naming trap worth calling out plainly. The Agent 365 SDK does not build or host agents. It takes an agent you already built — in Agent Framework, Copilot Studio, the GitHub Copilot SDK, or anything else — and adds the enterprise layer on top: an Entra Agent ID identity, governed access to Microsoft 365 data through Work IQ, OpenTelemetry observability, and notifications so the agent can take part in Teams and Outlook like a real participant. Picture three layers stacked:

Layer	What it does	Who provides it
Enterprise capabilities	Identity, observability, notifications, governed tools	Agent 365 SDK
Agent logic	Prompts, workflows, reasoning	Your code
Model & orchestration	Calling the model, running the tools	Your build framework (Agent Framework, GitHub Copilot SDK, …)

So Agent Framework and the Agent 365 SDK aren’t competitors — they stack. One builds the agent; the other makes it a governed member of your tenant. The names in this space are unhelpfully close together, so it’s worth laying the four you’ll hear side by side:

SDK	What it’s for
Microsoft Agent Framework	Build agent logic
GitHub Copilot SDK	Build agent logic
Microsoft 365 Agents SDK	Build and host Microsoft 365 agents
Agent 365 SDK	Make an already-built agent governable

What about agents built on Anthropic, OpenAI, or other platforms?

They can be brought under governance here — that’s the whole point of a control plane — but how much control you get depends on how deeply the agent is integrated. Agents you build with Microsoft Foundry, Copilot Studio, or Agent Builder are wired into Agent 365 automatically, so you get the full picture. For agents built anywhere else — an open-source framework, a third-party SaaS, your own code, or platforms like Amazon Bedrock and Google Vertex AI — there are two levels. Syncing them into the registry (no code needed for Bedrock and Vertex) gives you visibility — you can see the agent exists and inventory it — but not much more. For real control — a first-class Entra identity, observability, and governed data access on the same footing as a native agent — a third-party agent has to adopt the Agent 365 SDK. So the model or platform an agent was built on doesn’t lock you out of governing it, but the depth of that governance follows how far you’re willing to integrate it.

So who secures what?

Here’s the whole map in one view: for each surface, what Microsoft secures and what falls to you. Read down the rows and your share grows — the deeper you build, the more you own.

Component	Microsoft secures	You secure
Microsoft 365 Copilot	Model, orchestration, hosting, platform safety	Data exposure, labels, DLP, identity/access
Declarative agent	Same as Copilot (inherited)	Instructions, knowledge scope, who can build/publish
Copilot Studio agent	Platform runtime	Power Platform environments, connectors, Dataverse, logic
Foundry prompt agent	Runtime, hosting, scaling	Model choice, instructions, tools, data access
Foundry hosted agent	Managed endpoint, platform, agent identity issuance	Agent code, orchestration, model, prompts, tool wiring

One thing the columns don’t show: the “you secure” work doesn’t reset row by row — it accumulates. Building a custom agent never removes the data, identity, and access hygiene the simpler surfaces already asked of you; it adds to it. And Agent 365 sits over the whole table: it doesn’t take any of that build-time work off your plate, but it does give you one place to see and control the result.

All of it assumes a healthy Zero Trust baseline underneath — verified identities, least-privilege access, device compliance, and the network controls that apply to your whole enterprise, not just AI. Get that foundation right first; the AI-specific work stacks on top of it, it doesn’t stand in for it. See Microsoft Zero Trust.