DeepSeek exposure shows how fast AI security becomes an NHI problem

At a glance

What this is: This is an analysis of DeepSeek’s rapid adoption and the security issues that emerged around exposed data, model behavior, and unmanaged AI use.

Why it matters: It matters because AI tools behave like non-human identities, so IAM teams must govern their access, secrets, and discovery before shadow use becomes a control failure.

By the numbers:

• DeepSeek hit #1 in the Google Play Store on January 27, sending stocks tumbling and contributing to a nearly $600 billion loss to Nvidia’s market value.
• Enkrypt AI found DeepSeek’s R1 model was 11x more likely to generate harmful outputs than OpenAI’s O1, according to the source article.

👉 Read DeepSeek’s timeline of AI security concerns and credential exposure

Context

AI adoption becomes an IAM problem the moment a tool receives credentials, stores prompts, or connects to internal systems. In this case, DeepSeek was discussed not just as a model provider but as a fast-moving AI surface with exposure risks that touch secrets, data handling, and policy enforcement. For IAM and NHI practitioners, that makes the security question broader than content safety alone.

The governance gap is that many organisations still treat AI usage as an application choice rather than an identity and access problem. Once employees authenticate with corporate credentials, once data is logged, or once autonomous workflows touch tools, the environment creates NHI-style exposure that must be discovered, classified, and controlled. That starting position is increasingly common rather than exceptional.

For background on the broader risk pattern, see the Ultimate Guide to NHIs , Why NHI Security Matters Now and the OWASP NHI Top 10.

Key questions

Q: How should security teams govern AI tools that use corporate credentials?

A: Security teams should treat those tools as non-human identities and govern them through discovery, classification, least privilege, and log review. Corporate authentication creates organisational trust, so the AI service must be assigned an owner, a data-handling profile, and an access boundary before broad use is allowed.

Q: Why do AI platforms create NHI risk even when user sessions are short?

A: Short sessions do not remove the underlying trust relationship. If the platform stores prompts, logs, API keys, or backend details, the exposure persists after logout. That is why NHI controls must cover retention, telemetry, and secret handling, not only real-time access.

Q: What is the difference between model safety and NHI governance?

A: Model safety focuses on what the system can say or refuse to say. NHI governance focuses on what the system can access, retain, and expose across tools, identities, and data stores. Both matter, but they solve different risk layers and need different controls.

Q: When should organisations block an AI service rather than permit it?

A: They should block or constrain a service when it cannot prove acceptable handling of credentials, telemetry, and sensitive data. If discovery shows shadow use, poor visibility, or uncontrolled retention, the safer decision is to deny access until minimum governance requirements are met.

Technical breakdown

How exposed AI logs become an NHI security problem

When AI systems record chat history, operational metadata, backend details, or API secrets, the logs themselves become a credential reservoir. That changes the attack surface because log access can reveal tokens, service endpoints, and internal workflow context that should never be broadly readable. For NHI governance, the issue is not only the model’s output. It is the data exhaust around the model, which often inherits weaker controls than production systems. If logging pipelines are not classified and restricted, they can turn routine observability into silent privilege leakage.

Practical implication: Treat AI telemetry as sensitive identity data and restrict it with the same controls used for secrets and service-account material.

Model policy bypasses and hidden parameters

A model that can be coaxed into revealing hidden system parameters or restricted technical details exposes a different failure mode from ordinary data leakage. The control problem is prompt-level influence combined with weak guardrails around what the model is permitted to reveal. This matters because the attacker does not need shell access to extract operational insight. In agentic environments, policy bypass can expose system instructions, tool logic, or integration details that support later abuse of connected services. That makes the boundary between model safety and access control much thinner than many teams assume.

Practical implication: Review prompt, instruction, and tool-access boundaries as part of NHI threat modeling, not as a separate AI safety task.

Shadow AI discovery and corporate credential use

Shadow AI appears when employees use external AI tools without inventory, approval, or monitoring. The NHI connection is straightforward: once corporate credentials are used, the tool inherits organisational trust, and any connected data or actions may sit outside normal governance. Discovery matters because teams cannot secure what they cannot enumerate. Classification matters because some AI tools should be allowed only for low-risk use cases, while others need explicit blocks or tighter conditional access. The core architectural lesson is that AI use must be tied to identity inventory, not just acceptable-use policy.

Practical implication: Link SaaS discovery, identity inventory, and policy enforcement so unmanaged AI use is visible before access spreads.

