What was the common factor in the Snowflake, BeyondTrust, OmniGPT, and DeepSeek breaches?

Why This Matters for Security Teams

The shared lesson from Snowflake, BeyondTrust, OmniGPT, and DeepSeek is not that attackers needed exotic techniques, but that they found identity paths with too much trust and too little oversight. Once an NHI credential, API key, service account, or agent token is reachable, the attacker often inherits the same access the workload already had. That makes NHI governance a breach-prevention control, not a back-office hygiene task. The The 52 NHI breaches Report shows how often these failures repeat, while the Ultimate Guide to NHIs — Why NHI Security Matters Now frames why the blast radius is rising as automation expands.

For AI and agentic workloads, the risk is sharper because behaviour is not always fixed in advance. An agent can chain tools, retry actions, or move into adjacent services in ways a human reviewer might not anticipate. That is why static RBAC alone is rarely sufficient for autonomous systems. Current guidance increasingly points toward workload identity, policy evaluation at request time, and short-lived access, but there is no universal standard for this yet. In practice, many security teams encounter NHI compromise only after anomalous API use or data access has already occurred, rather than through intentional detection of the identity control failure.

How It Works in Practice

These breaches usually follow a simple pattern: the attacker obtains a secret, discovers a service account with excessive scope, or finds an API path that was assumed to be low risk. From there, the compromise becomes an identity problem, not a malware problem. The Snowflake breach, the BeyondTrust API key breach, the OmniGPT breach, and the DeepSeek breach each reinforce that once secrets or NHIs are exposed, the attacker often does not need persistence in the traditional sense.

A practical control stack for this class of risk usually includes:

• Inventory every NHI, including service accounts, API keys, bots, and agent identities.
• Replace long-lived secrets with JIT, short-lived credentials wherever possible.
• Bind machine access to workload identity, not just static tokens or shared keys.
• Evaluate authorisation at request time using context, purpose, and policy-as-code.
• Log tool use, secret access, and privilege escalation paths for each agent or workload.

This aligns with the direction of AI security guidance and with the reality described in the Anthropic — first AI-orchestrated cyber espionage campaign report, where tool access and operational chaining mattered more than a single clever exploit. It also matches NHIMG research showing that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, which leaves little time for manual response. These controls tend to break down in environments with shared service principals, hard-coded secrets in pipelines, and agent workflows that can self-select tools without real-time policy checks.

Common Variations and Edge Cases

Tighter NHI control often increases operational overhead, requiring organisations to balance faster automation against stronger containment. That tradeoff is especially visible for AI agents, where overly rigid controls can slow legitimate task completion while loose controls create a path to self-directed overreach. Best practice is evolving, but current guidance suggests that autonomous systems should not inherit broad standing access simply because they are “internal” or “trusted.”

One common edge case is the difference between a normal workload and a goal-driven agent. A fixed application may safely use a narrow role, but an agent can change tactics mid-task, invoke additional tools, or continue operating after the original intent has changed. In those environments, intent-based authorisation is more appropriate than static role mapping, even though there is no universal standard for this yet. Another edge case is secret sprawl in CI/CD, where credentials are copied into build logs, test fixtures, or training datasets. DeepSeek’s exposure of more than one million sensitive records, including credentials and API keys, shows how quickly an NHI mistake can become a data exposure event. For broader breach patterns, see the 52 NHI Breaches Analysis.

The practical takeaway is that the common factor across these breaches is not the sector, vendor, or payload. It is that NHIs were allowed to operate with more trust than their exposure justified. For teams building agentic systems, the safest default is short-lived access, workload-bound identity, and runtime policy checks rather than standing credentials and pre-approved broad roles.

Related resources from NHI Mgmt Group

• What is the most common mistake organisations make with NHI credential management?
• How do NHI breaches typically impact regulatory compliance?
• How did NHI mismanagement contribute to the Snowflake breach?
• What lessons should NHI practitioners draw from the BeyondTrust breach?