What should IAM teams do when employees keep using unsanctioned AI tools?

Why This Matters for Security Teams

Unsanctioned AI tools are not just an acceptable-use issue; they are an identity and data access problem. Once employees paste prompts, connect OAuth apps, or upload files into unmanaged services, IAM teams lose visibility into who can reach enterprise data and what the service can do with it. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a control problem, not a training problem, because access must be authorized, monitored, and revoked in practice.

The risk is amplified when AI tools sit outside approved browser, SaaS, and credential governance. NHIMG research on The 2024 Non-Human Identity Security Report shows that 88.5% of organisations say non-human IAM lags behind or only matches human IAM, while 59.8% see value in dynamic ephemeral credentials. That gap matters because the enterprise often discovers shadow AI after tokens, data, or permissions have already spread into the toolchain. In practice, many security teams encounter misuse only after an account, token, or browser session has already been abused, rather than through intentional control design.

When employees keep using unsanctioned AI, the real question is whether the organisation can still enforce policy at the identity layer. The answer is usually no unless OAuth review, conditional access, and revocation are coordinated.

How It Works in Practice

The practical response is to make the sanctioned path easier than the shadow path, then enforce it through identity and browser controls. Start by defining which AI services are approved, which data types may be used, and which integrations are forbidden. Then bind that policy to the controls users actually touch: enterprise SSO, browser access policies, CASB or SaaS discovery, and OAuth consent governance.

For identity teams, the key is to treat AI service access like any other privileged SaaS connection. Review third-party OAuth grants, block high-risk scopes, and revoke tokens when a tool is unapproved or a user leaves. Where the tool exposes API access, require managed service accounts or brokered credentials rather than personal logins. This is the same control logic behind preventing credential sprawl in incidents such as TruffleNet BEC Attack — Stolen AWS Credentials and limiting secret exposure patterns discussed in Azure Key Vault privilege escalation exposure.

• Use SSO and conditional access to route users toward approved AI tools first.
• Block unmanaged browser sessions from sending sensitive data to unknown domains.
• Audit OAuth consents for AI apps and remove risky or overbroad permissions.
• Revoke access quickly when policy changes, not only at periodic review.
• Pair acceptable-use policy with technical enforcement so violations are not purely disciplinary.

For broader control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for access enforcement, session monitoring, and revocation discipline, while NHIMG coverage of incidents such as the DeepSeek breach shows how quickly exposed secrets and uncontrolled integrations can turn into data exposure. These controls tend to break down when employees can bypass managed browsers or connect personal AI accounts from unmanaged endpoints because identity policy no longer follows the data path.

Common Variations and Edge Cases

Tighter AI access control often increases user friction, so organisations have to balance productivity against data loss risk. That tradeoff is real, and current guidance suggests the answer is not a blanket ban unless the environment is highly regulated or data sensitivity is extreme.

Some teams can rely on browser isolation and app allowlisting, while others need CASB enforcement, device posture checks, and DLP to keep pace with users who switch between personal and corporate accounts. There is no universal standard for this yet, but best practice is evolving toward policy that follows the identity and the session rather than only the network perimeter. If employees can still paste confidential content into consumer AI from a corporate browser, the gap is operational, not educational.

Edge cases also matter. Contractors may need tighter session controls than employees. Developers may need approved AI sandboxes with restricted connectors. High-risk business units may require step-up approval before any data export to AI services. NHIMG reporting on the Replit AI Tool Database Deletion and the Gemini CLI Breach underscores that AI tools can create impact quickly when permissions, context, and execution authority are too broad.

Related resources from NHI Mgmt Group

• Why do unsanctioned AI tools create compliance risk for IAM teams?
• Why do employees keep using unapproved AI tools even when policy forbids them?
• How should security teams govern MCP tools using behavior-based policies?
• How should security teams handle risks from AI browser extensions?