Two accounts appear in exposure evidence. One can read a low-impact team workspace. The other can create administrators and change recovery settings. Their record counts may be equal; their access consequences are not.
Least privilege makes this difference manageable before and during an investigation.
Map capabilities, not labels
OWASP's authorization guidance recommends designing access around required permissions and applying least privilege. An investigation should establish the permissions actually granted now.
Do not infer power solely from an address containing admin, finance, or support. A harmless-looking workload can have broad rights, while a person with an impressive title may have limited technical access.
Ask the authorized system owner to confirm what the identity can read, change, approve, and delegate.
Use a small access-impact worksheet
| Capability | Investigation question |
|---|---|
| Sensitive data | Which information can the account access? |
| Configuration | Can it alter security or business settings? |
| Delegation | Can it create users, grants, or privileged roles? |
| Recovery | Can it reset or recover other accounts? |
| Dependencies | Which business processes rely on it? |
This worksheet is a conversation aid, not a universal risk-scoring formula. The significance of each answer depends on the service and business context.
A hypothetical integration that can export customer data may deserve a fast review even if it cannot administer users.
Reduce authority without guessing about compromise
A historical exposure finding does not establish that the credential still works. It can still reveal a good reason to confirm whether the account's current access remains justified.
The service owner can remove unnecessary permissions through the normal authorization process, independently of whether the original incident is attributed.
When current misuse is suspected, coordinate containment with the incident owner. Document the business impact of disabling a dependency rather than leaving broad access untouched because it is inconvenient to review.
Verify the new boundary
After a permission change, use approved administrative records and test accounts to verify intended access. Do not replay an exposed secret to measure its former capabilities.
Check the business workflow too. A permission reduction should leave authorized work functional or have a documented recovery plan.
Close the investigation with the established account role, actions taken, access outcome, and remaining uncertainty. “Privileged” should be an explainable condition, not a decorative severity badge.
Read service-account investigations and prioritizing privileged exposure. Reducing the authority behind a credential can matter more than counting how many times it appears.