DeepSeek’s DDoS exposure shows why AI needs machine identity controls

At a glance

What this is: This is an analysis of the DeepSeek DDoS incident and the argument that machine identity security is the control layer AI systems need to survive abuse and escalation.

Why it matters: For IAM and NHI practitioners, it shows why AI agents and AI services need unique identities, monitored credentials, and containment controls before they become operational dependencies.

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.

👉 Read CyberArk's analysis of the DeepSeek DDoS incident and machine identity controls

Context

Machine identity security is the discipline of binding authentication, authorization, and monitoring to non-human identities such as API keys, certificates, and tokens. In AI environments, that matters because the model, its agent wrapper, and the services it calls can all become trust boundaries that attackers target when availability or access controls are weak. This DeepSeek incident is a reminder that AI security is not only about model quality or prompt safety; it is also about controlling the identities that let the system operate.

The governance gap is broader than one DDoS event. AI systems increasingly sit inside business workflows, and once they can call tools, read data, or trigger actions, the same identity failures that affect service accounts and other NHIs begin to apply. That makes machine identity controls part of the operating model for AI adoption, not a niche hardening step. The starting point here is typical for fast-moving AI programs: capability first, governance later.

Key questions

Q: How should security teams govern AI agents that use API keys and tokens?

A: Treat each AI agent as a non-human identity with its own credentials, permissions, and logging. Do not share keys across agents or workflows. Scope access to the narrowest possible task, rotate secrets on a schedule, and require revocation paths that can cut off the agent quickly if behaviour changes or abuse is detected.

Q: What is the difference between machine identity security and model security?

A: Model security protects the AI model from tampering, misuse, or harmful output, while machine identity security protects the credentials and trust paths that let the system operate. In practice, machine identity controls decide who or what can call the model, reach data, and trigger actions. Both matter, but identity failures often create the faster path to impact.

Q: When does just-in-time access make AI operations safer?

A: Just-in-time access helps when an AI agent needs elevated permissions only for a discrete task, such as pulling a record or updating a workflow. It reduces the time an attacker can reuse stolen credentials. It becomes less effective when access is broad, poorly logged, or granted automatically without clear task boundaries and revocation rules.

Q: Why do AI systems complicate zero trust architecture?

A: AI systems complicate zero trust architecture because they are autonomous consumers of data and tools, not static services with fixed behaviour. Their access patterns can change by task, prompt, or model output. Zero trust still applies, but teams must continuously verify machine identities, permissions, and actions rather than assume a stable workload profile.

Technical breakdown

Why machine identities are the real control plane for AI systems

AI systems rarely act alone. They authenticate through certificates, tokens, API keys, and other machine identities that determine what data they can access and what actions they can take. If those identities are shared, over-privileged, or poorly monitored, the AI layer inherits the same weaknesses seen in service-account abuse and secrets leakage. In agentic environments, the problem deepens because an autonomous agent can chain tool calls, reuse credentials, and amplify a small compromise into broader operational impact. Security teams should treat each agent and service as a distinct identity with narrow scope.

Practical implication: Assign unique identities to AI agents and tie every privileged action to monitored credentials.

How kill-switch controls work in AI incident response

A kill switch is not a literal button. It is a set of containment mechanisms that can pause, revoke, isolate, or roll back an AI system when it behaves unexpectedly or is under active attack. In practice, that means revoking API tokens, disabling tool access, freezing outbound calls, and restoring the last known safe configuration. The design goal is to stop ongoing abuse before an attacker can pivot from model access into data theft, fraud, or supply-chain spread. That makes availability and containment inseparable from identity governance.

Practical implication: Pre-stage revocation and rollback paths so response teams can cut off compromised AI access within minutes.

Why zero standing privilege matters for agentic AI

Agentic AI increases the risk of standing privilege because agents often need access to multiple systems across a task workflow. Zero standing privilege, or ZSP, reduces that exposure by issuing rights only for the task at hand and only for the shortest necessary time. The control is especially relevant when an agent can trigger external tools or operate at machine speed, because persistent credentials create a durable attack path. ZSP works best when paired with continuous verification, step-up approval for high-risk actions, and strict separation between read, write, and execute permissions.

Practical implication: Use just-in-time access for AI agents instead of leaving persistent credentials active across workflows.

Threat narrative

Attacker objective: The objective is to disrupt AI availability and, where possible, turn that disruption into broader identity abuse or data exposure.

1. Entry occurs when attackers target externally exposed AI services, such as API endpoints or web chat interfaces, to exhaust availability or probe for weak controls.
2. Escalation occurs if exposed secrets, broad API permissions, or shared machine identities let the attacker move from nuisance traffic into privileged access.
3. Impact occurs when the AI service is forced offline, registrations are halted, or the attacker can use the same trust path to reach data and downstream tools.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Machine identity is becoming the decisive trust layer for AI operations. When agents can call tools, reach data, and trigger workflows, the model itself is only one part of the attack surface. The identity bound to that activity determines whether abuse is contained or scaled. Practitioners should assume every autonomous path needs explicit identity governance, not inherited trust.

