Employees should avoid sharing secrets, credentials, internal code, personal data, and confidential business information unless the organisation has approved that specific platform and use case. Anything that would be unsafe to post publicly should be considered unsafe to prompt into an AI tool.
Why This Matters for Security Teams
ChatGPT-style tools can turn a routine drafting task into a data exposure event when employees paste secrets, customer records, source code, contracts, or incident details into a prompt. The risk is not just accidental disclosure. Prompts may be stored, reviewed, used for model improvement, or copied into connected workflows. That makes prompt hygiene part of access control, data protection, and third-party risk management, not just user etiquette.
Current guidance suggests treating any prompt as potentially persistent and externally observable unless the platform contract and configuration prove otherwise. That aligns with the NIST Cybersecurity Framework 2.0 emphasis on protecting data and managing third-party dependencies. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which is why prompt-sharing mistakes can become real compromise paths rather than harmless productivity shortcuts, as covered in the Ultimate Guide to NHIs.
In practice, many security teams encounter AI-related leakage only after a secret has already been pasted into a public or unmanaged tool, rather than through intentional review of prompt behaviour.
How It Works in Practice
The safest operational rule is simple: employees should not share anything that would be unsafe to place in a public ticket, email thread, or shared document. That includes passwords, API keys, session tokens, certificates, private keys, internal architecture diagrams, unreleased code, regulated personal data, and confidential business information. For organisations that approve specific AI tools, the policy should define what data types are allowed, what redaction is required, and whether prompts are retained for training or support.
Security teams should pair user guidance with technical controls. For example, data loss prevention can detect secrets or regulated data before submission, while approved enterprise platforms can enforce tenant isolation, retention limits, and access logging. The governance model should also cover connected tools, because a harmless-looking prompt can still trigger retrieval from documents, repositories, or ticketing systems. That is why the Ultimate Guide to NHIs is relevant here: secrets and service account material are often the real objects of abuse, not the model itself.
- Classify prompts by data sensitivity before users get access.
- Block obvious secrets and regulated data at the endpoint or gateway.
- Allow only approved tools with documented retention and training settings.
- Log usage so security can investigate abuse or accidental disclosure.
Use case-specific exceptions are possible, but they should be approved in advance and paired with redaction or synthetic data. These controls tend to break down when employees use consumer AI accounts from unmanaged devices because the organisation loses visibility into both prompt content and downstream retention.
Common Variations and Edge Cases
Tighter prompt restrictions often increase friction for employees, requiring organisations to balance productivity against the risk of accidental disclosure. That tradeoff is real: developers, analysts, and support teams often want fast access to AI tools, but the same workflows can expose credentials or sensitive case data if the policy is too broad or too vague.
Best practice is evolving on how to handle low-risk internal content, anonymised data, and model-assisted coding. Some organisations permit limited use of internal text after redaction, while others prohibit all confidential input unless the platform is contractually approved. There is no universal standard for this yet, but the policy should always treat secrets, credentials, and personal data as off-limits unless a specific exception exists.
Edge cases matter. Paste-in code snippets may look harmless but can contain hard-coded keys, endpoint URLs, or business logic that should stay internal. Likewise, screenshots and copied logs can reveal tokens or customer identifiers even when the user did not intend to share them. A practical control set should therefore combine user training, DLP, secure approved tools, and clear escalation paths for exceptions. For broader governance patterns, the same principles also map to the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0, both of which reinforce controlled handling of sensitive information rather than trust-by-default sharing.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Prompt input can expose sensitive data that needs protection in transit and at rest. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Secrets and credentials are core NHI assets that must not be exposed in prompts. |
| NIST AI RMF | AI risk governance must address data handling, privacy, and misuse in user prompts. |
Prevent employees from pasting credentials or tokens into AI tools and add detection at the prompt layer.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
