agent reset the wrong account: name collision in ad search results

TL;DR

Name searches return multiple people and the agent picked the wrong one. Require disambiguation by employee ID, UPN, or department before any destructive action, and show the candidate list when uncertain.

The query

agent reset the wrong account: name collision in ad search results

Use this when

• the agent reset the wrong account
• common names return multiple results
• destructive actions follow a name search

Not for

• AD search slowness
• read-only lookups
• service account management

Steps

1. Require the agent to collect a unique identifier, employee ID or UPN, before any reset. Expected output: the action targets exactly one account.
2. When a name search returns multiple candidates, present the list with distinguishing attributes. Expected output: the ambiguity is visible, not hidden.
3. Block destructive actions when more than one candidate matches and no unique ID was given. Expected output: the agent asks instead of guessing.
4. Log the chosen account with its unique ID on every action. Expected output: the audit trail names the exact account.
5. Test with the most collision-prone names in the directory. Expected output: the guard triggers correctly.

Applies to

Active Directory, Entra ID, helpdesk agents performing account actions.

Variant phrasings

Collision across rehired accounts

Include account status and hire date in the candidate display.

Service accounts sharing naming patterns

Keep service accounts in a separate OU and search path.

Why it happens

Names are not unique identifiers. Agents that treat them as such will eventually act on the wrong person, and resets are hard to unsee.

Edge cases

• UPN changes on name changes; employee ID is the stable key.
• Display photos or departments in the candidate list for human confirmation.
• This guard belongs in the framework, not in each individual skill.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W2QkurIx3XGKMAbXtsUXAA