---
Title: "How to automate self-service password resets and access requests with AI agents"
Url: "https://devrev.ai/blog/how-automate-password-resets"
Published: "2026-10-22"
Last Updated: "2026-10-22"
Author: "DevRev Editorial"
Excerpt: "A reset cannot be undone, a grant can be revoked, and onboarding can fail system by system. See where approvals go and what to rehearse first."
Reading Time: 12
---

# How to automate self-service password resets and access requests with AI agents

**TL;DR**

- To automate self-service password reset safely, let the AI agent take the request, keep the identity check in a channel it can’t see, and let the identity provider do the reset.
- A reset can’t be undone, an access grant can be revoked, and a new-hire bundle fails one system at a time. So each gets its own check before anything changes.
- Put the approval before the change, and rehearse a revoke before go-live.

A dangerous call to your help desk sounds polite and rushed, like an executive locked out before a board meeting. Scattered Spider, a group that breaks in by impersonating employees, works that way. So before an AI agent touches self-service password reset, decide which system performs the reset and which channel checks identity.

The Cybersecurity and Infrastructure Security Agency (CISA) updated its [advisory on the group](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a) in July 2025. It says members talked help desks into moving multi-factor authentication (MFA) to their own devices. In the advisory’s words, they “posed as employees to convince IT and/or helpdesk staff to provide sensitive information, reset the employee’s password, and transfer the employee’s MFA to a device they control.”

So our opinion is unfashionable: the first skill your AI agent needs is restraint. We designed Computer, by DevRev, our AI teammate, around that restraint for self-service password reset: the agent files a work item, and a separate workflow runs the identity check and the reset.

## Which self-service password reset approach fits your identity setup?

The right starting point depends on where your resets and approvals already run, and each comes with a check to run before go-live.

| If your team… | Start with | Check before go-live |
| --- | --- | --- |
| Wants one agent to take resets and access requests in chat | Computer: the agent files a work item, and a separate workflow does the reset | Which internal agents are live, and which skills need approval |
| Wants resets to stay in the identity provider | Self-service password reset in Microsoft Entra ID or Okta | The methods employees register, and Entra’s two-gate policy for admins |
| Needs access that ends on its own | Okta Access Requests | Who approves, and when the grant expires |
| Already runs requests in ServiceNow, Jira Service Management, or Freshservice | That tool’s approval step | What happens when an approver doesn’t answer |
| Wants an agent layer beside the service desk | Moveworks | Where approvals land |
| Can’t get approvals answered in time | “Agent files, person fulfills” | Who fulfills each request, and how long it waits |

## Six-step rollout for resets, access requests, and onboarding

Roll out in six steps: rank requests by risk, start the agent on a low-risk request, give it narrow write access, approve before every write, deploy where people already ask, and rehearse a revoke before go-live.

This is desk research: we wrote the steps from vendor documentation and our own pages, all re-read on October 16, 2026, and didn’t run these setups ourselves.

### Step 1: Rank your 10 most common requests by volume and risk

Score last quarter’s 10 most common request types:

- **Low** – reversible and low privilege, like a distribution list.
- **Medium** – reversible, but it opens data, like a finance app.
- **High** – irreversible or privileged, like an admin’s MFA reset.

Automate high-volume, low-risk requests first. Resets feel like the obvious opener, but every one scores “High,” so in step 2 the agent only files them.

Amar Gautam, Head of DevRev Labs, describes the employee who still ends up at the help desk: “They’re locked out, and what they want is their access back.”

