HACH dev: verify chat agent requests by user.id, not display name

The article's distinction is between two different trust problems. Prompt injection, already widely discussed, concerns fake instructions hidden in external content the agent reads. The article targets an earlier step: whether the person speaking live in the chat is who they claim to be. It notes that chat platform APIs typically send both a display name and a user ID, or account ID, but hurried implementations sometimes use only the display name for logging and permission checks — the starting point of incidents.

The article's argument rests on several concrete scenarios. Display names are often user-editable, so a malicious third party or a hijacked guest account can mimic an executive's name and icon. External guests or members of partner workspaces may join under the same name as an internal member, making inside-versus-outside hard to distinguish. And when an account is reused or handed over after retirement or transfer, name-based linking to past conversation logs cannot reveal that the owner has changed.

The proposed countermeasures are layered. Permission decisions should use only immutable identifiers such as Slack's user.id or Teams' aad_object_id, with display names used purely for human-facing display; some platforms also let the agent tell whether a participant is a guest or external member, so requests from outside can be held back or escalated according to importance. And because the article acknowledges these signals on their own produce many false positives, it recommends not blocking outright but inserting a heavier confirmation step before execution. What the design ultimately hinges on is how much added friction a team is willing to absorb for hard-to-undo actions, and for whom — the teams running agents that approve quotes or suppress reports daily are the ones who will feel that trade-off.