TL;DR: DeepSeek’s DDoS attack halted new registrations and exposed how AI services can fail when API, web, and platform identity controls are not built to absorb abuse, according to CyberArk. The incident reinforces that AI agent security needs machine identity, not just model hardening.
At a glance
What this is: This is a CyberArk analysis of the DeepSeek DDoS incident and related exposure, arguing that AI systems need machine identity controls to stay governable under attack.
Why it matters: It matters because IAM and NHI teams now have to treat AI services and AI agents as identity-governed systems whose credentials, tokens, and certificates can determine blast radius during disruption.
By the numbers:
- 92% of security leaders have concerns about the use of AI-generated code.
- 77% of global security leaders worry about data poisoning, where attackers manipulate training data to skew AI outputs.
- 75% are deeply concerned about AI model theft.
Context
AI systems now behave like operational services as much as models. Once they expose APIs, chat interfaces, and backend integrations, they inherit the same identity and availability problems that have long affected other internet-facing systems.
The DeepSeek incident is a machine identity problem because the service’s exposed interfaces, secrets, and database access were part of the attack surface. When AI platforms are reachable, their credentials and access paths become governance objects, not implementation details.
For identity programmes, the lesson is that AI deployment creates a new class of non-human access to secure. The control question is no longer only whether the model is safe, but whether the surrounding machine identities can be contained when the platform is pressured or abused.
Key questions
Q: What breaks when AI services expose secrets and backend access during a disruption?
A: The service loses the separation between availability, authentication, and administration. A DDoS event then becomes more than traffic saturation because exposed secrets or permissive backend access can turn ordinary pressure into control-plane compromise. The result is not just downtime, but a wider loss of containment and trust.
Q: Why do AI agents need their own identity instead of borrowed human credentials?
A: AI agents need their own identity because borrowed human credentials destroy auditability, make revocation imprecise, and expand blast radius. Separate identities let teams scope access to the agent’s task, revoke it without affecting the human user, and trace every action back to the actual executor. That separation is foundational for governance.
Q: What signs show that an AI platform's identity controls are failing?
A: Leaked API secrets, unauthenticated database access, shared credentials across agents, and backend functions reachable from public interfaces all indicate a weak trust boundary. If those signs appear together, the platform is treating identity as an implementation detail instead of a control plane.
Q: What should teams do after an AI service loses containment?
A: First, revoke the affected machine identities and isolate the exposed interfaces before the incident spreads further. Then restore the service only from known safe configurations, review every credential tied to the affected AI path, and confirm that agent access can be reissued with a narrower scope.
Technical breakdown
Why machine identity, not model hardening, is the control boundary
An AI model can be resilient in the narrow sense and still fail operationally if the service around it is exposed. Machine identities are the certificates, API keys, and access tokens that let AI services authenticate to databases, storage, and downstream tools. If those identities are leaked or overtrusted, an attacker does not need to break the model itself. They can use the surrounding trust fabric to reach data, change state, or keep the service unstable under load.
Practical implication: Treat AI service identities as production credentials with explicit scope, rotation, and revocation paths.
How DDoS, exposed secrets, and privilege escalation interact in AI services
DDoS is an availability attack, but it often becomes an identity problem when stressed services reveal secrets, fail open, or expose administrative functions. In the DeepSeek example, the article describes an exposed ClickHouse database with chat history, log streams, API secrets, and operational details, plus control of the database without authentication. That combination turns a traffic flood into a broader trust failure because the service’s access model no longer distinguishes routine load from hostile interaction.
Practical implication: Separate public-facing resilience controls from backend authentication and privilege controls so overload does not expose management paths.
Why autonomous AI increases the need for unique identities per agent
Agentic AI changes the stakes because each agent may act continuously, call tools, and access data without a human in the loop. That means identity cannot be shared, borrowed, or implied by the application. If multiple agents reuse the same credential set, containment becomes impossible when one agent misbehaves. Unique identities per agent allow policy to follow the actor rather than the platform, which is the only defensible way to preserve attribution, isolation, and rollback in autonomous workflows.
Practical implication: Assign a unique identity to each AI agent and bind its tool access to the smallest viable scope.
Threat narrative
Attacker objective: The attacker objective is to disrupt the AI service and expose enough operational access to undermine trust in the platform's control plane.
- Entry occurred through a distributed denial-of-service attack that targeted DeepSeek’s API and web chat platform, forcing the service to halt new registrations.
- Credential access and exposure were amplified when researchers found a ClickHouse database leaking chat history, log streams, API secrets, and operational details.
- Escalation followed because the exposed database allowed complete control without authentication, turning service visibility into administrative reach.
- Impact extended beyond disruption because the incident showed how AI services can lose trust, availability, and containment at the same time.
Breaches seen in the wild
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
- Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Machine identity is the control plane for AI availability. The DeepSeek case shows that AI service resilience is not just a model issue or a web uptime issue. When API keys, certificates, and access tokens define how the service reaches data and tools, their governance becomes the real boundary between disruption and containment. Practitioners should treat machine identity as the operational control that preserves AI trust under pressure.
Ephemeral AI access still needs identity governance: AI agents are not special exceptions to NHI discipline, they are another form of non-human access that can expand fast and fail fast. If an agent can act autonomously, then shared credentials, ambiguous ownership, and vague offboarding assumptions become structural weaknesses. The implication is that machine identity governance must be designed for the agent lifecycle, not just the application lifecycle.
Unchecked AI exposure creates identity blast radius. Once an AI platform exposes logs, secrets, and backend access together, a denial-of-service event can turn into a broader trust failure. That is not just an incident response problem. It shows that the surrounding identity model was built to assume calm, bounded access rather than hostile, high-volume interaction. Security teams should assume every externally reachable AI system has a measurable identity blast radius.
AI agent identity will become a standard governance category. The article points toward a market shift where AI platforms are evaluated not only on model capability but on how clearly they bind actions to identities. That pushes IAM and PAM teams into the AI control discussion earlier, because privilege, authentication, and containment all have to work before an agent is allowed to act. Practitioners should expect AI identity controls to become part of baseline architecture reviews.
Machine identity controls are how organisations make AI revocable. The practical meaning of an AI kill switch is not a dramatic shutdown button, but the ability to revoke, isolate, and reissue machine credentials cleanly. Without that, organisations can observe a problem but not stop the actor behind it. The field needs to stop framing AI governance as model oversight and start treating revocation, containment, and credential scope as core design requirements.
From our research library:
- 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.
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Identity blast radius is now a practical AI risk, not an abstract architecture term. When an AI system can expose secrets, query live data, and keep operating under load, the programme has to manage identity scope before it manages model behaviour. The boundary that matters is no longer just the prompt or the container, but the access path behind the interface.
The DeepSeek case also shows why AI governance has to move closer to NHI discipline. 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey. That pattern is dangerous because AI agents can multiply that privilege across workflows faster than conventional review cycles can react.
For practitioners
- Define a machine identity boundary for every AI service Inventory the certificates, API keys, and tokens used by AI workloads, then map each one to a named service owner and a single business function.
- Bind each AI agent to a unique credential set Do not let multiple agents share credentials or inherit human accounts, because shared identity destroys containment and attribution when behaviour goes wrong.
- Separate public availability from backend authority Design AI front ends so denial-of-service pressure cannot expose management functions, database control, or secrets stored behind the interface.
- Test revocation as a live control, not a paper process Practice disabling AI access paths, rotating credentials, and restoring the last known safe state so a compromised agent can be contained quickly.
- Monitor AI systems for anomalous access patterns Watch for abnormal token use, unexpected database queries, and tool access that falls outside the agent's normal operating scope.
Key takeaways
- AI services fail when their surrounding machine identities are overexposed, not only when the model itself is attacked.
- The DeepSeek incident combined availability pressure with credential and database exposure, which widened the blast radius beyond a simple outage.
- Unique identities, narrow privilege, and tested revocation are the controls that make AI systems governable under real attack conditions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed API secrets and leaked database access in an AI service. |
| NHI-04 — Insecure Authentication | Unauthenticated database control and weak access boundaries are core to the incident narrative. | |
| NHI-05 — Overprivileged NHI | The piece argues AI systems become dangerous when their machine identities carry excessive access. | |
| Recommendation — Scan AI service paths for exposed secrets and revoke any leaked machine credentials immediately. Enforce authenticated access for AI back ends and remove any unauthenticated control paths. Reduce AI service privilege to the minimum scope needed for each workload and integration. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The incident combines secret exposure with service disruption and control loss. |
| Recommendation — Map exposed AI credentials to Credential Access and treat DDoS disruption as an impact multiplier. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on managing tokens, certificates, and API keys used by AI services. |
| Recommendation — Apply authenticator management to rotate, revoke, and monitor AI service credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core problem is excessive and poorly bounded access around AI services. |
| Recommendation — Document and restrict AI service entitlements so each identity only reaches the resources it needs. | ||
Key terms
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- AI Kill Switch: An AI kill switch is a containment mechanism that can pause, isolate, revoke, or roll back an AI system when it behaves unpredictably or is under attack. It is implemented through identity revocation, access shutdown, and safe-state restoration, not through a single physical or software button.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 29, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org