They create risk because access can be granted once and then continue operating outside normal identity controls. Once an app has an OAuth token or similar delegated permission, the organisation may lose sight of who approved it, what scope it has, and when it should be revoked.
Why This Matters for Security Teams
Unapproved SaaS and AI apps are risky because they sit at the edge of identity governance and often receive delegated access faster than security teams can review it. Once a user clicks approve, the app may inherit mailbox, file, or data platform permissions without ever passing through normal joiner-mover-leaver controls. That makes the app itself a non-human identity with real blast radius.
The problem is not only visibility, but persistence. OAuth grants, API keys, and service tokens can outlive the business need that created them, especially when the app is connected through shadow IT procurement or a browser-based consent flow. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a useful signal for how often identity control breaks down once machine access spreads beyond approved tooling.
Current guidance from the NIST Cybersecurity Framework 2.0 still depends on asset visibility, access governance, and continuous monitoring, but unapproved apps usually bypass all three. In practice, many security teams encounter the breach path only after a third-party app has already been over-permissioned and used as a quiet bridge into sensitive data, rather than through intentional app onboarding.
How It Works in Practice
Unapproved SaaS and AI apps create identity risk because they turn ordinary user consent into durable machine access. A user may approve an integration for convenience, but the resulting token or delegated grant often acts like a standing credential that security teams do not inventory, rotate, or revoke on schedule. That is why this is an identity issue, not just an app governance issue.
Security teams should treat each approved app as a distinct non-human identity and track four things: who consented, what scopes were granted, where the token can be used, and what event revokes it. Best practice is evolving, but current guidance suggests combining OAuth app review, CASB or SaaS discovery, and NHI lifecycle controls so shadow approvals do not become permanent access paths.
- Inventory all user-consented apps and classify them by data sensitivity and privilege scope.
- Restrict admin consent so high-risk scopes require explicit approval and ticketed justification.
- Monitor for stale grants, unused tokens, and excessive scope creep across SaaS and AI tools.
- Revoke access automatically when the business use case ends, not only when a user leaves.
The issue is amplified in AI apps because they often request broad connectors into chat, documents, tickets, and code repositories. The LLMjacking research shows how quickly exposed credentials can be abused, which is why delegated access must be treated as a live attack surface. For baseline governance, the Ultimate Guide to NHIs remains the clearest reference point for lifecycle, visibility, and offboarding discipline.
These controls tend to break down when employees can self-authorise third-party apps directly against production SaaS platforms because the approval path is outside security-owned workflows.
Common Variations and Edge Cases
Tighter app control often increases friction for business users, requiring organisations to balance speed of adoption against data exposure and revocation risk. That tradeoff is especially visible with AI assistants, where teams want rapid experimentation but the same tools may request access to mailboxes, documents, or CRM records. There is no universal standard for this yet, so policy design has to reflect local risk tolerance.
One common edge case is low-code automation. A harmless-looking workflow platform can become a privileged identity if it is allowed to move data between systems, send emails, or create records on behalf of users. Another is contractor-led app adoption, where temporary teams connect tools that outlive the engagement and remain valid long after the work ends. In both cases, the identity risk comes from the grant, not the logo on the app.
Security teams should also avoid assuming that MFA on the human user solves the problem. Once consent is granted, the app may continue operating without interactive authentication until the token expires or is revoked. NHI Management Group’s 52 NHI Breaches Analysis and the Top 10 NHI Issues both reflect the same pattern: the biggest failures come from unattended machine access, not from the initial user click.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses weak lifecycle control over app credentials and tokens. |
| CSA MAESTRO | Applies governance to SaaS and AI app access paths that bypass normal oversight. | |
| NIST AI RMF | Relevant because AI apps create decision and access risks beyond traditional software. |
Use MAESTRO to govern app approvals, scope review, and continuous monitoring for autonomous access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
