Because the real risk is delegated access, not the app name. A hidden assistant or consumer service can inherit permission to read mail, files, calendars, and identity data through OAuth or shared credentials, and those rights can persist after the user stops using it. Inventory is useful, but lifecycle control of grants and tokens is what limits exposure.
Why inventory underestimates the real exposure
A simple app inventory tells you what is installed or connected, but it often misses what those apps can actually do on behalf of a user. The material risk is delegated authority: a hidden assistant, plugin, or consumer SaaS may hold long-lived access to mail, files, calendars, contacts, or identity data even when the app itself looks harmless. Shadow AI and AI Agent Discovery Guide helps teams find those hidden tools through OAuth grants and related signals rather than relying on app counts alone.
That is why inventory and governance need to be paired. If an app has been granted access through OAuth or shared credentials, the risk travels with the grant, not with the app label. A low-visibility tool can therefore become a durable access path into business data, and the exposure can remain active long after the user has stopped opening the app.
How delegated access becomes a standing trust path
OAuth is designed to let a user or admin delegate limited access without sharing a password, but in practice the scope, token lifetime, refresh behaviour, and consent model determine how much authority the app really gets. RFC 6749: The OAuth 2.0 Authorization Framework defines that delegation model, while RFC 9700: Best Current Practice for OAuth 2.0 Security addresses practical hardening against token theft and weak deployment choices.
Once a grant exists, the app may act with the user’s permissions without ongoing human interaction. That makes the grant a lifecycle object, not a one-time event. If the grant is never reviewed, revoked, or narrowed, the access path can outlive the business need, which is why dormant consent is often more dangerous than the app inventory suggests.
What to look for when the app list looks clean
Focus on the controls around grants, tokens, consent, and session persistence. The highest-value questions are whether the app has offline access, whether refresh tokens can survive user logout, whether scopes are broader than the use case, and whether multiple apps are reusing the same source of trust. The SaaS-to-SaaS and OAuth App Governance Guide is useful here because it treats consent and revocation as governance problems, not just inventory problems.
Also check for hidden paths created by consumer tools, AI assistants, and third-party integrations that inherit mailbox, file, or identity permissions through delegated access. The practical failure mode is that the application appears low risk on paper while its grant can still exfiltrate sensitive data, persist beyond business use, or be repurposed after compromise. In other words, the app name is not the unit of exposure, the permission set is.
Risk and Threat Considerations
Hidden AI tools and OAuth grants create a durable attack surface because attackers do not need to compromise the visible app if they can abuse the delegated access behind it. That can turn consented access into data theft, mailbox abuse, or lateral movement through business workflows, especially when grants are broad, long-lived, or poorly monitored.
Failure mechanism: The organisation inventories apps but does not continuously govern grants, scopes, token lifetime, or revocation, so access remains active after the user, sponsor, or business purpose has changed.
Impact: Sensitive mail, files, calendars, and identity-related data can remain exposed through a hidden or forgotten integration, and compromise of that integration can create persistent unauthorized access rather than a short-lived event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Hidden grants can outlive app use and user intent. |
| NHI-02 — Secret Leakage | OAuth grants and shared credentials can expose data if they are mishandled. | |
| NHI-07 — Long-Lived Secrets | Persistent refresh tokens extend exposure beyond the visible app lifecycle. | |
| Recommendation — Revoke unused grants and tokens when the app or sponsor is no longer active. Protect OAuth secrets and token material from unintended disclosure. Shorten token lifetime and rotate credentials to reduce standing access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens and shared credentials require lifecycle control and revocation. |
| AC-20 — Use of External Information Systems | Third-party apps and consumer services act as external systems receiving delegated access. | |
| AC-2 — Account Management | The issue is standing access that persists after business need changes. | |
| Recommendation — Manage issuance, rotation, and revocation of authenticators and tokens. Restrict external-system access paths and approve them explicitly. Continuously review and disable no-longer-needed accounts, grants, and access paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Grant review and revocation are central to reducing hidden delegated access. |
| CIS-5 — Account Management | Persistent grants behave like accounts that must be governed across their lifecycle. | |
| Recommendation — Inventory and remove unnecessary access paths, including third-party grants. Review account and grant lifecycle to remove stale access. | ||
Practitioner Guidance
What to prioritise: Review grants first, not the app catalogue. An app with narrow business value but broad delegated access deserves faster attention than a well-known app with no active consent or expired tokens.
What to verify: Confirm who approved the grant, which scopes were issued, whether refresh tokens or offline access are present, and whether the grant is still tied to an active business need. If you cannot answer those questions quickly, the control is not mature enough to trust.
Decision rule: If an app can read mail, files, or identity data and you cannot justify the scope in business terms, revoke or re-consent it before you spend time classifying the app brand. If the app is already gone but the grant remains, treat the grant as the asset.
Practitioner takeaway: Inventory tells you what exists; lifecycle control tells you what still has power. The real reduction in exposure comes from governing consent, scopes, and token validity as first-class security objects.