A support tool may let an employee view the application as a customer to reproduce a problem. That feature combines two identities: the staff member operating the tool and the customer account whose experience is being viewed. Losing either identity in the authorization or audit path can make the resulting actions difficult to control or explain.
The feature's business purpose is usually narrower than unrestricted account access. A review can define which customer information is needed and which actions remain unavailable during support access.
Preserve both actor and subject
OWASP's multi-tenant guidance addresses tenant context, privileged operations, and cross-tenant access boundaries. The multi-tenant security guidance provides the surrounding isolation principles.
An illustrative support agent opens a customer's project to investigate a display problem. The system can record the staff identity as the actor and the customer as the subject. Replacing the staff identity entirely with the customer identity would make later actions appear to have been performed by the customer.
Define scope and sensitive exceptions
Read-only viewing may satisfy some support tasks. Other tasks may require a specific change, such as correcting a configuration value. Account ownership transfer, credential changes, payment details, and bulk exports can require separate authorization even if ordinary viewing is allowed.
Record the reason for access and any customer or internal approval required by the product's policy. A ticket number provides useful context but is not itself an access-control decision. The service still needs to check the support role and the requested customer scope.
Test transitions into and out of support mode
Use a synthetic customer and a test support identity. Verify normal entry, expiration, explicit exit, and loss of the support role while the session is active. Check direct API calls as well as visible buttons because hidden controls do not establish server-side restrictions.
Attempt agreed prohibited operations and verify that they leave the customer record unchanged. Also test whether links or background jobs created during support mode retain excess access after that mode ends.
Verify customer-visible and internal evidence
Review whether the product displays the intended support-access indicator or notification. Then inspect audit records for the actor, customer tenant, operation, reason, time, and outcome. The records need to support reconstruction without logging unnecessary customer content.
The assessment can describe the authority available during support access and the controls that limit it. For the business, this provides evidence for a sensitive operational capability that may not appear in ordinary customer-role testing. It also creates specific retest cases when support tooling or account roles change.
Sources
OWASP: Authorization. The support workflow is illustrative.
