You Have More Tenants Than You Think, and Agents Live in All of Them

If you’ve made an acquisition in the last few years, you are very likely running a Microsoft 365 tenant nobody on your current IT team has ever logged into.

Same story if you’re a multi-entity group with regional subsidiaries. Somewhere, a business unit spun up its own environment years ago, for a reason nobody remembers, and it’s still there.

One clarification before anything else. A “tenant” here means a Microsoft 365 or Entra cloud environment — a separate organizational instance in Microsoft’s cloud, with its own admins, its own licenses, its own identity boundary. That’s a different thing from the “multi-entity” setup inside a single Dynamics 365 instance, where one tenant hosts several legal entities for tax and reporting purposes. This post is about the first kind: tenants your organization operates, in full or in part, that nobody currently has a complete list of.

Microsoft’s own answer to that gap reached general availability on August 10, 2026. Microsoft Entra Tenant Governance, per Microsoft’s own overview, “enables you to get visibility across all your tenants and ensure they are configured to meet your security and compliance requirements.” That’s the stated purpose — visibility and configuration compliance across an org’s whole tenant footprint. One of the things that visibility is meant to fix is exactly the problem above: Microsoft’s own words describe the product helping “address security gaps and blind spots” and “reduce shadow-tenant risk, configure policies, monitor configuration drift.”

That a product like this shipped, with shadow-tenant risk named explicitly as one of the problems it addresses, tells you the gap isn’t hypothetical. It’s common enough that Microsoft built part of a control plane around it.

How Organizations End Up With Tenants They Didn’t Know They Had

Microsoft’s own documentation names the mechanism plainly: “Most organizations also have user-created ‘shadow IT’ tenants that central IT doesn’t administer and often doesn’t know about.”

A few concrete ways this happens. An acquisition brings in a company that already had its own Microsoft 365 tenant, and nobody ever formally decommissioned or merged it. A regional office signed up for its own trial years ago, and the trial quietly became production. A department bought its own licenses on a corporate card, outside procurement, to get something running fast.

None of these are exotic. They’re the ordinary residue of how organizations actually grow — through acquisition, through regional autonomy, through someone solving a problem quickly and never circling back. Each one leaves behind a tenant that still exists, still has admins, and isn’t on anyone’s current list.

This is also why a normal IT audit rarely catches it. An audit typically starts from a list of known systems and checks whether each one is configured correctly. A shadow tenant doesn’t fail that audit — it simply never appears on the list the audit started from. The gap isn’t a control that failed. It’s a control that was never asked to look in that direction.

What This Looks Like in a Manufacturing or Distribution Business

Here’s an illustrative scenario, not a documented case, to make the shape of the problem concrete.

A distribution company acquires a smaller regional competitor. The deal closes. Sales territories get merged. Financial reporting gets consolidated into the parent company’s Dynamics 365 environment within the first year.

The acquired company’s own Microsoft 365 tenant, though, keeps running quietly in the background. It still has a handful of licensed users. It still has its own admin account, held by someone who left the acquired company eighteen months ago and was never offboarded from that specific tenant, because nobody at the parent company knew that tenant was theirs to offboard.

Two years later, someone in that leftover tenant sets up a Copilot Studio agent to help process incoming purchase orders. It’s a reasonable thing to build. Nobody at the parent company’s security team ever sees it, because nobody at the parent company’s security team knows that tenant exists.

A second, equally illustrative version can hit a manufacturing group with several regional plants, without any acquisition at all. One plant standardized on Microsoft 365 years before the head office did, under its own regional IT contact, on its own tenant. Head office consolidated everyone else. That one plant’s tenant was never folded in, because it was already working fine on its own and nobody had a reason to touch it.

The Second Announcement: Constraining What Agents Can Do

In the same August 2026 roundup where Microsoft announced Tenant Governance, Microsoft Security Exposure Management released new guidance on what it’s calling agentic containment.

Microsoft’s own words: the guidance “helps organizations put controls in place before autonomous agent action expands across the environment,” focused on “constraining agent-initiated actions that occur without explicit user approval,” alongside hardening attack surfaces and governing identities and permissions.

