Skip to content

Password Reset Anomaly Triage

Example prompt: "When someone raises a password reset ticket, have a quick look at where they were and what they were doing this week, and if anything seems off — different country, late at night, third reset this month — flag it to the security lead before anyone resets anything."

The Problem

Password reset tickets are the single most common helpdesk request, and most of them are mundane — somebody got locked out coming back from holiday, somebody bought a new phone and the authenticator app moved. But every social-engineering compromise we read about in the trade press starts with a password reset ticket that looked exactly like the other forty that week, and the helpdesk technician on shift had ten minutes to deal with each one and no easy way to ask "is anything actually wrong here." The cost of treating all resets as routine is the rare case that should have been escalated; the cost of treating all resets as suspicious is a helpdesk that grinds to a halt. The middle path needs a triage step nobody has the time to do by hand.

How GloriaMundo Solves It

We build a workflow that triggers whenever a new ticket of type "password reset" is opened in the helpdesk. An integration step pulls the requester's recent activity record from the security log sheet — the last week's login countries, typical login times, and the count of password resets in the last 30 days. An LLM step compares the new request against the recent pattern and writes a short triage note flagging anything genuinely unusual — a request from a country the person has not logged in from before, a request at 3am local time when they normally log in 9-to-5, or a third reset in 30 days when they typically have none. A conditional step routes by the triage note: if nothing unusual is flagged, the workflow posts a short internal note on the ticket saying "triage clean, normal processing" and assigns it to the on-shift technician for the standard reset path; if anything is flagged, the workflow does not do the reset and instead posts the triage note on the ticket, raises a parallel DM to the security lead and the on-shift technician, and tags the ticket "security-hold" so the standard reset macro is not run. The reset itself is always done by a human; the workflow's only commitment is "we have looked at this and these are the flags." Glass Box preview shows the requester's recent pattern, the triage note, and the routing decision before anything is posted.

Example Workflow Steps

  1. Trigger (integration): A new Zendesk ticket of type "password reset" is opened.
  2. Step 1 (integration): Pull the requester's recent activity record from the security log Google Sheet — last week's login countries, typical login window, and the count of password resets in the last 30 days.
  3. Step 2 (LLM): Compare the new request against the recent pattern and write a short triage note flagging country, time, or frequency anomalies, or noting that nothing unusual stands out.
  4. Step 3 (conditional): Route on the triage note — clean cases to the standard-reset path, flagged cases to the security-hold path.
  5. Step 4 (integration): For clean cases, post a short internal note on the ticket saying "triage clean, normal processing" and assign it to the on-shift technician.
  6. Step 5 (integration): For flagged cases, post the full triage note on the ticket, raise a parallel Slack DM to the security lead and the on-shift technician, and tag the ticket "security-hold" so the standard reset macro is not run.
  7. Step 6 (integration): Log the triage outcome back to the security log sheet so the pattern view on next week's request includes the run.

Integrations Used

  • Zendesk — the password-reset ticket trigger, the internal-note posts, and the security-hold tagging
  • Google Sheets — the security log of login countries, typical login times, and recent reset counts, updated on each triage outcome
  • Slack — the parallel DM channel to the security lead and the on-shift technician for flagged cases

Who This Is For

Helpdesk and security leads at companies between 100 and 1,000 staff where password reset tickets come through a shared helpdesk queue and the team wants a consistent triage step in front of the standard reset macro without slowing down the routine cases.

Time & Cost Saved

The triage step itself is the kind of work nobody can sustain by hand on a busy queue — a technician handling six reset tickets an hour cannot also do five minutes of activity-pattern checking on each one. The workflow does the check on every ticket; the saving is not in technician time on the routine cases but in the rare-case catch — the request that looks routine on the ticket form and is the first signal of an account takeover attempt, where five minutes of triage in front of the reset is the difference between a security event and a security incident.