How should organisations govern AI usage when employees use unapproved tools?

Why This Matters for Security Teams

Unapproved AI tools are not just a policy problem. They are an identity, data, and governance problem that can turn ordinary employees into the intake path for sensitive content, prompts, and credentials. Once a tool is outside approved procurement and security review, organisations often lose visibility into where data flows, which accounts are reused, and whether the tool retains inputs for model training or vendor support. That is why visibility has to come before punishment. The practical aim is to identify apps, browser extensions, agents, and shadow workflows before they become a persistent exposure surface, a point reinforced by Top 10 NHI Issues and the governance lens in NIST Cybersecurity Framework 2.0. Current guidance suggests that blanket bans rarely remove usage; they usually just move it out of sight. In practice, many security teams encounter data leakage only after an employee has already pasted sensitive material into an unapproved tool, rather than through intentional control design.

How It Works in Practice

A workable model starts with discovery, then classification, then control selection. Security teams should map which unapproved tools are being used, who is using them, what business tasks they support, and whether those tasks involve secrets, regulated data, or customer records. From there, decisions can be based on context rather than a simple allow or deny. For lower-risk use cases, organisations may permit limited access with strong guardrails. For higher-risk uses, the answer may be removal, replacement, or monitored exception handling.

That governance flow aligns with the lifecycle thinking in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with NIST Cybersecurity Framework 2.0, which both emphasise visibility, access control, and continuous monitoring. For AI-specific use, the control question should also include whether the tool can create or reuse

secrets

, whether it stores prompts, and whether it can act autonomously on behalf of a user. If an employee connects an unapproved assistant to email, tickets, or source code, the issue is no longer just application use. It becomes delegated authority.

• Require inventory of all approved and unapproved AI tools, including browser-based and embedded assistants.
• Classify usage by data sensitivity, business purpose, and whether the tool can write, send, or execute actions.
• Block direct handling of

  secrets

  and privileged content unless the tool is explicitly authorised.
• Use policy reviews to decide when education, restriction, or exception handling is the right response.

Where organisations have strong NHI discipline, they can also apply the same thinking to user-to-tool connections and delegated credentials, rather than treating shadow ai as a separate exception class. The DeepSeek breach is a reminder that exposed data and uncontrolled retention can scale quickly once AI systems are allowed to ingest more than intended. These controls tend to break down when unapproved tools are embedded in collaboration platforms, because security teams lose the ability to see both the request and the downstream data handling.

Common Variations and Edge Cases

Tighter control often increases user friction, so organisations have to balance speed and convenience against exposure and auditability. That tradeoff is real, especially where teams are using AI to automate routine work and will simply route around rigid bans if the approved path is too slow.

One common edge case is personal accounts used for work. Another is a sanctioned model accessed through an unsanctioned wrapper or plug-in. A third is employee-created agents that can take actions across multiple systems. Best practice is evolving here, and there is no universal standard for this yet, but the direction is clear: the more a tool can retain data, act independently, or chain actions across systems, the closer it needs to sit to formal NHI governance. The audit perspective in Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful because it frames these cases as control, evidence, and accountability problems rather than a narrow app-approval issue. Security teams should also watch for prompts containing API keys, tokens, or certificates, because leaked

secrets

can outlive the session and create a second-order incident.

When employees use unapproved tools for low-risk drafting, the response may be education and monitoring. When they use them for code, finance, customer data, or admin actions, the response should be much stricter. The hard part is not deciding that shadow AI is risky. It is building a governance model that can distinguish harmless experimentation from behaviour that creates an unmanaged identity and data path.

Related resources from NHI Mgmt Group

• How should organisations govern access to data used by AI systems?
• How should organisations govern destructive AI agent actions in production?
• How should healthcare organisations govern AI when data comes from many systems?
• What breaks when employees use personal and corporate AI accounts interchangeably?