Topic starter
23/03/2026 3:25 pm
TL;DR: DeepSeek’s rapid growth was followed by a public ClickHouse database exposing more than a million log lines with chat history, secret keys, backend details, and API secrets, while model restrictions were also bypassed, according to Wing Security. The security lesson is that AI adoption becomes an NHI governance problem as soon as credentials, logs, and unmanaged access paths exist.
Editorial analysis by NHI Mgmt Group, based on content published by Wing Security: “DeepSeek – The hidden security risks of AI”.
Key questions
Q: What breaks when an AI app exposes logs or secrets?
A: The first failure is that telemetry stops being passive evidence and becomes an access path.
Q: Why do exposed AI secrets create more risk than ordinary cloud credentials?
A: AI secrets often sit between data sources, model access, and downstream business systems, so a single key can expose prompts, outputs, and linked datasets while also enabling access to adjacent services.
Q: What signs show that AI access sprawl is getting out of control?
A: Look for broad admin-consented permissions, agents targeting many services, unknown owners, dormant connections and disconnected approval records.
Practitioner guidance
- Discover AI app usage across corporate identities Identify which users are accessing AI tools with corporate credentials, including shadow IT and unsanctioned browser use, so that access can be tied back to an owner and a review cycle.
- Classify exposed AI services as forbidden when needed Use policy enforcement to block high-risk AI services that expose secrets, backend details, or unrestricted data handling, and notify users when access must be removed.
- Inventory log and secret exposure paths Review where AI services write chat history, backend metadata, tokens, and API secrets, then remove those values from logs and telemetry pipelines before they become reusable access material.
Bottom line: DeepSeek’s exposure shows that AI adoption can become an identity governance problem as soon as credentials, logs, and delegated access are involved.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 4:29 pm
AI application security becomes NHI governance the moment the service handles credentials: The DeepSeek case shows that model adoption is rarely confined to model behavior. It creates an operational identity surface made up of API secrets, log streams, backend accounts, and connected applications. The practitioner implication is that AI governance has to include non-human identity ownership, scope, and revocation, not just acceptable-use policy.
A few things that frame the scale:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations treat AI model safety and access control as separate problems?
A: Yes. Model safety controls govern what the system outputs, while access control governs who can reach the system and what it can touch. A blocked prompt does not remove exposed credentials, unreviewed integrations, or unsafe log retention, so both layers must be governed independently.
👉 Read our full editorial: DeepSeek exposure shows how fast AI security becomes an NHI problem