DeepSeek is a availability event, but its lesson is governance, not uptime. DDoS creates the immediate outage, yet the deeper issue is whether AI platforms have enough identity separation to fail safely under pressure. If tokens, keys, and certificates are not scoped tightly, the same incident path can turn into privilege abuse. The control problem is broader than resilience engineering alone.

Ephemeral credential trust debt: AI programs often add temporary access paths faster than they remove them, and that creates accumulated exposure. The more agents and tools you deploy, the more hidden trust relationships you must monitor, rotate, and revoke. Teams that do not measure this debt will confuse agent velocity with security maturity.

AI security programs need blast-radius design, not just detection. Monitoring still matters, but detection after an agent or service is already over-scoped is too late for many outcomes. Least privilege, task-scoped credentials, and rollback-ready containment are what limit damage when the model or surrounding service is abused. Practitioners should build for interruption, not optimism.

The market is moving toward identity-first AI governance. As AI agents become more operational, security teams will need controls that look less like model tuning and more like IAM, PAM, and NHI governance. That shift complicates any program that treats AI security as a standalone discipline. The practical conclusion is simple: AI adoption now requires identity architecture, not just model oversight.

From our research:

• 92% of security leaders have concerns about the use of AI-generated code, according to The State of Non-Human Identity Security.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to the Ultimate Guide to NHIs.
• For a deeper operational lens, 52 NHI Breaches Analysis shows how compromised non-human credentials turn small exposures into repeatable incident patterns.

What this signals

Machine identity drift is the hidden risk in AI rollout programmes. Teams usually track model behaviour, prompt quality, and user access first, then discover too late that the real trust problem sits in the credentials behind the model. If those credentials are not tied to lifecycle controls, the AI programme inherits the same sprawl that has long affected service accounts and other NHIs.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, AI teams should assume over-permissioning is the default unless proven otherwise. That changes the implementation priority from feature enablement to identity minimisation. The programme risk is not only compromise, but also uncontrolled reach across internal and third-party systems.

Identity blast radius: the more tools an AI agent can call, the more damage a single credential failure can create. That is why AI governance should be built around revocation speed, task scoping, and monitored trust boundaries rather than broad enablement. Practitioners should be preparing for agent containment as a normal operating requirement, not a crisis-only control.

For practitioners

• Inventory AI service identities Map every certificate, API key, token, and service account used by AI models, agent wrappers, and supporting tools. Separate human-admin access from machine-only access, and document which identities can read data, call tools, or execute transactions.
• Enforce unique identities for each agent Do not let multiple agents share credentials or reuse the same privileged path. Bind each agent to a distinct identity, restrict scope to a single workflow, and require explicit approval for cross-system actions.
• Pre-stage revocation and rollback runbooks Create incident procedures that can disable outbound tool access, revoke tokens, and restore the last known safe state for AI services. Test the runbook under outage conditions so response time does not depend on improvisation.
• Apply just-in-time access to high-risk actions Use task-scoped access for AI agents when they need elevated permissions, and automatically expire those permissions when the task completes. Pair this with logging that records which identity requested the access and why.
• Align AI controls with NHI and ZTA policy Treat AI systems as non-human identities inside zero trust architecture. Require continuous verification, scope-limited permissions, and periodic review of the trust paths that connect models to internal and third-party services.

Key takeaways

• AI services need machine identity controls because the credentials behind the model are often the easiest path to abuse.
• Availability incidents in AI systems quickly become governance problems when access paths are shared, broad, or hard to revoke.
• Security teams should design AI programs for containment, unique identities, and task-scoped access before autonomy expands further.

Key terms

• Machine Identity: A machine identity is the credential set a non-human system uses to authenticate and operate, such as certificates, API keys, tokens, or service accounts. In AI environments, it governs what the model, agent, or supporting service can access, making it a primary security boundary rather than a plumbing detail.
• 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.
• Just-In-Time Access: Just-in-time access is a method of granting permissions only when a specific task requires them and removing them immediately afterward. For AI agents, it limits the window in which stolen or misused credentials can be replayed, and it reduces standing exposure across workflows.
• Identity Blast Radius: Identity blast radius is the amount of damage that can flow from a compromised non-human identity. It depends on privilege scope, how many systems the identity can reach, and whether revocation is fast enough to stop lateral movement or downstream abuse.

Deepen your knowledge

Machine identity security for AI agents is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI services with shared access paths, it is worth exploring.

This post draws on content published by CyberArk: DeepSeek DDoS, why AI needs machine identity security. Read the original.