Tech use cases · Help desk
Triage a password reset request that smells off
The scenario
A help desk technician gets a Friday-afternoon ticket: 'I'm out of the office and locked out of my laptop. Can you reset my password and email it to my personal Gmail? I need to send a contract by 5.' The user's tone is urgent. The request is also exactly what a social-engineered attack looks like. AI can help you draft a response that helps the legitimate user without giving away the credentials to a bad actor.
The prompt
You are training a help desk technician on social-engineering red flags in password reset requests. I will give you the ticket. Walk through the response. Format: 1. Three red flags in this request, ranked from most to least serious. One sentence each. 2. The single most important question to ask before doing any reset, and why. 3. The verification path the help desk should take, in plain language. Do not assume what the company has set up, name the categories of verification (something the user knows, something they have, callback to a known phone number, in-person check, manager confirmation). 4. A draft response to the user. Under 80 words. Friendly but firm. Does not promise a reset until verification is complete. Does not send any password or reset link to a personal email under any circumstances. Rules: - Do not be condescending. Real people get locked out and ask for help in clumsy ways. Most of these tickets are legitimate. - Do not assume the user is malicious. Assume the request might be impersonating them. Ticket: [paste the ticket from the scenario]
The output
Three red flags, ranked.
- Out-of-band delivery channel requested. “Email it to my personal Gmail.” Legitimate password resets go to channels the company controls. A request to send credentials to a personal account is the single biggest red flag in this ticket.
- Time pressure paired with a deadline. “I need to send a contract by 5.” Urgency is a classic social-engineering tactic. Real urgency is also real, so this on its own does not condemn the request, but combined with red flag #1 it elevates the suspicion sharply.
- Cannot verify in person. “I’m out of the office.” Cuts off the cheapest verification method. Again, legitimate by itself, but stacked with #1 and #2, the pattern matches an attacker who has the user’s email signature and tone but not their MFA device.
The single most important question.
Ask: “Can I call you back at the phone number on file in our directory?” If the answer is “use this other number, my regular one is dead,” the suspicion is now overwhelming. If they accept the callback, that one verification step alone defeats most impersonation attempts.
Verification path, by category.
- Something they know. A security question or a fact about a recent ticket the user submitted. Weak on its own.
- Something they have. Push a code to their MFA app or registered phone, not the personal Gmail.
- Callback to a known number. Pull the number from your directory or HR system, not from the ticket itself.
- Manager confirmation. Reach the user’s manager via a known channel and confirm the user is locked out and traveling.
- In-person check. Off the table here, but worth naming so junior technicians know it is the strongest option.
Two of these, minimum, before any reset action.
Draft response (under 80 words).
Hi [name], no problem, I can help you get back in. Before I touch the account, I need to verify it is you. I will not send the new password to a personal address; that is a hard line. I can call you back at the number on file in our directory, or push an MFA prompt to your registered device. Which works? I will get this resolved as soon as I have you verified. - [your name]
One reasonable answer. Your run may differ. Read it against the scenario before using any of it.
What to watch for
- AI may suggest sending the password to the personal email 'if the user is verified.' Most companies forbid this entirely. Check your organization's policy before adopting an AI's draft.
- AI may not know your specific verification tools (Okta, Duo, security questions, manager callback). Edit the response to reference what your shop actually uses.
- Never paste real employee names, phone numbers, or email addresses into a public AI. Sanitize the ticket first.
- If the request came in over chat or text rather than email, the verification bar should be higher, not lower. Channel mismatch is itself a red flag.