The L1 ticket that never reaches a human: a password reset in Microsoft 365

The cheapest way to handle a Tier 1 password reset is to never let it become a ticket. The hard part isn't the reset — it's doing it without a human and still being able to prove, afterward, that the right thing happened for the right reason. This post traces one real Microsoft 365 password reset through Dex Go end to end, with one purpose: to show the skeptical CIO exactly where the policy gate sits, why no action executes without a matching policy, and what the audit trail captures when no human was ever in the loop.

We've described before that Dex Go resolves password requests. This goes a level deeper — into the governed-autonomy mechanics a CIO needs to see before trusting an agent with credentials.

The request: "I'm locked out and my phone is dead"

Start with the actual case, because the policy mechanics only matter against a concrete one. An employee opens Microsoft Teams and types: "I can't log in and I've lost my phone, so I can't get the MFA code either."

That single sentence is two problems stacked. The password may be forgotten, expired, or locked after failed attempts — and the registered MFA method is gone, which is exactly the case Entra ID's built-in Self-Service Password Reset doesn't close on its own. In a conventional shop this is now a ticket: a human reads it, asks the user the same questions, verifies identity, performs two changes in Entra ID, and closes it out. The work is routine. The latency and the cost are not.

Dex Go runs the same request through a loop — investigate, plan, execute, audit — with a hard checkpoint wedged between plan and execute. That checkpoint is the whole story.

The loop, and the gate inside it

Dex's canonical job is to investigate, plan, and execute. For a credential change, a fourth stage — audit — isn't an afterthought; it's part of the same transaction. And the move that separates governed autonomy from an "AI agent that resets passwords" is where the policy check happens: not at the end as a log entry, but in the middle, as a gate the action has to clear before it touches anything.

Investigate. Dex Go reads the requesting user's profile from Entra ID — department, group memberships, role, devices — and checks recent sign-in events. Did the password expire? Are there failed sign-in attempts indicating a lockout? Has the user already tried SSPR and failed? This surfaces facts the user wouldn't think to mention, and it does so by acting as the requesting user through delegated permissions, never with a broad shared API key.

Plan. Dex Go decides what it intends to do: in this case, verify identity through an alternate path, reset the password, and reset the lost MFA registration. The plan is a proposed sequence of concrete actions against named targets — not a vague intention. Nothing has changed yet.

The policy gate. Before any of that executes, each proposed action is checked against an explicit, structured policy. This is the checkpoint. No policy match, no action — and the block is enforced in the execution layer, in code, not as a line in the model's prompt. An agent can be talked into saying almost anything. It cannot be talked into executing an action the gate hasn't cleared, because the gate doesn't read the conversation.

Execute. Only actions that clear the gate run. Dex Go performs the reset against Entra ID, resets the MFA registration in the same flow, and delivers the new credential through the verified channel.

Audit. Every step is recorded — twice — with the policy that authorized it attached. More on that below.

Why no action executes without a matching policy

The gate isn't a single yes/no. Dex's policy engine evaluates a six-layer model, and an action only proceeds if it clears every applicable layer:

• Global — platform-wide rules that always apply (Dex never bypasses MFA; Dex never grants itself admin roles).
• Tenant — the organization's own standing rules for its Microsoft 365 environment.
• Target rules — what may be done to the specific object being touched. A standard user account and a privileged admin account are not the same target.
• Department — rules that vary by org unit (finance and engineering can carry different verification requirements).
• Action — the constraints on this action type: who may reset a password, under which complexity requirements, with which approvals.
• Runtime — conditions at the moment of execution: is this inside an allowed maintenance window, does Conditional Access apply, is the requester verified?

Run our locked-out user through it. The global layer confirms MFA won't be bypassed — so MFA recovery has to go through a sanctioned alternate path, not around it. The target-rules layer confirms this is the user's own standard account, not someone else's and not a privileged one. The action layer confirms a self-service reset with MFA recovery is permitted for this user's role and selects the verification path the policy demands — a manager confirmation in Teams, a recovery email, or a Conditional Access challenge. The runtime layer confirms the requester cleared that verification before the reset fires.

Now flip one fact. Suppose the account is a privileged admin account. The target and action layers no longer clear a silent self-service reset — the matching policy routes it for human approval. Suppose there's no policy at all covering the action. Then there is no best guess and no improvised workaround. The action is blocked, and where appropriate the request escalates to a human with the full investigation attached. That's the answer to the only question a CIO actually has about agentic credentials: what stops it from doing the wrong thing? The honest answer most vendors can't give is "a deterministic gate the model can't override." Dex can.

What the audit trail captures

A reset that no human touched is only trustworthy if it's more legible after the fact than one a human did touch. So Dex Go logs every action twice, in two systems that serve two audiences.

In Microsoft 365, the password reset and the MFA registration reset appear in the Entra ID audit log as the underlying identity events — the same place your security team already monitors. Nothing about agentic resolution moves the record out of the system your auditors trust.

In Dex Go's own activity log, the entry is richer than any ticket. It captures:

• the reasoning chain — what Dex Go investigated and what it concluded;
• the exact policy that authorized the action, by layer;
• the verification method used to confirm the requester's identity;
• the delegated identity Dex Go acted as, and the scope it was bounded to;
• the result, and confirmation delivered to the user.

Set the two side by side and you can answer who, what, when, under which policy, and on whose authority — for a reset that never generated a ticket and never interrupted an engineer. That's a stronger evidentiary trail than the typical human-handled L1 ticket, which records the outcome but rarely the reasoning or the authorizing rule. Dex never stores your Microsoft 365 data beyond what a task needs; it reads what's required and discards it, while the audit record of what it did persists.

This is L1 today, L3 on the same rails

A password reset is a clean L1 example precisely because it's routine and policy-bounded. But the loop — investigate, plan, clear the gate, execute, audit — is not an L1-only mechanism. Dex resolves L1 through L3 autonomously: deeper Tier 2 configuration changes and multi-step troubleshooting, and Tier 3 engineering-adjacent work that used to require a senior tech, all run through the same governed pipeline. The policy gate scales with the stakes. A higher-risk action simply has to clear more, or stricter, policy layers — and the ones that genuinely need human judgment escalate cleanly, with the full investigation attached. Only architecture and novel-incident calls are left for people.

This is the difference between a chatbot bolted to a help desk and an autonomous IT engineer. A copilot suggests; the human still acts and still owns the audit gap. Dex Go acts, under policy, and closes the gap itself. The ticket doesn't get resolved faster — it never gets opened.

What to take into your next vendor conversation

If you're evaluating anything that claims to "automate password resets" or "resolve L1 with AI," three questions separate governed autonomy from a demo:

1. Where does your policy check happen — before or after the action? If it's a log entry after execution, it's not a gate; it's a receipt. The check has to sit between plan and execute, in code.
2. What happens when no policy matches? "It does its best" is the wrong answer. "It blocks and escalates with context" is the right one.
3. What does the audit trail capture beyond the outcome? If it can't show you the authorizing policy and the reasoning, you can route work through it but you can't govern it.

For the step-by-step user-facing flow, see how Dex Go resolves password requests in Microsoft 365. To put the policy model against your own environment, Dex Go is where the loop lives.

A governed password reset isn't a smarter ticket. It's the absence of one — with a better record than the ticket would have left behind.