What is multi-tenant IT automation with least privilege?

It is the ability to resolve IT work across many client tenants from one place without holding broad, permanent admin access in each of them. Dex does this as a single control plane: it acts through delegated permissions rather than a standing service account, and every individual action must match the explicit policy of the tenant it touches before it runs. No policy, no action.

Why does adding admin seats increase risk for an MSP?

Each standing admin account in a client tenant is a privileged identity that can be phished, reused, or forgotten, and each one has to be reviewed, rotated, and offboarded. When an MSP scales by giving more technicians admin rights in more tenants, the count of privileged identities grows roughly as technicians times tenants. Audit scope and breach exposure grow with it, even if ticket volume per client stays flat.

How does Dex apply different policies to different client tenants at the same time?

Every action is evaluated against a six-layer policy model: global, tenant, target rules, department, action, and runtime. The tenant layer means each client carries its own rules, so the same request type can be allowed in one tenant, routed for approval in another, and refused in a third. The check happens per action in the execution layer, in code, not once at login and not in a prompt.

Does zero standing access mean my technicians lose admin access?

No. Zero standing access describes the automation and the growth model, not a lockout of your senior engineers. Dex holds no permanent privileged identity of its own in any client tenant, and growing the book no longer requires handing more technicians permanent admin rights in more tenants. Your engineers keep the access their roles need for policy design, exceptions, and the hard cases.

Is Dex only handling Tier 1 work across tenants?

No. Dex resolves L1 through L3: password, MFA, and access requests, plus Tier 2 and Tier 3 configuration, troubleshooting, and engineering-adjacent work. Deeper work means more steps, and each step is authorized individually against that tenant's policy. Genuine architectural or judgment calls escalate to a human with the full investigation attached.

One engineer, 40 tenants, zero standing access: the multi-tenant control plane nobody scales with more admins

Most MSPs scale the same way: win a client, stand up the tenant, and give the technicians who support it admin rights there. It works until you count what you have built. Forty clients with three technicians each is 120 standing privileged accounts, each one a credential to phish, a role to review, and a line on someone's audit. This post explains why that model is the objection that quietly stalls MSP deals with CFOs and security reviewers, and how multi-tenant IT automation with least privilege works when one Dex control plane runs every tenant at once and matches each individual action to that tenant's policy. The short version: growth should add policies, not keys.

The admin-seat model multiplies keys with every client

The standard MSP scaling model treats privilege as a byproduct of headcount. A new client means delegated admin relationships for the team that supports it. A new technician means admin rights in every tenant they cover. Nobody decides to build a large privileged attack surface. It accumulates one onboarding at a time.

Here is a simple illustrative model. Use your own numbers; the structure holds.

40 client tenants
 × 3 technicians with admin rights per tenant
 = 120 standing privileged identities

Grow to 60 tenants, hire 2 more technicians:
 60 × 4 = 240 standing privileged identities

Client count grew 50%. Standing privilege doubled. Every one of those identities needs a joiner-mover-leaver process, periodic access reviews, MFA enforcement, and an answer when a client's auditor asks who in your company can change their directory. Microsoft's own move from broad delegated admin to granular, time-bound delegated admin privileges (GDAP) for partners points the same way: the industry already agrees that broad, permanent partner access is the risk.

We have covered the economics of this book before. The MSP tenant math showed how one engineer can supervise 40 tenants once routine work stops scaling with headcount, and the MSP onboarding backlog priced what pending access requests cost across the same 40 tenants. This post is about the part those numbers leave out: what you are trusting to do the work, and under which rules, in 40 tenants at the same time.

Why the control-plane question stalls MSP deals

When an MSP evaluates autonomous IT, the operations lead usually likes the math. Then two people join the call.

The CFO asks what happens to liability. If one tool can act in every client tenant, a single mistake or compromise is now a 40-client incident instead of a one-client incident. Contracts, cyber insurance, and client trust are all priced against that blast radius.

The security reviewer asks what identity the tool runs as. If the answer is a vendor-owned service principal with tenant-wide application permissions installed in each client, the MSP has just added 40 new standing privileged identities that nobody in the building will ever offboard.

Both objections are correct about the tools they describe. Neither is an argument against autonomy. They are arguments against a specific architecture: broad standing access, authorized once at install time, with guardrails that live in a prompt.

What a multi-tenant control plane actually is

A multi-tenant control plane is one place where work for every client is planned, authorized, executed, and recorded, without that place owning permanent admin rights in any of them. For Dex, that means three properties working together.