“Even the oldest request in the book is an access request in disguise.” – Amar Gautam, Head of DevRev Labs, in [the invisible half of employee self-service](https://devrev.ai/blog/employee-self-service-beyond-the-ticket)

**Approval gate:** every system owner signs off before anything ships.

Our [IT Self Service page](https://devrev.ai/use-cases/service-desk-automation) says Computer’s agent will “spot repeat issues, flag gaps in your knowledge base,” which gives you a running list to rank. Freshservice, Freshworks’ IT service desk, advises in its guide to pre-built AI agents to start with “the two or three workflows that cover your highest-volume requests.” During implementation, Moveworks, an AI assistant for employee support, mines ticket data to recognize the software people request.

### Step 2: Build the first agent on a low-risk request, and keep resets out of its hands

Our [IT Self Service page](https://devrev.ai/use-cases/service-desk-automation) also lists no-code templates “for common tasks (like password resets and software access),” and Agent Studio is where your team builds, tests, and deploys them. Before you switch on a reset template, decide who holds the credentials.

In [Powerless by design](https://devrev.ai/blog/powerless-by-design), Shlomi Vaknin, our Senior Architect, writes that our agent “has zero ‘write’ authority over identity systems.” The agent files a work item. A separate workflow then confirms the employee on a registered device, checks that they’re entitled to the change, and, as he describes it, calls the identity provider’s API to perform the reset.

Our connectors for the identity providers Okta and Microsoft Entra ID only import data, so ask us which reset actions your workspace supports. For MFA resets, a manager confirms, and nobody approves their own request.

“The agents that survive contact with real attackers won’t necessarily be the smartest ones. They’ll be the ones that were never handed the keys.” – Shlomi Vaknin, Senior Architect at DevRev, in [Powerless by design](https://devrev.ai/blog/powerless-by-design)

**Approval gate:** verification happens in a channel the agent never sees.

Other tools keep the password out of the chat, too. Moveworks, which ServiceNow, an AI and workflow software company, [bought in December 2025](https://cxtoday.com/servicenow-moveworks-acquisition), says in its documentation that it doesn’t handle or ask for the password in chat. It links out to the reset portal instead.

ServiceNow’s Virtual Agent offers several verification options, including security questions, and the admin picks which ones run. SysAid, an IT service management vendor, warns in its documentation that security questions “can often be guessed or found through social engineering.” If your reset flow offers them, switch them off.

Okta Threat Intelligence reported in July 2026 that one intrusion cluster phones targets while it triggers self-service resets, a finding the technology news site [iTWire also covered](https://itwire.com/business-it-news/security/oktas-threat-hunters-say-ai-has-put-old-identity-attacks-on-fast-forward-and-the-fix-starts-at-enrolment). In Okta’s words, an attacker in that position “will always choose the weakest, most ‘phishable’ method.”

The methods employees register for self-service password reset (SSPR) are where the risk sits. [CISA’s advisory](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a) tells organizations to “implement FIDO/WebAuthn authentication or Public Key Infrastructure (PKI)-based MFA,” because those methods resist phishing. The National Institute of Standards and Technology (NIST) [warns in its authentication guidelines](https://pages.nist.gov/800-63-4/sp800-63b.html) that “to the extent that authenticator recovery is human-assisted, social engineering attacks also pose risks.”

Enrollment is where you fix this. One IT reviewer at a mid-market higher-education organization describes requiring a stronger factor at first setup in ManageEngine’s ADSelfService Plus, a self-service password tool for Active Directory. G2 notes the seller requested the review:

“One of the main benefits is that we can easily populate users’ personal email addresses and phone numbers in the system, so they can use those factors during the initial setup. We can also require them to configure a stronger factor as part of that same initial setup process.”

[Verified user in higher education. G2, June 2026↗](https://www.g2.com/products/manageengine-adselfservice-plus/reviews/manageengine-adselfservice-plus-review-13019236)

One sysadmin on Reddit doubts AI belongs in resets at all, and the point deserves an answer:

“AI as a self-service replacement for password resets feels like forced AI adoption. If a user couldn’t figure out SSPR, then they’re still calling the helpdesk. All you’re getting is a new attack surface.”

[u/VB0101, r/sysadmin, May 2026](https://www.reddit.com/r/sysadmin/comments/1toxgrk/ai_for_internal_it_supportpassword_resets_is/oo4mjyl/)

That’s a fair hit on an agent that performs resets. Ours files a work item, so a talked-into agent has nothing to hand over.

### Step 3: Connect the systems it reads and writes

Give the agent wide read access and narrow write access. Our [Agent Studio post](https://devrev.ai/blog/agent-studio) says each Computer skill runs “under an execute-as-user permission model,” and our [Agent Studio reference](https://support.devrev.ai/en-US/devrev/article/kIjLyjeT-agent-studio-reference) lists that setting as on by default. Our [post on AI agent authentication](https://devrev.ai/blog/ai-agent-authentication) explains that we also mint per-skill credentials, “issuing short-lived, least-privilege tokens at execution time.” The reset itself runs in the workflow, through a connection you set up with its own keyring.

**Approval gate:** every connection has a named owner who can switch it off.

Jira Service Management is Atlassian’s service desk. Its automation has paired actions for Entra ID, such as “Add user to group in Entra ID” and “Remove user from a group in Entra ID,” so each grant has an action that reverses it. Freshservice’s pre-built agent workflows won’t run until each app is connected with valid credentials.

### Step 4: Put the approval before the write

Our [Agent Studio page](https://devrev.ai/agent-studio) says, “If the stakes are high, require human approval before your agent takes action.” In Agent Studio, the closest switch is the [“Needs Approval” setting](https://support.devrev.ai/en-US/devrev/article/kIjLyjeT-agent-studio-reference) on each skill, which ships switched off. Once switched on, it holds the skill until the requester confirms. That’s a confirmation, not an approval.

A manager’s or app owner’s sign-off is a separate step, in our native approvals or in Okta. The approver’s card should show who asked, what they get, for how long, and which policy allowed it. Leave out “for how long,” and you’ve built a permanent grant by accident.

**Approval gate:** the requester is never on the approver list.

Time-bound grants, often called just-in-time access, end on their own. In Okta Access Requests, access is revoked automatically when the request expires.

ServiceNow’s Ask for Approval can decide on a timer instead. Its documentation gives an example where, if no approver responds within the window, the system automatically approves the request. That suits an outage, but don’t let a timer approve access.

Send approvals to the app or data owner. A manager knows the person, but only the owner knows what the access opens.

### Step 5: Deploy in the channel people already use

Our [Agent Studio post](https://devrev.ai/blog/agent-studio) says agents deploy “across channels – email, Slack, and WhatsApp – from the same configuration,” and [our help center](https://support.devrev.ai/en-US/devrev/article/LhjCUxm2-agent-studio) lists those channels for customer experience agents. As of October 16, 2026, it still marks internal agents “coming soon,” so check with us which of yours are live, and where. Keep the request, the verification, and the approval in separate channels, so one hijacked chat can’t do it all.

**Approval gate:** approvers answer in a signed-in session, never in the requester’s thread.

Jira Service Management approvers can decide in Slack or Microsoft Teams, so check the approval lands in the approver’s own signed-in session.

### Step 6: Rehearse a revoke and a partial failure before go-live

Grant a test account access, revoke it, and check that both got logged. Then run a new-hire bundle with one app set up wrong. It will partly succeed, and nobody files a ticket for the part that worked.

Our Agent Studio post says you can roll an agent version that misbehaves back “to a known-good state without overwriting history,” and [Safe Actions](https://devrev.ai/blog/safe-actions) lets individual actions “be undone cleanly.” A reset still can’t be undone. But [Powerless by design](https://devrev.ai/blog/powerless-by-design) says every completed reset writes a record nobody can delete. So compliance can pull “every password reset in the last 90 days, who approved each one, and what verification method was used.”

[Our session on permissions and blast-radius control for agent actions](https://www.youtube.com/watch?v=jmmujTOap-Y) covers who may run an agent action, and how far it can reach. The session is from July 2026 and runs about 32 minutes.

**Approval gate:** someone other than the builder publishes the agent.

Check your audit trail before go-live, too. Jira Service Management’s automation audit log keeps 90 days, so compare that with your audit period. Entra ID collects no reset reporting data until someone opens the Reporting tab or the audit logs once, so open it before launch.

Another sysadmin on Reddit warns that new-hire automation breaks on data long before it breaks on code. People can exist in the HR system before they exist in Active Directory (AD):

“Be aware, HR data quality will bite you. Plan for validation: users with missing departments, duplicate entries, people who exist in HR but not AD yet.”

[u/uptimefordays, r/sysadmin, February 2026](https://www.reddit.com/r/sysadmin/comments/1r1xsyn/automating_onboarding_and_off_boarding/o4thaf5/)

To see how Computer keeps the request apart from the reset, [book a demo of Computer](https://devrev.ai/request-a-demo) and bring one of your own reset requests.

## Which of these requests can you take back?

Whether a change can be undone depends on the system that made it, not on the agent that asked for it. Microsoft’s documentation on how SSPR works says it “performs the equivalent of an admin-initiated password reset in Active Directory” on-premises. In our reading, a cloud reset in Entra ID or Okta is just as final: once the new password is set, there’s no undo.

| Request | Where the write lands | Check before the write | Can you take it back? |
| --- | --- | --- | --- |
| Password reset | Identity provider | Identity verification | No. You can only reset again |
| MFA reset | Identity provider | Manager attestation or stronger | No, and the new device owns the next sign-in |
| Access grant | App or group in the identity provider | App owner approval | In part. Revoke it; anything it opened stays open |
| New-hire bundle | HR system, identity provider, devices, apps | Approval per system | In part, one system at a time |

## How do you know the automation is working?

Track deflection rate and time to fulfillment for each request type from day one:

- **Deflection rate:** requests closed without anyone on the service desk touching them, divided by all requests of that type. An approval click doesn’t count as a touch.
- **Time to fulfillment:** the time from when the request arrived to when the access works. Report the median.

Fixify, a help desk vendor, studied more than 50,000 tickets from more than 30 organizations for its 2026 IT Help Desk Benchmark Report. Even heavily automated permissions tickets took a median 9.6 hours to resolve. That’s Fixify’s resolution time, not time to fulfillment as defined above, and Fixify says human sign-off “extends the clock.”

That clock is the price of the approval gate, and it’s worth paying while a reset can’t be undone. Measure it per request type, and keep the agent filing the request while the identity provider does the reset.

If you ranked your 10 most common requests in step 1, bring that list to a [15-minute live demo](https://devrev.ai/request-a-demo) and use it to choose the first requests to automate.

## FAQ

### What is a self-service password reset?

Self-service password reset (SSPR) lets an employee reset a forgotten password or unlock an account without calling the help desk. The employee proves who they are with methods they registered in advance. Then the identity provider, such as Microsoft Entra ID or Okta, performs and logs the reset.

### Is it safe to let an AI agent reset passwords?

Yes, if the agent never holds identity-provider credentials. In that design, the agent only files the request. Identity checks run where the agent can’t reach them, and the identity provider performs the reset. A persuasive caller gets nothing from the agent, because the agent has no identity access to give.

### What happens if an AI agent grants the wrong access?

Revoke it in the identity provider, then check what the account opened while the grant was live, because revoking access doesn’t undo exposure. Time-bound grants limit the damage by expiring on their own. The audit record shows who approved the grant, and when.

### Can an AI agent run new-hire onboarding end to end?

In pieces, for now. Onboarding touches several systems, and each can fail on its own, so approve and check each one. Jira Service Management’s documentation says its autonomous mode “is not available for any onboarding request types.” Offboarding needs the same care in reverse.