Organisations should approve only specific AI services for company data and enforce that policy technically at the endpoint or network layer. Acceptable-use statements alone are not enough. Security teams also need visibility into what content is being pasted, which identities are using the tools, and whether the service retains or reuses that material.
Why This Matters for Security Teams
When employees paste source code, product plans, customer data, or research notes into AI tools, intellectual property can leave the organisation faster than traditional data loss channels. The risk is not limited to accidental disclosure. Some AI services retain prompts, reuse content for training, or expose material through shared workspaces, plugins, or connected accounts. Governance has to treat AI tools as data destinations, not just productivity software.
This matters because policy-only controls rarely survive day-to-day usage. If users can access unsanctioned services from unmanaged devices, the organisation loses control over where sensitive material goes and how long it persists. A sound response aligns acceptable use, data classification, endpoint enforcement, and identity visibility so that the security team can see who used which tool, from where, and with what content sensitivity. That is consistent with the risk-based approach in the NIST Cybersecurity Framework 2.0.
In practice, many security teams only discover exposure after a sensitive prompt has already been copied into an external service and cannot be retrieved.
How It Works in Practice
Protecting intellectual property in AI workflows requires layered control. The first layer is classification: organisations need clear rules for what may never be entered into external AI tools, what may be used only in approved enterprise instances, and what requires redaction or summarisation before use. The second layer is technical enforcement. That usually means blocking unsanctioned AI domains at the secure web gateway, browser, CASB, or endpoint control layer, then allowing only vetted services with appropriate contractual and privacy terms.
Identity control is equally important. Security teams should tie AI usage to corporate identities rather than anonymous or personal accounts, because auditability depends on knowing who submitted the content. Session logging, prompt logging where lawful, and DLP-style content inspection can help detect source code, secrets, contracts, or regulated data being shared with external models. For higher-risk teams, organisations should require approved enterprise AI tenants with retention limits, admin controls, and clear data-use guarantees.
- Define which data classes are prohibited, restricted, or allowed in AI tools.
- Restrict access to approved services through policy enforcement, not reminders.
- Bind usage to managed identities and monitor for shadow IT accounts.
- Review vendor retention, training, and deletion settings before approval.
- Log and investigate high-risk submissions such as code, credentials, and IP.
Current guidance suggests treating AI tool access as both a security and governance problem, because the same prompt can create leakage, compliance, and contractual issues at once. This approach aligns well with AI risk management principles in NIST AI Risk Management Framework and with model-use controls discussed by the MITRE ATLAS community for adversarial and misuse scenarios. These controls tend to break down when employees rely on personal devices and consumer AI accounts because the organisation cannot reliably enforce policy or capture audit evidence.
Common Variations and Edge Cases
Tighter AI controls often increase friction for developers, analysts, and knowledge workers, requiring organisations to balance productivity against confidentiality. That tradeoff is especially visible when teams need generative AI for drafting, summarising, or coding, but the underlying source material includes trade secrets or customer-sensitive data.
Best practice is evolving for several edge cases. There is no universal standard for whether prompts should be logged in full, partially redacted, or excluded entirely in every environment. Legal, privacy, and labour rules can shape that decision. For highly regulated sectors, organisations may need separate approval paths for legal, HR, financial, or R&D content. For software teams, source code deserves special treatment because even small snippets can reveal architecture, keys, or proprietary logic. For agentic ai workflows, the risk expands further because an agent may call tools, retrieve documents, or write data to systems without a human seeing each step.
Where personal AI accounts are already embedded in work habits, enforcement should focus on reducing exposure quickly rather than seeking perfect elimination on day one. In those cases, organisations often need a staged approach that combines policy, endpoint restriction, SaaS allowlisting, and user education. The practical failure point is not lack of awareness; it is unmanaged access paths that let sensitive content leave through approved-looking but ungoverned channels.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Protects data by limiting where sensitive IP can be sent or stored. |
| NIST AI RMF | Addresses governance and risk management for AI use involving proprietary material. | |
| MITRE ATLAS | Useful for misuse scenarios like prompt injection and data exfiltration via AI tools. | |
| OWASP Agentic AI Top 10 | Relevant where AI assistants or agents can move or expose company IP through tool use. | |
| NIST AI 600-1 | Helps govern GenAI use cases that may retain or reuse organisational content. |
Classify AI data paths and enforce controls that prevent sensitive content from leaving approved systems.
Related resources from NHI Mgmt Group
- How should organisations govern AI usage when employees use unapproved tools?
- How should organisations audit AI use that happens outside approved tools?
- Should organisations let AI agents use the same login flow as employees?
- What breaks when employees use AI tools inside browser sessions without data controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