Delegated execution. Dex Pro acts through the admin's own OAuth token, not a shared API key or a vendor service account. Its reach in any tenant is bounded by an identity that already exists in your model. Dex Go, the employee side in Microsoft Teams and Slack, can only act on the requesting user's own account.

Per-org isolation. Each client organization gets its own isolated database and encryption keys. One control plane does not mean one shared pool of client data.

Per-action policy. Every action Dex takes must match an explicit, structured policy for the tenant it is acting in. No policy, no action. That check is enforced in code, in the execution layer, so a malicious instruction in an email or document can change what the model says but not what is allowed to run.

The first two properties were the core of least privilege by default, which covered how Dex acts without standing admin access in a single organization. The third is what changes when there are 40 organizations instead of one.

Before and after grid showing 40 tenants each with a standing admin account marked by red keys, then the same 40 tenants managed by one Dex control plane with every action matched to policy and no standing access

Per-action policy across many tenants at once

Least privilege in one tenant is a permission model. Least privilege across 40 tenants is a policy model, because the same action can be fine for one client and a contract breach for another.

Six layers, every action

Dex evaluates each action against six policy layers: Global, Tenant, Target Rules, Department, Action, and Runtime. The global layer holds the floors that apply everywhere: Dex never grants admin roles and never bypasses MFA. The tenant layer is where each client's rules live. The lower layers narrow from there, down to the runtime conditions of the specific request.

The important word is each. Authorization does not happen once when a technician logs in, or once when a tenant is connected. It happens every time Dex is about to change something, against the rules of the tenant it is about to change.

One request type, three tenants, three answers

Take one common request: add a user to a SharePoint site. The same day, it arrives from three clients.

A 60-seat accounting firm. Policy allows membership changes on project sites when the requester's manager is the site owner. Dex investigates the group structure, confirms the condition, executes, and logs it.
A healthcare practice. Policy marks the patient-records site as approval-required. Dex prepares the change, routes it to the named data owner, and executes only after approval.
A manufacturer with a no-guest rule. The requester is an external contractor. Policy forbids guest access to that site. Dex refuses, records the refusal, and escalates with context so a human can decide whether the policy should change.

Same action type. Same control plane. Three different outcomes, each one traceable to a specific rule in a specific tenant. That is the difference between scaling with policy and scaling with admin seats: a technician with admin rights in all three tenants could have made all three changes, and the only thing stopping the wrong two would have been memory.

L1 through L3 under the same gate

A fair question from a security reviewer: fine for access requests, but what about the deep work? Dex resolves L1 through L3, including Tier 2 and Tier 3 configuration and troubleshooting, such as tracing why a Conditional Access policy blocks a contractor or untangling nested group inheritance across Entra ID and Exchange Online.

Deeper work does not get a wider grant. It gets more steps, and each step passes through the same per-action gate for the tenant it touches. Dex Pro shows each action before executing it, with "Approve Always" available once a technician trusts a repeated pattern. Every executed action lands in both the client's Microsoft 365 audit log and Dex's own activity log, so the record of a complex resolution is evidence in the client's own system, not a summary written by the tool.

What "zero standing access" means here, and what it doesn't

Precision matters in a security conversation, so here is the claim exactly.

It means Dex holds no permanent privileged identity of its own in any client tenant, and growing from 40 tenants to 60 does not require handing more technicians permanent admin rights in more tenants. The work scales through the control plane. The policies scale per client. The key count does not have to.

It does not mean your senior engineers lose access, or that delegated execution makes the identity it runs under irrelevant. The admins whose authority Dex acts within still need the hygiene you would apply anyway: MFA, scoped roles, regular review. The difference is that you can keep that group small while the book grows.

Five questions to ask before you scale the book

Use these on your own model and on any vendor:

How many standing privileged identities exist across all client tenants today? Count technicians times tenants. Then model next year's growth.
When a tool acts in a client tenant, whose identity is it? A name in your directory, or a vendor service principal?
Is authorization per action or per session? Once at login is not the same as every change.
Can one rule produce different answers in different tenants? If every client runs the same policy, you are trusting that every client's contract says the same thing.
Where is the record? In the client's Microsoft 365 audit log, or only in the tool's own dashboard?

The reframe

The MSP growth model has always tied three things together: more clients, more technicians, more keys. Autonomous IT breaks the first link, and the earlier posts in this series showed what that does to margin. The control plane breaks the second. One engineer can supervise 40 tenants because the routine work runs through Dex, and the CFO and security reviewer can sign off because every action in every tenant is matched to that tenant's policy before it runs.

Every new client used to mean a new set of keys. With Dex, it means a new policy set. To see per-tenant policies working across a live multi-tenant setup, start with Dex Pro.