They should define trusted destinations, then block or mask sensitive data when it tries to leave those boundaries. The key decision is not whether AI is allowed in general, but which tenant, account type, and application may receive specific data classes. That approach gives security teams a practical way to separate approved work from shadow AI use.
How to define trusted destinations for AI data movement
Governance starts by making the destination, not the model, the control point. Teams need an explicit allowlist of approved tenants, accounts, and applications that may receive each data class, then apply policy at the point of transfer so that sensitive material is blocked, redacted, or downgraded before it crosses into an untrusted boundary. That is the practical way to separate sanctioned use from shadow AI use.
The useful question is whether the receiving tenant is inside the trust boundary for the specific data, not whether the AI tool is popular or enterprise branded. A tenant may be sanctioned for low-risk content and still be inappropriate for regulated, confidential, or operationally sensitive data. In practice, the control model has to look at data class, tenant provenance, account type, and application purpose together.
When teams do this well, the policy is understandable to security, privacy, and platform owners alike. They can say, for example, that one class of content can go to a managed enterprise tenant, another can only be summarized locally, and the most sensitive material cannot leave approved systems at all. The NIST Cybersecurity Framework 2.0 is a useful governance lens here because it connects data handling rules to risk management, protection, detection, and recovery.
What to enforce when sanctioned and unsanctioned tenants coexist
Once the trust boundary is defined, enforcement should be granular enough to stop accidental over-sharing but simple enough to operate at scale. That usually means combining classification, destination awareness, and conditional controls, so the same document can be treated differently depending on which tenant, app, or user path is trying to send it out. If a destination is not on the trusted list, the safest default is to block, redact, or convert the payload into a safer form.
For AI tenants, the biggest mistake is treating all enterprise SaaS or model-hosting accounts as equivalent. They are not. A sanctioned tenant with strong contractual and technical controls is different from a personal account, a trial workspace, a third-party embedded feature, or a consumer chatbot. The governance policy should reflect that difference explicitly, because the risk comes from where the data lands and who controls that environment.
This is also where inventory matters. If teams cannot tell which AI tenants and applications are actually in use, they cannot enforce destination rules consistently. The Shadow AI and AI Agent Discovery Guide supports that governance step by showing how to find unmanaged AI apps and agents through OAuth grants, API keys, cloud, endpoint, and network signals before they become blind spots. For cloud control mapping, the CSA Cloud Controls Matrix is also relevant because it treats IAM and cloud data governance as operational control areas rather than abstract policy statements.
How to keep data controls effective when AI use changes quickly
Data movement policy should be designed as a living control, not a one-time approval exercise. AI adoption changes quickly, and new tenants, connectors, browser plug-ins, and embedded assistants appear faster than most review processes. Teams therefore need repeatable control points, such as egress filtering, DLP rules, sanctioned connector inventories, and exception review, so policy remains current when users change tools.
The best operating model is to make exceptions explicit and short-lived. If a business group needs to use an unsanctioned tenant for a legitimate purpose, that should trigger a review of destination risk, data class exposure, and retention implications. That is materially different from silently allowing the transfer and hoping downstream use is acceptable.
Control assurance should also cover leakage via credentials and connectors, not only the content itself. A tenant that is technically approved can still become a high-risk destination if its access model is too broad, its secrets are exposed, or its connector permissions allow later reuse of the same data elsewhere. The Microsoft SAS token exposure 2023 is a clear reminder that long-lived, over-permissive access can turn a data movement decision into a large-scale exposure event. For broader control alignment, NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful for access control, auditability, and information flow enforcement.
Risk and Threat Considerations
When sanctioned and unsanctioned AI tenants are both in circulation, the main risk is uncontrolled data exfiltration through a path that users perceive as routine. Sensitive data can leave approved systems through copy-paste, uploads, connectors, or API-based integrations before any downstream review happens, which makes the destination boundary more important than the model brand.
Failure mechanism: The control fails when teams approve AI use at a general level but do not enforce destination-specific rules for each data class. Users then route information into personal, third-party, or weakly governed tenants that retain, reuse, or expose the data beyond the intended boundary.
Impact: The result can be confidentiality loss, policy breach, regulatory exposure, or irreversible propagation of sensitive content into systems the organisation does not fully control. At scale, the same weakness also creates shadow IT visibility gaps, because the organisation loses sight of where its data is actually being processed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Sets risk-based rules for approved AI destinations and data movement boundaries. |
| PR.DS-01 — Data-at-rest is protected | Supports protecting sensitive data that may otherwise leave governed environments. | |
| PR.AA-05 — Identity Management, Authentication and Access Control | Controls who and what may send data into approved AI tenants and apps. | |
| Recommendation — Define risk thresholds for sanctioned AI tenants and enforce destination controls by data class. Classify sensitive data and apply protection before it can move into AI tenants. Restrict AI data transfers to approved identities and applications only. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Directly governs tenant, account, and application access for cloud-hosted AI use. |
| Recommendation — Map AI tenants to IAM policy so only approved accounts can receive sensitive data. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Relevant where API-connected AI tools can access data they should not receive. |
| Recommendation — Authorise each data object before it can be sent to an AI tenant. | ||
| ISO/IEC 27001:2022 | A.5.14 — Information transfer | Covers policy and controls for transferring information between internal and external services. |
| Recommendation — Apply transfer rules that distinguish sanctioned from unsanctioned AI destinations. | ||
Practitioner Guidance
What to prioritise: Start with the data classes that would be most damaging if they reached the wrong tenant, then define the approved destinations for each class before broadening the policy to lower-risk content. That sequence keeps the control focused on blast radius rather than on blanket AI restrictions.
What to verify: Confirm that the enforcement point can distinguish sanctioned from unsanctioned tenants in the actual workflow, not just in policy documents. If the control cannot see the destination, the exception process, or the connector path, it is not governing movement, only documenting intent.
Practitioner takeaway: The strongest pattern is destination-based governance with data-class sensitivity. If you can reliably decide where each data type may go, most of the shadow AI problem becomes a policy enforcement problem instead of an open-ended prohibition problem.
Related resources from NHI Mgmt Group
- How should security teams govern AI-assisted data movement across endpoints?
- How should teams govern data handling across sanctioned and unsanctioned apps?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern AI access to sensitive data across hybrid environments?