Running agents governed when your stack is Microsoft

If your organization runs on Microsoft, your agent journey probably starts there too: Copilot for the users, Copilot Studio or Foundry for building, maybe an evaluation of Agent Framework for custom work. That’s a reasonable starting point — and nothing on this page tells you to abandon it.

What this page covers is the part of the journey Microsoft’s stack doesn’t: what happens when your agents need to be governed as a whole — including the ones that weren’t built in Redmond.

Credit where it’s due

Microsoft has done more than anyone to make agents first-class citizens of the enterprise. As of mid-2026, Entra Agent ID gives agents real directory identities with owners, RBAC and Conditional Access, and Agent 365 wraps that in a registry, audit logs and Purview compliance — generally available, at a published per-user price. If you’ve been waiting for agent identity to be a real, supported thing, it is now.

So the question isn’t whether Microsoft can govern agents. It’s which agents — and what happens after governance.

Three questions to ask before you lock the path

1. How many products does the full chain take — and who owns the whole?

The Microsoft agent story spans Agent 365, Entra Agent ID, Foundry, Copilot Studio and Purview. Each is good at its job. But the assembly is yours: your architecture, your integration effort, your internal owner for the combined result. Before committing, sketch who in your organization owns that whole — not each product, the whole. In our experience, the honest answer is often “unclear,” and that gap surfaces late, in production.

2. What about the agents your teams already built elsewhere?

In most organizations, agents don’t wait for the platform decision. Someone in marketing has a research agent in Claude. An engineer runs three through OpenAI. They exist today, they do real work, and they sit outside your Microsoft governance plane. Microsoft’s answer is to bring workloads into its stack — Foundry can host external frameworks, and cross-cloud registry sync exists in preview (as of August 2026). The direction of travel is inward. If your reality is agents living in several stacks — and staying there — you need a layer whose whole design is to not care where an agent was built.

3. Where does a business person approve what an agent does?

Microsoft’s Agent Framework gives developers solid human-in-the-loop primitives — tool approval, request/response ports. But they’re SDK plumbing: your team designs, builds and maintains the surface where an actual human says yes or no. Ask to see that surface as a product, for a business owner rather than a developer. Then decide whether building and owning it yourself is where you want your engineering budget.

Where Copyl fits — beside, not instead

Copyl is an independent, European operating layer for agents. It doesn’t replace Copilot Studio or Foundry — those remain excellent places to build. It sits above them, and above every other build platform, doing one job: making any agent a governed, accountable member of your organization.

Concretely, today: take the definition of an agent — built in Copilot Studio, Claude, ChatGPT, or by hand — express it as an open JSON Agent Manifest, and run it in a governed sandbox. Zero credentials, every external tool call captured instead of executed, a full transcript, and a proposal for what the agent would need to run for real. About a minute from paste to first governed run. The risky decisions — real accounts, real scopes — come after you’ve seen it work, and the path toward production is built on explicit grants and sign-off.

Two structural things follow from independence. Copyl treats every build platform the same — Microsoft’s included — because we have no model or cloud to steer you toward; a vendor with a stack to sell can never be a neutral layer above its competitors. And for European organizations, especially publicly owned ones, agent governance under an independent EU vendor is a different sovereignty posture than governance embedded in a US hyperscaler’s identity plane.

On cost, one distinction matters more than any number: Microsoft prices the stack per human user plus consumption — credits and tokens whose monthly total you learn after the agents run. A governance decision and a cost model are the same decision here. Whatever you choose, make the comparison on the cost of the work an agent performs, with the consumption lines included — not on the license row alone.

When Agent 365 is all you need

Honestly: if your agents are built in Microsoft tools, act only on Microsoft systems, are used by already-licensed Copilot users, and you have no requirement for stack-independence or EU-sovereign governance — use the native stack. It’s integrated, it’s in your renewal, and a neutral layer would add nothing but complexity.

The neutral layer earns its place when any of those assumptions breaks: agents from more than one platform, systems across vendor boundaries, sovereignty requirements, or simply a path you’re not ready to lock.

Try it without deciding anything

The fastest way to evaluate this isn't a slide deck — it's your own agent in a governed sandbox. Take an agent definition you already have (or the complete example in the manifest reference) and run it:

Import your agent →

No credentials, no migration, no platform decision. Your Microsoft roadmap stays exactly as it is — you just get to see your agents, all of them, governed in one place.

Build your agent anywhere. Run it governed. · Agent Manifest reference