Organisations should teach employees specific rules for what can and cannot be entered into public AI tools, then reinforce those rules with role-based scenarios. Training should cover confidential data, customer information, credentials, and intellectual property. The goal is not to ban AI use, but to reduce leakage risk through clear guidance, just-in-time nudges, and consistent governance.
Why This Matters for Security Teams
Public AI tools are now part of everyday work, but they are not safe destinations for confidential data by default. Employees paste prompts quickly, often outside approved workflows, which means sensitive business context can leave the organisation in seconds. The main risk is not just accidental disclosure. It is also retention, model reuse, and downstream exposure when prompts contain secrets, customer data, or proprietary code. NHI Management Group’s The State of Secrets in AppSec shows that 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases.
Training matters because policy alone does not change behaviour. Employees need simple decision rules, examples that match their job function, and repeated reinforcement at the moment of use. That is especially important as public AI use blends productivity with risk in ways many teams still underestimate. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of user awareness and data handling discipline, but organisations still have to translate controls into plain language people can act on. In practice, many security teams discover unsafe AI prompting only after a sensitive prompt has already been entered and copied into a third-party service.
How It Works in Practice
Effective training starts with a clear classification rule: if the data would be restricted in email, chat, ticketing, or a shared drive, it should not be entered into a public AI tool unless an approved, redacted workflow exists. That means teaching employees to recognise credentials, customer records, incident details, source code, legal text, and internal strategy as off-limits. The message should be specific enough to answer, “Can I paste this?” without requiring a manager review every time.
Best results usually come from combining short policy lessons with role-based examples. For instance, sales teams should see how customer names and deal notes can create privacy and contractual exposure, while engineers should see why API keys, tokens, and snippets from private repositories are especially dangerous. Training should also explain that prompts may be stored, reviewed, or used to improve services depending on the platform terms, so employees should treat public AI as an external environment, not a private assistant. This is consistent with the threat patterns described in DeepSeek breach, where exposure was amplified by the reuse of sensitive material at scale.
- Use a simple red, amber, green decision model for what can be entered.
- Require redaction or synthetic examples before employees test prompts.
- Place just-in-time warnings in approved AI tools when users paste sensitive text.
- Train managers to spot risky use cases in their own teams, not just in security briefings.
Where possible, pair training with logging, egress controls, and approved enterprise AI options so employees have a safe path to follow. These controls tend to break down in fast-moving teams that use personal accounts, browser extensions, or copy-and-paste workflows outside managed devices because the organisation loses visibility at the point of entry.
Common Variations and Edge Cases
Tighter AI controls often increase friction, requiring organisations to balance data protection against employee productivity and adoption. That tradeoff is real, especially when public tools are already embedded in daily work and staff see them as harmless brainstorming aids. The practical answer is usually not a blanket ban, but a narrower rule set with exceptions that are tightly governed.
One common edge case is public information that becomes sensitive when combined. For example, a non-confidential meeting summary may still expose strategy if it includes project names, timelines, or vendor details. Another is regulated content, where privacy, legal, or sector rules override the normal productivity argument. Guidance is still evolving for low-risk prompts that include de-identified data, so organisations should label that area as “approved only with review” rather than assume universal consensus.
Training should also address shadow AI use. Employees often believe that if a tool is free, widely advertised, or popular, it must be acceptable. That is where policy reminders, browser banners, and targeted refresher training matter most. NHI Management Group’s Ultimate Guide to NHIs — Key Research and Survey Results is useful context for why identity, access, and data handling discipline must be consistent even when the “user” is a human acting through a public AI service. A mature program teaches employees to pause before pasting, verify whether a prompt contains restricted content, and default to approved tools whenever uncertainty exists.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AT-1 | Security awareness training directly supports safe AI use and data handling. |
| NIST SP 800-63 | Identity assurance matters when employees use personal or unmanaged accounts. | |
| NIST Zero Trust (SP 800-207) | AC-6 | Least privilege limits what can be exposed through approved AI workflows. |
| NIST AI RMF | GOVERN | Governance is needed to define acceptable AI use and accountability. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Secrets exposed to AI tools can become unrecoverable credentials risk. |
Restrict public AI access to approved identities and discourage use of unmanaged personal accounts for work data.
Related resources from NHI Mgmt Group
- What breaks when employees use AI tools inside browser sessions without data controls?
- How should security teams control shadow AI use when employees paste sensitive data into public models?
- How do organisations balance AI adoption with data protection when employees use GenAI tools?
- How can organisations tell whether AI tools are exposing data beyond policy intent?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
