What does least privilege mean for AI IT automation?

Least privilege means the system holds only the access required for the specific action it is performing, at the moment it performs it, and nothing beyond that. For least privilege AI IT automation, that has a concrete test: the automation should not own a permanent, broadly-scoped identity of its own. Dex executes through delegated permissions - it acts as the requesting user or the admin who assigned the task, using their existing access - and every action must additionally match an explicit policy before it runs. No policy, no action.

Does Dex need Global Administrator access in Microsoft 365?

No. Dex does not require a standing Global Administrator role or a permanent service-principal identity with broad application permissions. Dex Pro executes through the admin's own OAuth token rather than a shared API key, so its reach is bounded by that admin's existing rights, and Dex Go can only act on the requesting user's own account - never on someone else's. The scope of what Dex can do is then narrowed further by the policy engine, which is enforced in code.

How does Dex prevent prompt injection from escalating its own access?

Because the guardrails are enforced in the execution layer rather than written as prompt instructions. Two constraints are hard-coded floors under every policy: Dex never grants admin roles, and never bypasses MFA. A malicious instruction hidden in a document or a chat message can influence what the model says, but it cannot reach past the code that decides whether an action is permitted to fire. The attempt simply fails to execute, and the refusal is logged like any other decision.

Can autonomous IT satisfy a zero-trust mandate?

It can, provided the autonomy runs inside your identity model instead of alongside it. Zero trust asks for per-request authorization against an identity, explicit policy, and least-privilege scope. Delegated permissions satisfy the first, the policy engine satisfies the second and third, and the audit log makes each decision reviewable after the fact. The failure mode to watch for in any tool is the opposite pattern: a standing privileged identity that authenticates once at install time and is trusted indefinitely.

What permissions does Dex need for Tier 2 and Tier 3 work?

The same kind - delegated, scoped, per-action - not broader ones. Dex resolves L1 through L3, and deeper work means more steps and more policy, not a wider standing grant. A Tier 3 investigation may read more signals and touch more services in sequence, but each of those steps is authorized individually against the policy set and executed under an existing identity. Depth of capability and breadth of standing privilege are separate design choices, and conflating them is how over-privileged automation gets shipped.

Least Privilege by Default: How Dex Acts Without Standing Admin Access

Ask an IT security team what worries them about autonomous IT and you rarely hear "what if it gets the answer wrong." You hear "what access does it need?" That is the right question. Any system that resolves IT work has to change things in Microsoft 365, and the standard way vendors get that ability - a permanent app identity holding broad tenant-wide permissions - creates exactly the kind of privileged account your zero-trust program exists to eliminate. This post lays out the alternative: how Dex enforces least privilege by default through delegated permissions and a code-level policy engine, why delegation alone is not sufficient, and what to ask any vendor about their permission model.

The objection is right: standing admin access is the actual risk

The security risk in autonomous IT is usually not the autonomy. It is the identity the autonomy runs as. A tool that installs a service principal with tenant-wide application permissions - read and write across directory, mail, files, devices - has created a permanent, unattended, always-on privileged account that nobody will ever offboard, and that no joiner-mover-leaver process covers. If it is compromised, the blast radius is the whole tenant.

Compare that to how you already govern humans. Your senior engineers do not carry Global Administrator by default. They have scoped roles, they elevate when necessary, the elevation is time-bound, and every action lands in the Entra ID audit log attributable to a named person. That is the control model your auditors already accepted. The problem with most automation is not that it is too autonomous; it is that it sits outside that model entirely, holding privileges no human on your team would be permitted to hold permanently.

So the design goal is not "make the system trustworthy enough to hold admin." It is "make the automation subject to the same permission discipline as everyone else."

Least privilege, defined for an autonomous IT engineer

Least privilege means holding exactly the access a specific action requires, at the moment it runs, and nothing more. Applied to an autonomous IT engineer, that translates into three properties you can inspect rather than take on faith:

It has no identity of its own. Dex executes through delegated permissions. Dex Pro acts as the admin who assigned the task, using that admin's own OAuth token rather than a shared API key. Dex Go acts as the employee who asked, and its boundary is hard: it can only act on the requesting user's own account, never on someone else's. There is no separate super-identity to compromise, because the action runs under an identity your directory already governs.

Its reach is narrowed further per action. Every action is also checked against an explicit policy before it executes, so the effective permission for any task is the intersection of what the identity can do and what policy allows.

Its scope is provable after the fact. Each action writes an audit entry naming the requester, the authorizing policy, the executed change, and the result - to your native Microsoft 365 logs and to Dex's own Activity Log. Least privilege you cannot verify is a claim; least privilege that reconciles against Entra ID is a control.

Diagram of Dex using a scoped per-user delegated permission for one action instead of standing global admin access

Delegated permissions are necessary but not sufficient

Security-minded readers spot the gap immediately. If Dex acts as an admin who holds a powerful role, delegation on its own has not reduced anything - it inherited the privilege rather than creating a new one.

