Impersonation test cases, for when the audit trail blames the customer

Impersonation is built for internal users, shipped without a design review, and then never tested again, which is why it accumulates the sharpest defects in a product. The most consequential is attribution. If an action taken while impersonating is recorded as performed by the customer, the audit trail does not merely lack detail, it asserts something false. A customer disputing a deletion or a settings change will be shown evidence that they did it, and you will have no way to establish otherwise. Every action needs recording as performed by the admin on behalf of the user.

The privilege boundaries are the second theme. Impersonation should grant the ability to act as the user and never the ability to read their secrets, so passwords, API keys, recovery codes and payment details stay masked. It must not permit changing authentication factors, because that converts temporary support access into permanent independent access. It must refuse chaining, since impersonating from within an impersonation session makes attribution ambiguous and can reach accounts the admin was never authorised for. And it must refuse impersonating upward, or it becomes a straightforward escalation path.

Session hygiene needs to be stricter here than anywhere else. An impersonation session is an open door to somebody personal account, so the idle and absolute limits should be shorter than an ordinary session, and exiting must invalidate the token on the server rather than switching context in the browser. The persistent banner belongs in this group too: an admin who forgets which account they are in will act as the customer by accident, and that is a support failure caused by a missing interface element.

Finally, the governance cases are what a regulator or an enterprise buyer will ask about. The record has to be immutable, because an admin able to delete the log of their own access defeats the entire control. Access should be notified to the customer, or gated behind their consent, since reading a personal account without the person knowing is hard to defend. Bulk impersonation by one admin in a short window should raise an alert to a separate reviewer, because that pattern is what precedes an exfiltration incident. And impersonated activity should be excluded from usage analytics, or support sessions quietly inflate both engagement metrics and any usage based billing.