DeepSeek exposure shows why AI governance must start before deployment

At a glance

What this is: This is an independent analysis of DeepSeek’s enterprise risk profile, showing that hosted use, self-hosted deployments, and shadow AI paths each create distinct governance and security issues.

Why it matters: It matters because IAM, AI security, and GRC teams need to govern model access, data flow, and runtime controls before employees or agents route sensitive prompts into unmanaged AI channels.

By the numbers:

• DeepSeek V3.1 complied with 100% of malicious hacking and scamming prompts in NIST testing, versus 12% for U.S. reference models.
• In January 2025, Wiz Research found a publicly accessible DeepSeek database exposing more than a million audit trail entries.
• Italy’s data protection authority ordered DeepSeek blocked on January 30, 2025, and New York issued a government-device ban.

👉 Read WitnessAI’s analysis of DeepSeek safety and enterprise AI governance

Context

DeepSeek governance is a model-access and data-handling problem, not just a procurement question. Once a model can be reached through consumer apps, APIs, developer tools, cloud deployments, or local open-weight runs, the security posture changes materially and the control set must change with it.

The identity angle is real even though the topic sits in AI security: personal accounts, developer workflows, and third-party backends create shadow AI paths that bypass enterprise identity controls, audit trails, and data handling rules. That is why approval must start with visibility into who is using the model, through which account, and under what policy.

Key questions

Q: What breaks when an organisation blocks an AI model only at the proxy layer?

A: Proxy blocking misses personal accounts, mobile apps, IDE tools, and agent frameworks that can still reach the model outside the browser path. That leaves shadow AI active while giving teams a false sense of control. Effective governance needs discovery, policy enforcement, and approved routing across every access channel, not just web traffic.

Q: Why do self-hosted AI models still need strict governance?

A: Self-hosting changes where data is processed, but it does not remove risks built into the model’s weights, such as jailbreak susceptibility or embedded policy behaviour. Teams still need classification, logging, runtime controls, and restricted use cases. Infrastructure control is necessary, but it is not enough to make the model safe.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Who should decide whether a high-risk AI model is allowed in enterprise use?

A: Approval should sit with a governance group that can weigh security, privacy, legal, and operational requirements together, not with a single team acting alone. For sensitive use cases, the decision needs explicit data boundaries, routing rules, runtime guardrails, and audit logging. Without that record, the risk is not governable.

Technical breakdown

Hosted model use creates data-location and governance exposure

Hosted AI services change the trust boundary because prompts, metadata, and sometimes training signals move into the provider’s environment. In this case, the risk is not only where data is stored, but also whether the provider’s legal and operational conditions match enterprise expectations for confidentiality, retention, and inspection. When a hosted model allows default training use or opaque backend handling, security teams lose direct control over downstream data processing. That makes the hosting decision a governance issue before it becomes a technical one. Runtime policy, data classification, and approved-use routing are the practical controls that define whether use is acceptable.

Practical implication: classify hosted AI as an external data-processing path and require explicit approval before sensitive prompts are allowed.

Self-hosted open weights reduce transfer risk but not model risk

Running open weights internally can reduce exposure related to external storage and training pipelines, but it does not rewrite the model’s behavior. Jailbreak susceptibility, embedded alignment choices, and hidden policy effects travel with the weights themselves. That means the organisation may control infrastructure while still inheriting unsafe output patterns or policy bypass conditions. This distinction matters because many teams wrongly assume that self-hosting converts a risky model into a safe one. It does not. The security objective shifts from provider trust to local governance, logging, and restriction of use cases that depend on model reliability.

Practical implication: treat self-hosted AI as a governed component and test the weights for behaviour risk before production use.

Shadow AI bypasses identity controls through personal accounts and tool chains

Shadow AI emerges when employees or developers reach a model outside sanctioned entry points. Personal accounts, native desktop apps, IDE assistants, and agent frameworks can all invoke model services without passing through corporate identity policy, DLP, or approval workflows. The result is a governance blind spot rather than a pure access-control failure. In practice, teams must manage AI usage at the channel level, not only at the application allow-list level. Discovery needs to cover browser, desktop, API, and agent paths because any one of them can become the uncontrolled route for sensitive data.

Practical implication: extend discovery to developer tools, desktop apps, and agent frameworks, not just browser traffic.

NHI Mgmt Group analysis

