One approval is often expanded to cover all later related operations
Aliases: authorization scope creep · persistent reuse of approval · consent scope expansion
What it is
Privilege-consent scope creep occurs when a system or application interprets approval for one object, purpose, or period as broad authority over later “related” operations. Access to a folder for one import can become continuous scanning, analysis for a new purpose, or processing of files added later.
Why it happens
Permission implementations store broad resource capabilities while confirmation uses concrete task language. When granularity differs, technical scope exceeds understood scope and survives updates, background work, and new features. Users do not see later uses and cannot tell that the initial decision has been reinterpreted.
Studying it
Have participants approve capability in a specific task, then elicit expectations for new objects, purposes, background use, and later versions. With marked test data, observe every post-approval access and reconcile requester, object, action, purpose, and time against confirmation. A successful authorization API call does not prove later use remains within the user's semantic grant.
Where it stops holding
Some continuing functions genuinely need future or background access, which should be explicit at confirmation with visible state and revocation. Technical inability to enforce purpose does not erase purpose boundaries; architecture, audit, and organizational controls must supplement. A narrow, predictable task lease used to reduce repetition differs from an ambiguous permanent grant.
Applying it
- Bind authorization records to requester, resource set, purpose, allowed actions, time, and foreground or background condition.
- Reconfirm new objects, purposes, stronger actions, or application-ownership change instead of reusing “related operation” authority.
- Show recent use by purpose with one-action termination and propagate revocation to background processes and derived tokens.
- Use marked test objects to verify access outside the original scope is blocked and audited.
Related
Cards in the same group
- O3.08.1Privilege elevation requires explicit confirmation
- O3.08.2Confirmation must explain what capability will be gained
- O3.08.3Elevated privilege needs a time limit
- O3.08.4Frequent elevation prompts produce unthinking consecutive approval
- O3.08.6Ambiguous elevation wording makes users underestimate granted authority
- O3.08.7Batch or silent elevation needs stricter limits than one interactive request