They should bring those accounts into the same ownership, review, and offboarding model used for other identity assets. The aim is not to ban tool adoption, but to make sure every credential has a clear owner, a lifecycle, and a deprovisioning path.
What to do when employees create SaaS and AI accounts outside central onboarding
Unmanaged accounts are not just a procurement issue, they are an identity and access problem. Once employees spin up SaaS tools or AI services on their own, those accounts can outlive the business need, bypass review, and retain access after the person changes role or leaves. The practical goal is to fold them into the same ownership and offboarding discipline as any other credential-bearing account.
That means teams need a discover, assign, review, and retire model for shadow SaaS and AI use. A useful starting point is an inventory of user-created tools, the authentication path behind each account, and the business owner who can approve continued use. NHIMG’s Shadow AI and AI Agent Discovery Guide is built around finding those unsanctioned tools through OAuth grants, API keys, cloud, endpoint, and network signals before bringing them under governance.
Where the account can touch company data, shared workflows, or downstream systems, treat it as part of the enterprise identity estate rather than a personal convenience. That includes SaaS trial accounts that later become production workflows, AI tool subscriptions tied to employee email, and third-party app consents that silently keep access after the original use case has changed. The same ownership rule should apply whether the account was created by IT, a manager, or the employee themselves.
Why unmanaged SaaS and AI accounts become a lifecycle problem
The main failure is drift. A team may approve a tool informally, but without ownership, the account can escape review, remain active after offboarding, or keep standing access that no one is still monitoring. That creates a gap between business adoption and security control, especially when the account holds tokens, API keys, or delegated access to mail, documents, CRM records, or code.
Shadow AI and SaaS also tend to blur personal and corporate boundaries. Employees often connect these tools through single sign-on, OAuth consent, or a personal email address, which makes the account look harmless while still preserving access to sensitive content or business systems. NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because the problem spans access control, identification and authentication, auditability, and account lifecycle discipline.
At scale, the issue is less about one risky app and more about inventory loss. If no one can answer who owns the account, what it can reach, and how it will be revoked, the organisation has no reliable way to prove least privilege or timely deprovisioning. That is why unmanaged SaaS and AI accounts should be handled as governed identity assets, not as a separate “tool sprawl” category.
How to bring shadow accounts under control without stopping adoption
The strongest approach is to separate approval from abandonment. Teams should allow employees to try useful SaaS and AI tools, but only if the account can be registered, attributed, and reviewed. That usually means one of three outcomes: bring the account into a sanctioned tenant, link it to a named business owner, or retire it if it has no durable business purpose.
For accounts that remain in use, teams should verify the authentication method, the data connections, and the offboarding trigger. If the tool uses OAuth grants, API keys, or delegated mailbox access, those permissions need to be tracked the same way a service account credential would be tracked. The OWASP Non-Human Identities Top 10 is relevant because long-lived secrets, overprivilege, and improper offboarding are common failure patterns once a user-created account starts acting like a business dependency.
For AI-specific use, the same logic applies even when the tool feels temporary. If an employee uses an AI workspace, plugin, or connected app to process internal content, the account should have an owner, a business justification, and a revocation path. NHIMG’s SalesBleed Salesforce Agentforce 2026 case study is a good reminder that agent identity and tool permissions can create real exposure when trusted integrations are left too broad.
Risk and Threat Considerations
Unmanaged SaaS and AI accounts create exposure when access survives the employee who created it, or when a personal approval path becomes a production dependency. The practical risk is not only account sprawl, but hidden data access, weak revocation, and third-party permissions that no one is monitoring.
Failure mechanism: Users connect unsanctioned tools through OAuth, API keys, or embedded sign-ins, then leave those credentials and consents active after the original need ends. That leaves a standing trust path that can outlast role changes, offboarding, or tool abandonment.
Impact: Sensitive data can remain reachable, audits can miss active access, and a compromised or forgotten account can become a persistence point for misuse, exfiltration, or unauthorized automation.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | User-created SaaS and AI accounts often outlive the employee who set them up. |
| NHI-02 — Secret Leakage | Shadow SaaS and AI tools commonly rely on exposed tokens, API keys, or stored credentials. | |
| NHI-05 — Overprivileged NHI | Employee-created accounts frequently accumulate broader access than the use case needs. | |
| Recommendation — Inventory user-created accounts and revoke access promptly when the business need ends. Track and rotate exposed secrets tied to unsanctioned SaaS and AI accounts. Reduce permissions on shadow accounts to the minimum access required for the approved task. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | These accounts depend on managing credentials, tokens, and other authenticators over time. |
| AC-2 — Account Management | The question is fundamentally about bringing unmanaged accounts into a governed ownership model. | |
| AC-6 — Least Privilege | Shadow accounts often retain excess access after the initial business use case changes. | |
| Recommendation — Register and rotate authenticators for user-created SaaS and AI accounts on a defined lifecycle. Place employee-created SaaS and AI accounts under formal account ownership and review. Limit unmanaged accounts to the smallest permission set needed for approved use. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Employee-created AI and SaaS integrations can expose powerful actions if permissions are not governed. |
| Recommendation — Verify that connected tools can only invoke functions explicitly approved for the account. | ||
Practitioner Guidance
What to verify: For every user-created SaaS or AI account, confirm the owner, the business purpose, the authentication method, the data scope, and the revocation mechanism. If any of those are missing, treat the account as incomplete governance, not as low-risk experimentation.
Decision rule: If the account can access company content, connect to other systems, or persist beyond the employee relationship, it belongs in the same review and offboarding process as any other enterprise identity. If it cannot be owned and revoked cleanly, it should not be allowed to keep production access.
Practitioner takeaway: The right control is not blanket prohibition, it is making shadow SaaS and AI accounts legible, attributable, and removable before they turn into unowned access.