Model governance focuses on AI systems that an organisation builds or fine-tunes, including training data, evaluation, and bias. Shadow AI governance focuses on employee use of third-party AI tools and the data sent into them. The first controls how systems are made, while the second controls how workers interact with outside services.
Why This Matters for Security Teams
Model development governance and shadow ai governance are often confused because both involve AI risk, but they address different control planes. Model governance is about what an organisation creates, trains, tests, and releases. Shadow AI governance is about what employees paste into external tools, what those tools retain, and how that data can later be reused, exposed, or trained into another system. The distinction matters because the control objectives, owners, and evidence are not the same.
Security teams that treat shadow AI as a model risk problem usually focus on approvals and documentation, then miss the real exposure: sensitive data leaving the organisation through unsanctioned SaaS, browser extensions, and consumer chat tools. That makes the issue less about model quality and more about data handling, access control, and acceptable use enforcement. NIST CSF 2.0 helps frame this as a governance and protection problem, while NHIMG research such as Top 10 NHI Issues shows how quickly identity and secret misuse becomes an operational risk in AI-enabled environments.
In practice, many security teams encounter shadow AI only after sensitive prompts, source code, or customer data have already been copied into a third-party service.
How It Works in Practice
Model governance should start at the build stage. That means controlling training data provenance, fine-tuning inputs, evaluation criteria, safety testing, and release approvals. It also means documenting who can retrain a model, what datasets are allowed, and how changes are reviewed before deployment. For organisations building or adapting models, this aligns to a lifecycle approach like the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because the identity and access controls around model pipelines matter as much as the model itself.
Shadow AI governance is different. The goal is to reduce what workers can expose to external AI services and to detect where those services are being used outside approved channels. Typical controls include:
- Acceptable-use policy for approved and prohibited AI tools.
- Data classification rules that block regulated, confidential, or source-code content from being shared externally.
- CASB, DLP, browser, and endpoint controls to detect prompt leakage and unsanctioned use.
- Vendor review for retention, training use, logging, and data residency terms.
- Identity-aware access where internal AI services are preferred over consumer tools for sensitive work.
For build-side governance, the evidence trail should show model cards, training records, evaluation results, and sign-off gates. For shadow AI, the evidence trail should show policy enforcement, user awareness, and monitoring outcomes. The threat becomes especially visible when identity artifacts are abused, as discussed in NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where compromised access can be used to reach AI services and infrastructure. These controls tend to break down in BYOD-heavy environments because personal browsers, unmanaged devices, and consumer AI accounts sit outside normal enterprise enforcement.
Common Variations and Edge Cases
Tighter AI controls often increase user friction, so organisations must balance developer productivity and employee convenience against the need to prevent data leakage and unsafe model changes. Best practice is evolving here, and there is no universal standard for how much shadow AI monitoring is acceptable without creating privacy or labour-relations concerns.
One common edge case is when a business unit uses a third-party foundation model through a paid enterprise subscription. That is not pure shadow AI if procurement, security review, and identity controls are in place, but it is still not the same as internal model governance. Another edge case is employee-built internal copilots that use external APIs. Those systems sit in both domains: the organisation must govern the model integration and also control what data is sent out.
NHIMG’s DeepSeek breach and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce the same practical point: governance is not only about whether an AI system is approved, but whether data, identities, and downstream usage are controlled after exposure. For AI builders, that means lifecycle governance; for shadow AI, it means usage governance and outbound data control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | Shadow AI often exposes prompts and data through unsafe agent/tool interactions. |
| OWASP Non-Human Identity Top 10 | NHI-01 | AI services rely on identities and secrets that are often abused in shadow use. |
| CSA MAESTRO | Separates governance of agentic systems from unmanaged external AI usage. | |
| NIST AI RMF | AI RMF distinguishes lifecycle governance from misuse of third-party AI services. | |
| NIST CSF 2.0 | PR.AC-1 | Access control is central to limiting who can use which AI tools and data. |
Apply governance, mapping, and monitoring to both build-side and user-side AI risk.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