Threat narrative

Attacker objective: The attacker aims to extract secrets, operational metadata, and system instructions that enable deeper access to AI-connected environments.

1. Entry via public exposure of a ClickHouse database that contained chat history, secret keys, backend details, and operational metadata.
2. Escalation through use of leaked secrets and inferred system details to probe model restrictions and hidden parameters.
3. Impact through unauthorized access to sensitive data and internal AI operation details that can support broader abuse.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DeepSeek illustrates the identity problem hidden inside AI adoption. The security debate often starts with model quality, bias, or safety filters, but the practical risk arrives through credentials, telemetry, and connected tools. Once those components are in play, AI systems behave like NHIs and must be governed accordingly. Practitioners should treat AI adoption as an access-control program, not just an application review.

Ephemeral usage does not remove trust debt. Fast-moving AI services can still ingest sensitive inputs, retain logs, and expose backend context even when user sessions are short-lived. That creates a false sense of safety if teams equate temporary interaction with temporary risk. The real issue is whether the surrounding control plane knows what the AI can see, store, and disclose. Security teams should measure the blast radius of every AI connection.

Shadow AI is now a discovery and classification problem. The article’s core warning is not that one tool is dangerous, but that AI adoption can outpace policy by orders of magnitude. When 15,000 applications already embed AI, unmanaged access paths are no longer edge cases. The named concept here is AI identity drift: when an AI tool’s access, data handling, and governance status change faster than the organisation can inventory and reclassify it. Practitioners should build controls that keep pace with that drift.

Model safety and NHI governance must converge. A bypassed model is not only a content moderation issue if it can reveal instructions, secrets, or operational details tied to enterprise systems. That makes AI controls part of the broader identity perimeter, alongside secrets management, least privilege, and logging review. The implication is clear: teams need one governance model for what the AI says and another for what the AI can access, with both tied to identity.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% at no or low visibility and 47% at only partial visibility.
• That visibility gap is why the control conversation must extend beyond model behaviour and into identity discovery, as framed in the OWASP NHI Top 10.

What this signals

AI identity drift: AI services tend to accumulate access, logs, and trust faster than governance teams can inventory them. That means the operational question is not whether AI will be adopted, but whether discovery, classification, and control can keep pace with changing access paths.

The visibility gap is already large enough to justify stronger guardrails. Only 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, which is a warning sign for any AI program that relies on delegated access.

Practitioners should align AI governance with the NIST Cybersecurity Framework 2.0 so discovery, protect, detect, and respond activities cover AI-connected identities as well as human users.

For practitioners

• Inventory corporate AI usage Use SaaS discovery and identity logs to identify which employees are accessing AI services with corporate credentials, then classify those services by risk and data handling.
• Restrict sensitive AI telemetry Treat chat history, prompts, backend metadata, and audit logs as sensitive identity-linked data. Limit access to those logs, encrypt them, and review retention settings for secret leakage.
• Separate model safety from access governance Review where prompt safety ends and identity control begins. Map each AI system’s tool access, data retention, and escalation paths to an owner and an enforcement point.
• Block or constrain high-risk AI tools For tools that cannot meet your minimum control requirements, apply deny-by-default policies, user notifications, and compensating education so corporate access does not become unmanaged trust.

Key takeaways

• AI platforms become NHI risks once they handle credentials, logs, or connected tools.
• Exposure in telemetry and backend metadata can matter as much as the model’s visible output.
• Discovery, classification, and least privilege are the practical controls that keep AI adoption governable.

Key terms

• Shadow AI: Shadow AI is the use of AI services or agents that security and governance teams have not discovered or approved. The risk is not just unauthorized software, but unmanaged identity, data retention, and access paths that can bypass normal controls and create hidden exposure.
• AI Identity Drift: AI identity drift is the gap that appears when an AI service’s access, retention, or governance status changes faster than the organisation can inventory it. The term captures how quickly a tool can move from low-risk use to a high-trust integration without matching controls.
• Non-Human Identity: A non-human identity is any machine- or software-based identity that authenticates to systems and performs actions on behalf of a process, workload, bot, or agent. In AI environments, these identities often control data access, API calls, and tool use, making them central to governance and blast-radius control.

Deepen your knowledge

AI identity drift and shadow AI discovery are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for corporate AI use, the course gives you the governance baseline to start from.

This post draws on content published by DeepSeek: The hidden security risks of AI. Read the original.