Right Action, Right Person: How an AI Agent for MSPs Checks Before It Acts

When people worry about an AI agent resetting passwords, they usually picture one failure: an attacker convincing the agent they’re someone else. That’s a real risk, and verification exists to stop it. But it’s only one of the ways an agent can do the wrong thing.

The agent can verify the right person and act on the wrong account. It can match the request to the wrong client. It can build a correct plan and then act on it after something changed. Getting “right action, right person” right means checking all of these, every time, before anything changes.

Here’s the chain of checks we think an AI agent for MSPs needs, and how Mizo handles each one.

1. Who is actually asking?

Before anything else, the agent has to know which contact the request came from. That’s harder than it sounds on an MSP desk: tickets arrive from shared mailboxes, forwarded threads, phone calls and portals, and the sender isn’t always the person with the problem.

Mizo resolves the requester against the contact record already in your PSA, not against whatever name was typed or said. For tickets from catch-all mailboxes and unknown senders, contact assignment matches the right contact and company first. And automatic resolution only runs when the ticket can be confidently linked to a specific end user; low-confidence matches aren’t diagnosed at all.

Why it matters: every later check depends on this one. Verify the wrong contact and the rest of the chain is checking the wrong person.

2. Are they who they say they are?

This is the step most people mean by verification. The rule is simple: never trust what the requester tells you during the request.

Mizo’s End User Verification Agent sends a challenge to a device or address registered before the request existed: a Microsoft Entra MFA push with number matching, a Duo push for clients on Duo, or a single-use, time-limited link to the email or mobile number on file. A challenge never goes to a number given during the call or in the ticket, and Mizo never uses security questions. Today, verification is mandatory before password resets.

We covered the full flow in how Mizo verifies end users and the live-call version in verifying identity on a phone call.

3. Are they allowed to ask for this account?

Here’s the check that gets skipped. A verified requester is not automatically authorized to act on any account.

The classic case: an office manager asks to reset a colleague’s password because the colleague is on a plane. The office manager might pass verification perfectly. They’re still asking about someone else’s account.

In Mizo, the resolution plan includes an identity check that the requester is authorized to make this request, for this account. When someone other than the account owner asks, and nothing authorizes that, the plan carries a visible security warning. If the check fails outright, no plan is created, and the ticket shows “Plan could not be created” with the reason.

Opinion: “on behalf of” requests are where social engineering lives. Your policy for them should be written down per client, not left to whoever picks up the ticket.

4. Is it the right account in the right tenant?

An MSP manages many clients, and many of them have a user called John Smith. The agent has to act on the right account, in the right client’s tenant, and nowhere else.

With Mizo, Microsoft 365 access goes through GDAP relationships you manage, with each tenant linked to its PSA company. The resolution plan names the specific account it will act on, and the target account’s address has to belong to that client’s list of verified domains. A client without a Microsoft 365 connection never gets a plan at all.

5. Is it still true at the moment of acting?

Plans take time. Between the moment a plan is drafted and the moment it runs, the account could change, the domain list could change, or someone could revoke write access.

So the check has to happen again, right before acting. When a technician clicks Apply resolution plan, Mizo re-confirms that the account still matches the approved plan, the domain is still approved and write access is still on. If anything changed, it stops before making changes and shows the reason, for example “the target user no longer matches the approved resolution plan.”

6. Does the result reach the right person?

The fix isn’t finished when the password is reset. The temporary password has to reach the person who should have it.

For a Microsoft 365 reset, Mizo resets the password, forces a change at next sign-in and emails the temporary password to the ticket’s contact, then logs a note. If the reset succeeds but the email fails, it says so on screen and shows the temporary password to the technician so they can deliver it manually; it isn’t stored for later. That’s one more reason step 1 matters: the ticket’s contact has to be the right person.

7. Can you prove all of it afterwards?

If a client, auditor or cyber insurer asks how a specific reset was verified, “the AI checked” isn’t an answer.

Mizo writes the verification method, outcome and timestamp to the ticket as structured fields, and the resolution plan with its reasoning stays on the ticket. That’s what turns a set of checks into evidence.

Where the human still matters

All of these checks are about the requester and the target account. None of them decide who inside your MSP is allowed to press the button: in Mizo, any technician who can open the ticket can click Apply. So treat reviewing the plan before clicking as the real approval moment — read the account name, read any security warning, and only then apply.

Opinion: automation should make the approval faster, not thoughtless. One informed click is the goal; a reflexive one isn’t.

For how verification fits with the rest of Mizo’s agents, see the AI agent for MSPs.

👉 Walk through the full check chain on a test ticket in your own PSA. Book a demo.

FAQ

How does an AI agent know it’s acting for the right person?

It resolves the requester against the contact on file, verifies them through a challenge to a device or address registered before the request, and checks they’re authorized for the specific account. Mizo does all three before a plan can be applied.

What happens when someone asks to reset a colleague’s password?

In Mizo, the plan carries a visible security warning when the requester isn’t the account owner and nothing authorizes the request. If the identity check fails outright, no plan is created.

Can an AI agent act on the wrong client’s account?

It shouldn’t be able to. Mizo acts only in tenants connected through your GDAP relationships, linked to the right PSA company, and the target account must belong to that client’s verified domains.

Does Mizo re-check anything before it makes a change?

Yes. When a technician clicks Apply, Mizo re-confirms the account, the verified domain and write access, and stops with the reason if anything changed since the plan was drafted.