A login is not a permission
Authentication establishes who is using a system; authorisation decides what that identity may do. An employee allowed to inspect a payment need not be allowed to refund it, change a beneficiary or export all customers. Design those capabilities separately instead of granting a broad administrator role whenever support encounters an inconvenient screen.
Enforce the real boundary
OWASP recommends least privilege and permission checks on requests. Hiding a button does not prevent an unauthorised API call. Check the action, relevant object and user context on the trusted side of the application. Roles also need review when duties change, particularly after temporary incident access or a team transfer.
A refund example
In a fictional support tool, agents can view assigned orders and request a correction. A separate approved role can release designated refunds. An old API endpoint lets any logged-in agent bypass that separation. Adding another warning in the interface will not repair the missing server-side authorisation decision on that endpoint.
Test and account for exceptions
Write tests that attempt the forbidden action directly, including access to another team’s records. Record who performed privileged actions and why, without exposing unnecessary customer data in logs. A two-person approval arrangement only helps if the second actor has independent authority and the system prevents the same identity from satisfying both roles through another route.