This is real, useful guidance. It’s also important to be precise about what kind of control it is. Containment policy constrains what an agent can do inside an environment your security team already administers. It’s a rule applied within a boundary you already know about.

Where These Two Announcements Meet

Here’s the connection this post is making, stated plainly: Microsoft has not stated this link directly in its own materials. This is our own reading of two real announcements published in the same month, not a claim Microsoft has made.

The reasoning is simple, though. A containment policy binds agent behavior inside a tenant your organization actively administers. If an entire tenant sits outside that administration — because it’s a shadow tenant, or an inherited one from an acquisition nobody finished integrating — then any agent running inside it is outside the reach of containment policy. Not because the policy failed. Because it was never pointed at that tenant in the first place.

Agent governance, in other words, inherits whatever gaps already exist in tenant governance. A policy can only constrain what it can see.

This isn’t a flaw specific to Microsoft’s containment guidance. It would be true of any containment approach, from any vendor. Containment is fundamentally a rule enforced within a boundary. The question that has to come first, always, is whether the boundary you’re enforcing rules inside is actually the whole boundary — or just the part of it your organization remembered to include.

This Isn’t Every Organization’s Problem

To be fair, a single-entity company that has never acquired anyone and has no regional subsidiaries mostly doesn’t have this problem. One tenant, one admin team, nothing hiding.

The organizations this actually applies to are specific: multi-entity groups, holding companies, and anyone who has completed an acquisition in the last several years without a formal step to inventory and decommission the acquired company’s own cloud environment. If that’s not your situation, this post isn’t describing your risk.

Name the size of that group honestly, though. Acquisitions, regional subsidiaries, and departmental IT decisions made without central sign-off are not rare events at any one organization — they’re the normal texture of how mid-size and larger businesses actually operate over a decade or more. The population this applies to is closer to “most organizations past a certain size and age” than to some narrow edge case.

If it is your situation, though, the fix isn’t a new governance committee. It’s a discovery exercise, run once: find out what you actually have. Tenant Governance includes a related-tenants discovery capability built for exactly this; based on public reporting on the release, it works from signals such as guest sign-ins, shared app consents, and shared billing relationships to surface tenants an organization didn’t know it operated.

That’s a meaningfully different kind of work than writing a policy. A policy can be drafted in an afternoon by someone who already understands the risk. Discovery has to actually query the signals — who has been invited as a guest into which environment, which tenants share a billing relationship with the parent company, which multitenant apps have been granted consent where — and then someone has to look at the results and decide what to do with each one. It’s closer to an inventory count than a writing exercise, and it only has to be run properly once to change what every subsequent policy actually covers.

A Short List Before Trusting Any Containment Policy

Four questions to answer before assuming your agent governance covers your whole organization:

• Can you name every Microsoft 365 or Entra tenant your organization operates today, including any inherited through an acquisition?
• Has anyone actually run tenant discovery, rather than assuming the list in front of them is complete?
• Do your agent-containment policies apply organization-wide, or only to the tenants your central IT team already knows to manage?
• If a subsidiary or an acquired business unit stood up its own agent inside its own tenant tomorrow, would you find out before or after it acted?

That last question is the one that matters most in practice. Most organizations can’t answer it with confidence. Usually that’s because the discovery step never happened, not because anyone weighed the risk and decided it was acceptable.

A related but different question has come up before on this blog: once an organization knows the tenants it has, who is assigned to watch inventory, identity, and guardrails across them. That question presumes the list of tenants is already accurate. What this post is pointing at happens earlier — the list itself is frequently wrong, missing entries nobody has gone looking for, and no administrative role assignment fixes a list that was never complete to begin with.

If your organization has grown through acquisition or operates multiple regional entities, DAX Software Solutions can help you find out how many Microsoft 365 tenants you’re actually running, and make sure your agent governance policy reaches all of them. Get in touch if you couldn’t currently list every tenant your organization operates with full confidence.