That is why delegation is only the first of two mechanisms. The permission model answers whose authority is this action running under. The policy engine answers is this specific action allowed at all. You need both, and a vendor offering only the first is describing traceability, not restraint. In practice: connect a narrowly-scoped admin account rather than a break-glass Global Administrator. That is ordinary integration hygiene.

Where least privilege gets enforced: the policy engine, in code

Dex's guardrails live in the execution layer, not in the model's prompt. It is the most important architectural distinction in the category, and testable in a demo. A prompt-level rule is an instruction to a language model - a preference a sufficiently clever request may talk past. A code-level rule is a branch in the execution path: the action either matches an authorization or it never fires.

Dex evaluates every action against a six-layer structured policy model - Global, Tenant, Target Rules, Department, Action, Runtime - and the rule underneath it is absolute: no policy, no action. Target Rules and Department do most of the least-privilege work in practice, because they answer the question a role assignment cannot: not just "may this admin change group memberships," but "may this admin change these groups, for these departments, in this context." Sensitive and irreversible actions route through explicit human approval.

A request that matches no policy does not get improvised. It halts and escalates to a human with full context attached.

The two floors nothing can cross

Two constraints sit beneath every policy as non-negotiable hard stops: Dex never grants admin roles, and Dex never bypasses MFA. Both are enforced in code, which is what makes them meaningful. A system that could grant roles could grant itself a role, putting privilege escalation one convincingly-worded request away. Closing that path in the execution layer means the shortest route to escalation does not exist, regardless of what any prompt, document, or injected instruction says.

These floors also close the quieter failure mode: automation that solves an access request by widening access permanently. Dex cannot resolve "I need into this SharePoint site" by making the site open, or fix an MFA problem by turning MFA off. The paths that look more helpful and leave the tenant weaker are closed by design.

L1 through L3 without widening the blast radius

Depth of capability and breadth of standing privilege are independent choices, and the security conversation goes wrong when they get conflated. Dex resolves L1 through L3: password and MFA recovery and access requests, and also multi-step configuration work, deeper troubleshooting, and engineering-adjacent tasks that used to need a senior tech. The reasonable assumption is that Tier 3 capability demands Tier 3 privilege, permanently held.

It does not. A deeper task means more steps, each one authorized on its own against the policy set, executed under an existing governed identity, and logged individually. A Tier 3 investigation that reads signals across Entra ID, Exchange Online, and Intune before changing one configuration value is a sequence of individually-authorized actions, not a single elevated session. That sequence is also why the record of a complex resolution is more legible than the equivalent human ticket, where the investigation happens off the record entirely - the fuller case is in why the audit trail is the product.

Two choices reinforce this at the data layer: per-org isolated databases and encryption keys, and a zero-data-retention model in which Dex reads what a task requires and discards it. Less retained data is less privilege in the way that matters during an incident.

Why zero trust makes this a procurement question

Zero trust does not have a carve-out for AI IT automation. Its core requirements - authenticate per request, authorize against explicit policy, grant the least scope that works, assume breach - apply to a non-human actor exactly as they apply to a contractor. A standing service principal that authenticates once at install time and is trusted indefinitely fails the first requirement outright.

That makes the permission model a procurement gate, not an implementation detail to sort out after the pilot. It is also the fastest way to shorten a security review: an architecture that runs inside your existing identity and policy model is one an assessor can evaluate with tools they already have, rather than one that needs a new exception. Dex is built by the team behind SysAid, whose platform is ISO 27001, ISO 27017, and ISO 27018 certified and SOC 2 Type 2 compliant with annual third-party audits; Dex's own attestations are in process. The architecture and its controls are documented on our security page, and specific compliance requirements are best routed to our team directly.

Five questions to ask about privilege

Five questions separate a real least-privilege design from a permission dialog with good copywriting:

"What identity do actions execute as?" You want a name - a user or an admin in your own directory. "Our platform's service account" means a standing privileged identity you now own the risk for.
"Which permissions does the install request, and which are application versus delegated?" Application permissions apply tenant-wide with no user in the loop. Read the consent screen; it is the most honest document in the sales process.
"Are the guardrails in the prompt or in the code?" If the answer is "we instruct the model not to," that is a preference, not a control.
"Can it grant roles or change MFA state?" Anything that can grant privilege can grant itself privilege. The correct answer is a flat no, enforced below the model.
"Show me one action's record end to end." Requester, authorizing policy, executed change, result - reconciled against the native Microsoft 365 log. If the only record is the tool's own summary of itself, you have a claim rather than evidence.

A vendor who answers all five cleanly is describing governed autonomy. A vendor who deflects to accuracy percentages is asking you to cover a permission model with optimism.

The reframe

Over-privileged access is the strongest objection to autonomous IT, and it should stay strong - it has disqualified plenty of tools that deserved it. But the objection is about architecture, not autonomy, and architecture is inspectable. An autonomous IT engineer that runs as your people, under your policies, with every action authorized individually and written to your logs is not asking for more trust than your existing admins get. It is asking for less standing privilege than most of them have.

Dex does not need to hold admin to do admin work. It needs permission for one action, at the moment it takes it, and a record that proves what it did.