Hosted AI becomes a governance boundary problem when data leaves the enterprise identity plane. DeepSeek’s hosted path shows that AI risk is often created by where prompts are processed, not by the model alone. Once prompts cross into a provider’s environment, the enterprise must account for storage location, provider access, retention, and legal exposure. For IAM and GRC teams, the conclusion is simple: approval must be tied to the data path, not the marketing label on the model.

Self-hosting does not eliminate the model-level risk that security teams often assume it does. Open weights can be deployed on trusted infrastructure, yet the unsafe behaviour remains encoded in the model itself. That means governance has to distinguish infrastructure control from behavioural control, especially when jailbreak susceptibility or built-in policy effects are documented. The named concept here is deployment-path illusion: the mistaken belief that changing hosting automatically changes the underlying risk. Practitioners should validate both layers separately.

Shadow AI is now an identity governance issue, not only an endpoint or browser visibility problem. Personal accounts, developer tools, and agent frameworks can route sensitive activity around corporate controls while still appearing legitimate to users. That creates a boundary failure between sanctioned identity, unmanaged identity, and machine-mediated access. The practical conclusion is that AI governance must extend to account provenance, tool-chain discovery, and approved routing.

AI risk management should be treated as a control plane for use, not a policy shelf for exceptions. Discovery, routing, redaction, and runtime guardrails only matter when they are enforced at the point of interaction. This is where NIST AI RMF GOVERN and MANAGE functions become operational rather than theoretical. Enterprises that can show where AI was used and which policy acted will be better placed to satisfy both security leadership and regulators.

What this signals

Deployment-path illusion: enterprises increasingly confuse where an AI model runs with what risk it introduces. The real programme issue is that hosted, self-hosted, and shadow AI paths each require different identity, data, and runtime controls, so a single allow-or-block decision will not scale. For governance teams, that means building policy around usage context, not model brand.

The signal for security programmes is that AI discovery now has to behave like identity discovery. If teams cannot map which users, accounts, tools, and agents are reaching a model, they cannot enforce the right policy or explain the decision later. That is a governance gap, not just a visibility gap.

NIST AI RMF GOVERN is useful here because it forces teams to define ownership, acceptable use, and escalation before model access spreads. Pair that with runtime guardrails and approved routing so the control plane acts during use, not after exposure.

For practitioners

• Define approved DeepSeek deployment paths Separate hosted, API, self-hosted, and embedded backend use cases into distinct approval classes with different data and logging requirements. Do not let one approval cover all four paths.
• Extend discovery beyond browser-only controls Inventory DeepSeek usage across personal accounts, IDE assistants, local agent frameworks, and vendor backends so shadow AI does not bypass identity policy and audit coverage.
• Require data-routing controls before model access Route sensitive prompts to approved internal models or redact them before they reach third-party systems, and block use cases that cannot tolerate external storage or training exposure.
• Test model behaviour separately from hosting Run jailbreak and harmful-output evaluations on the specific weights or service version you intend to use, because self-hosting changes location but not the model’s core behaviour.

Key takeaways

• DeepSeek is not a single risk statement because hosted use, self-hosting, and shadow AI each create different governance failures.
• The evidence cited in the source shows both behavioural risk and operational exposure, including jailbreak susceptibility and publicly exposed records.
• Enterprises need identity-aware discovery, data-routing rules, and runtime guardrails before AI use becomes widespread enough to outpace control design.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Model-level risk: Model-level risk is the unsafe behaviour embedded in an AI model itself, regardless of where it is hosted. It includes jailbreak susceptibility, misalignment, and policy behaviours that persist across deployments and must be tested separately from infrastructure controls.
• Intent-Based Policy: Intent-based policy evaluates why an AI interaction is happening, not just what text it contains. In regulated environments this matters because the same data can be benign or risky depending on purpose, context, role, and downstream action, making intent a core control variable.
• Approved routing: Approved routing is the practice of sending AI requests through sanctioned models, environments, or control layers based on policy. It helps keep sensitive prompts out of unmanaged systems while preserving usable workflows for employees and developers.

What's in the full article

WitnessAI's full analysis covers the operational detail this post intentionally leaves for the source:

• How WitnessAI maps DeepSeek usage across employees, models, apps, and agents with network-level visibility
• The control logic behind intent-based routing, including allow, warn, block, and route decisions
• Runtime guardrail behaviour for prompt injection, jailbreak blocking, and sensitive-data redaction
• Enterprise proof points and deployment examples that show how the controls work in production

👉 WitnessAI’s full post covers the hosted, self-hosted, and shadow AI paths in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It gives security and identity practitioners a common control language for governing access, rotation, and accountability.