A caller opens a ticket saying they are locked out. The name matches your client directory. They sound stressed, they have a meeting in ten minutes, and they would really appreciate a reset link sent to a different number.

Your AI help desk has already written the perfect cheerful response. Lovely. It still has no proof that the caller owns the account.

Here’s the deal

On November 6, 2026, Atomicwork announced a marketplace of prebuilt AI coworkers for IT and security work, including access operations. Its own product explanation says the workers are tested against role-specific tasks and can operate with defined tools and permissions. That is the vendor’s description of its product, not a promise that any particular client’s account recovery process is safe by default. Read Atomicwork’s November 6 explanation.

The bigger question for a managed service provider is where the assistant’s job ends. NIST’s Digital Identity Guidelines set out account recovery requirements, including appropriate recovery methods and account notifications. Microsoft Entra documentation describes self-service password reset using administrator-approved registered authentication methods. Neither source says a convincing chat message is identity verification.

What this actually helps you do

Create one safe route for a client employee’s password reset request: intake, identity checks through the approved system, a technician handoff if recovery fails, and a clear record of who authorized any sensitive action. That gives your team a better chance of resolving genuine lockouts without handing an impostor the keys.

The niche use case: a managed IT provider with several small business clients

Picture an MSP serving dental offices and professional-service firms. A receptionist at one client cannot sign in. The request arrives by email with a new phone number, but the client’s directory lists another number. The assistant has read the ticket and recognizes the employee’s name. It must not change the recovery destination just because the request sounds believable.

The practical result is a routed ticket that says which organization, which account, which approved recovery path, what is missing, and who must review it. Keep passwords, one-time codes, recovery codes, and security answers out of the ticket summary.

Exactly three benefits

Step-by-step: build the identity-first help desk route

1. Choose one ticket type. Start with standard employee password resets for one client. Leave administrator accounts, executive exceptions and device recovery outside this first test.
2. Define the allowed AI actions. Permit reading the relevant request, checking approved help articles, and drafting ticket notes. Do not give the assistant permission to change passwords, replace authentication methods, or grant access.
3. Match the account without claiming identity proof. Match the requested username to the correct client directory. If the requester gives a new phone number or email, record the mismatch as a flag, not as a replacement contact.
4. Use the client’s established recovery method. For an eligible Microsoft Entra tenant, direct the employee to the configured self-service password reset path. Microsoft says the service checks the methods that the user registered and the administrator enabled. Never collect one-time codes in a chat.
5. Hold exceptions for a technician. If the employee cannot use an approved method, the identity is uncertain, or the request concerns a privileged account, pause. The technician follows the client’s documented recovery policy and independently verified contact records.
6. Record the result without exposing secrets. Capture whether self-service succeeded, whether the request was denied or escalated, the reviewer, the timestamp, and the account-recovery notification status. Avoid recording actual passwords or codes.
7. Test before release. Run synthetic tickets for normal lockouts, a fake new-number request, and a privileged account. Confirm that unsafe cases stop and no access is changed by the assistant.

Tips and tricks

• Keep separate client instructions. One tenant’s recovery rules may differ from another’s.
• Give every exception a named owner and a reason. “AI said yes” is not a reason.
• Link the ticket to an approved help article. If the policy changes, update that source before using it again.
• Use existing logs to identify which system or technician actually performed the change. A related access-log example shows why keeping actors and permissions separate matters.

Common mistakes

• Treating a matching name or an internal-looking email as sufficient proof.
• Sending reset links to a newly supplied contact without independent verification.
• Putting one-time codes into tickets or asking an assistant to read them.
• Measuring success only by how quickly tickets close, rather than checking unsafe actions and user outcomes.

Human review checklist

• The correct client tenant and account have been identified.
• No password, recovery code or one-time code appears in the ticket.
• The user’s identity was checked through approved methods, or the exception was held.
• Privileged and contact-change requests reached an authorized reviewer.
• The ticket names the person or system that completed the action.
• Required account notifications and the case outcome are recorded.

How to measure success

For the first two weeks, compare a small sample of cases against your existing process. Track correctly routed requests, unsafe actions prevented, time until a technician receives a complete exception, and resets completed through approved recovery methods. Count them from actual tickets and identity logs. Do not make up a savings number because a dashboard has a pretty chart.

Also review false alarms. If every legitimate lockout is escalated, the rules need work. For review handoffs in another business setting, see how to keep a human approval lane.

FAQ

Glossary

Identity provider

The system that manages user accounts, sign-in methods, and access.

Self-service password reset (SSPR)

An approved path for users to recover their own account using registered authentication methods.

Privileged account

An account with elevated permissions that needs more protective review.

Account recovery

A documented process for returning access to the rightful user when normal sign-in does not work.

Sources and further reading

• Atomicwork, “Introducing Certified AI Coworkers,” November 6, 2026. The current product development behind the discussion.
• Atomicwork press release, November 6, 2026. Details on its access-operations AI roles and controls.
• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management. Account recovery and notification requirements.
• Microsoft Learn, How self-service password reset works. Registered authentication methods and tenant policies.