Two "AI Control Planes", Six Surfaces: Reading Microsoft Agent 365 Against Onyx Security
Microsoft Agent 365 hit general availability on 1 May 2026. Onyx Security came out of stealth in March 2026 with $40M. Both describe themselves as an “AI control plane.”
They are not substitutes.
If you are trying to govern AI across Copilot, Copilot Studio, Copilot for M365 Apps, Cowork, customer-facing chatbots, and the AI quietly embedded in your SaaS stack, here is the honest read.
A note on the name. “Onyx Security” here is the March 2026 startup, not Onyx the enterprise AI search-and-agent platform I’ve written about separately. Different companies, unfortunate collision.
What Agent 365 actually gives you
Agent 365 gives every agent in your Microsoft tenant an identity, a registry record, and a policy wrapper. That is the whole proposition, and it is a good one: agents stop being anonymous workloads and start being governable objects with an owner, a scope, and an audit trail.
Commercials: $15/user/month standalone, or bundled in the new E7 SKU at $99. Note the unit — licensed per user, not per agent. Agent sprawl doesn’t inflate the bill, which is the right incentive if you want teams to register agents rather than hide them.
It is no longer optional in places
This is the part most teams missed. As of 1 July 2026, agent security for Copilot Studio and Foundry requires an Agent 365 licence. Those capabilities are no longer covered by Defender for Cloud or Defender for Cloud Apps entitlements.
The experience still lives in the Defender portal — so nothing looks different until it isn’t there. Tenants without an eligible licence lost access. If you build agents in Copilot Studio or Foundry, you licence Agent 365. That’s not an evaluation any more; it’s a line item.
If you’re doing budget planning off an entitlement mapping you built in 2025, re-check it.
Where Onyx Security sits
Onyx approaches the same problem from outside the tenant. It discovers agents across SaaS, cloud, endpoints, and code repositories, then supervises agent reasoning step by step — blocking, escalating, or redirecting actions in real time.
That’s a meaningfully different control point. Agent 365 governs the agent as an identity; Onyx governs the agent as a running process. One is registry and policy, the other is runtime interception.
The gap most teams miss
Agent 365 is strongest where Microsoft owns the surface. Coverage thins on:
- Third-party agentic tools running on endpoints — Cowork and its equivalents sit on the user’s machine, not in your tenant
- Customer-facing chatbots, which often live in the marketing stack, not the M365 estate
- AI embedded in non-Microsoft SaaS, where the vendor shipped an assistant and never asked you
Onyx is stronger on heterogeneous discovery. But it is a March 2026 company. Most of the independent AI security startups were acquired in the last eighteen months. Price that in on a three-year term — not as a reason to avoid them, but as a reason to ask what happens to your enforcement layer if they’re absorbed in year two. Contractual continuity, data portability, exit plan.
Six surfaces, mapped
| Surface | Agent 365 | Onyx Security |
|---|---|---|
| Microsoft 365 Copilot | Strong — identity, registry, policy | Partial — discovery, not native depth |
| Copilot Studio | Strong (and now licence-gated) | Partial |
| Copilot for M365 Apps | Strong | Partial |
| Cowork / endpoint agentic tools | Thin | Strong — endpoint discovery + runtime supervision |
| Customer-facing chatbots | Thin | Strong |
| AI embedded in third-party SaaS | Thin | Strong |
Read down the columns and the answer is obvious: neither column is full.
Neither one gives you conformity evidence
Here’s what makes me cautious about the “control plane” framing generally. Neither product produces conformity-assessment evidence for ISO/IEC 42001.
Discovery and enforcement are not the same thing as proof that a control operated. An auditor doesn’t want to see that your platform can block an action. They want evidence that, over the assessment period, a defined control was in place, was operated by an accountable owner, and produced a reviewable record when it triggered — plus what happened to the exceptions.
Both tools generate telemetry that feeds that evidence. Neither assembles it into an AIMS. That assembly is still your work: control objectives, ownership, review cadence, exception handling, management reporting. Buying a control plane doesn’t discharge it.
What I’d actually do
Map the surfaces first. Then buy.
Concretely, in this order:
- Inventory by surface, not by vendor. List every place AI acts in your organization — the six above, plus whatever’s specific to you. Shadow-AI discovery is the starting point, not the finish line.
- Mark which surfaces are contractually forced. If you build in Copilot Studio or Foundry, Agent 365 is decided. Take it off the comparison table.
- Score the remaining surfaces for actual exposure — what data can the agent reach, what actions can it take, who is on the other end. A customer-facing chatbot with a CRM connector outranks an internal summarizer every time.
- Buy against the residual, and expect a seam. There will be one. Decide deliberately where it sits rather than discovering it during an incident.
- Build the evidence layer yourself, on top of whatever you buy. That’s the part that survives a vendor acquisition.
The governance model I use for this doesn’t change with the tooling — ownership, environment boundaries, connector governance, least privilege, runtime protection, evidence. Agent 365 and Onyx are two implementations of controls 4–6. They don’t supply 1–3, and no product will.
Two products. Six surfaces. No single answer.
Map the surfaces first. Then buy.
If you’re building the surface map — or trying to work out what your Agent 365 licensing change actually obliges you to cover — let’s talk. The AI-Native Security Framework is where I start these conversations, and there are free templates in Resources.