Black Hat USA 2026 puts cloud identity and SaaS risk in focus

At a glance

What this is: Black Hat USA 2026 is being framed as a preview of cloud, SaaS, identity, and AI risks that will shape defender priorities in the next cycle.

Why it matters: It matters because IAM, PAM, NHI, and cloud security teams need to prepare for access control, visibility, and governance gaps before those issues show up as incidents.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Safetica's analysis of Black Hat USA 2026 cloud, SaaS, and identity risks

Context

Black Hat USA 2026 is being used here as a lens on the security problems that are already emerging in cloud, SaaS, identity, and AI-heavy environments. The underlying issue is not just technical exposure, but governance drift, where access, data flow, and configuration controls no longer match the pace of adoption across distributed systems.

That matters for identity teams because the article repeatedly points to human and non-human identities as the control plane for modern cloud data protection. When service accounts, API tokens, automation pipelines, and AI-enabled workflows all touch the same data, traditional perimeter thinking gives way to lifecycle control, visibility, and privilege management.

The starting position described in the article is typical for modern enterprise environments, not unusual: SaaS sprawl, fragmented data flows, over-privileged machine identities, and slow-moving control frameworks are now common patterns rather than edge cases.

Key questions

Q: What breaks when SaaS sprawl is left out of AI governance?

A: AI governance breaks when SaaS sprawl is ignored because the organisation loses visibility into where AI is embedded, which identities connect those tools, and what data those tools can touch. The result is unmanaged access, unreviewed integrations, and policy that cannot be enforced consistently across the environment.

Q: Why do non-human identities complicate data protection controls?

A: Non-human identities often have broader reach, longer lifetime, and more machine-speed reuse than human accounts. That combination increases blast radius if a token, key, or integration is over-privileged. Data protection controls must therefore consider who issued the identity, what it can access, and how far it can move data.

Q: How do security teams know whether cloud access policy is actually working?

A: They should test whether policy decisions are traceable from discovery to approval to revocation. If a team can see apps but cannot prove who owns the integration, what data it can touch, and how it is removed, then the policy is only partially working. Effective governance produces evidence, not just alerts.

Q: Who is accountable when AI search exposes sensitive enterprise data?

A: Accountability sits with the teams that approved the data connections, retrieval scope, and response handling, not just the users who queried the system. Governance should cover access design, provenance controls, and operational monitoring across identity, search, and AI platform owners.

Technical breakdown

SaaS sprawl and distributed data paths

Modern SaaS environments distribute data across applications, APIs, integrations, and automation rather than a single controlled repository. That breaks older assumptions about where data lives and who can see it. Visibility problems emerge because each platform, integration, and shadow deployment adds another policy boundary, yet the data still moves fluidly across them. In practice, defenders are trying to govern a moving graph of services instead of a perimeter. Practical implication: inventory every SaaS connection that can reach sensitive data and classify the trust relationship behind it.

Practical implication: inventory every SaaS connection that can reach sensitive data and classify the trust relationship behind it.

Identity as the control plane for cloud access

Cloud access now depends on more than human logins. Service accounts, API tokens, workload identities, and AI agents all act as non-human identities, and they often outnumber human users by a wide margin. These identities are attractive to attackers because they can carry broad, persistent permissions and operate without the same oversight used for employees. The security problem is not just authentication, but lifecycle governance, privilege scope, and the trust relationships between systems. Practical implication: treat every machine identity as a governed access entity with ownership, expiry, and revocation rules.

Practical implication: treat every machine identity as a governed access entity with ownership, expiry, and revocation rules.

AI-assisted workflows and data handling risk

AI changes cloud data protection because it introduces new processing layers inside everyday workflows. Copilots, embedded LLM features, and agentic automation do not just move data, they interpret it, summarise it, and sometimes act on it. That creates risk when data classification, prompt handling, and access delegation are not aligned. The governance problem is that legitimate AI use can expand access paths faster than security teams can review them. Practical implication: define where AI can touch sensitive data and require explicit policy for tool access, retrieval, and logging.

Practical implication: define where AI can touch sensitive data and require explicit policy for tool access, retrieval, and logging.

Threat narrative

Attacker objective: The attacker objective is to exploit distributed cloud access paths to reach sensitive data without triggering strong perimeter-style detection.

1. Entry typically begins with SaaS sprawl, exposed integrations, or a compromised non-human identity that already has access to cloud data pathways.
2. Escalation follows when over-permissioned service accounts, tokens, or automation pipelines are used to move laterally across connected applications and datasets.
3. Impact comes through data exposure, unauthorised processing, or silent policy drift that leaves sensitive information accessible across the SaaS ecosystem.

NHI Mgmt Group analysis

Cloud data protection has become an identity governance problem, not just a data visibility problem. SaaS sprawl and AI-assisted workflows make access paths dynamic, which means policy cannot stop at storage or endpoint controls. The critical question is which human and non-human identities can reach data, under what conditions, and for how long. That shifts cloud security toward lifecycle governance, ownership, and revocation discipline.

Machine identity sprawl is the named concept practitioners should track. Service accounts, API keys, tokens, and workload identities now create a parallel access fabric inside enterprise SaaS and cloud estates. The more fragmented that fabric becomes, the more likely attackers will find standing privilege, stale trust, or unmanaged delegation. Practitioners should assume that machine identity inventory is now a prerequisite for effective cloud data protection.

AI adoption widens the trust boundary faster than most governance programmes can absorb. The article correctly notes that the largest risk is often uncontrolled use of legitimate tools, not only malicious automation. That matters because AI copilots and embedded LLM features can turn ordinary access into secondary processing and disclosure paths. Teams need policy that covers data retrieval, output handling, and identity assurance, not just model approval.

Visibility gaps are now operational risk indicators, not mere tooling gaps. When organisations cannot see where sensitive data resides or which identities can reach it, they lose the ability to prove control effectiveness. That is the governance failure behind most cloud exposure stories. The practical conclusion is that cloud security programmes should measure visibility, privilege scope, and trust-chain ownership together, not as separate workstreams.

Black Hat-style research remains valuable because it surfaces how attack techniques evolve before controls do. For identity teams, that means watching for patterns that combine SaaS integration abuse, token theft, and AI-enabled data handling. The signal is clear: cloud protection programmes that ignore machine identities and delegation chains will continue to lag real attacker behaviour.

What this signals

Cloud security programmes should expect the next wave of exposure to come from the overlap between SaaS sprawl, delegated access, and machine identity governance. The practical challenge is not just discovering risk, but proving that every access path to sensitive data has an owner, a purpose, and an end state.

Machine identity sprawl: this is the point at which service accounts, tokens, and automation paths become too numerous to govern with manual review alone. When that happens, identity teams need lifecycle controls, not periodic audits, because the attack surface is defined by active trust relationships rather than directory records.

Teams preparing for Black Hat-style threat patterns should also align cloud monitoring with identity-centric controls such as least privilege, secret rotation, and connector review. The goal is to reduce the time between exposed access and containment, especially where AI tools and third-party integrations can amplify misuse.

For practitioners

• Map every SaaS and API trust chain Create a live inventory of SaaS applications, third-party integrations, automation paths, and delegated access that can touch sensitive data. Include shadow SaaS and business-owned tools so the map reflects actual usage rather than approved tooling alone. Use that inventory to identify unowned trust relationships.
• Audit machine identities for ownership and expiry Review service accounts, tokens, and workload identities for explicit owners, justification, and expiry or revocation logic. Focus on identities that can access customer data, production systems, or AI-enabled workflows. Remove standing access where the business case no longer exists.
• Govern AI access to sensitive data Define which AI tools can retrieve regulated or confidential data, what prompts or connectors are allowed, and how outputs are logged and reviewed. Treat embedded copilots as access pathways, not just productivity features, and require policy approval before broad rollout.
• Measure privilege and visibility together Track the percentage of identities with excessive privilege alongside the percentage of services and datasets with verified ownership. Pair those metrics with detection of unauthorised integrations so governance sees both who can access data and where control has broken down.

Key takeaways

• Black Hat USA 2026 is being framed around cloud, SaaS, identity, and AI risk because those domains now overlap in the enterprise attack surface.
• The most consequential governance gap is visibility into machine identities, delegated access, and data movement across fragmented SaaS environments.
• Security teams should respond by inventorying trust chains, constraining AI access, and measuring privilege and ownership together.

Key terms

• Machine Identity Sprawl: Machine identity sprawl is the uncontrolled growth of non-human identities across teams, platforms, and business processes. It becomes a governance problem when identities are created faster than they can be inventoried, reviewed, rotated, or retired, leaving security teams with incomplete visibility and weak accountability.
• Delegated Access Chain: A delegated access chain is the sequence of permissions that lets one identity act through another, such as an AI agent using a token to call a tool that reaches sensitive data. These chains are hard to see because the original grant and the final action may live in different control planes.
• Governance Coverage Drift: Governance coverage drift is the gap between the access estate an organisation believes it controls and the access estate actually present across applications and identities. It emerges when discovery is incomplete, integrations lag, or review data does not reconcile cleanly to real entitlements.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.

What's in the full article

Safetica's full article covers the operational detail this post intentionally leaves for the source:

• Conference schedule context for August training, summit, and briefing sessions that shape the research agenda.
• Examples of the cloud, SaaS, and AI threat themes the event organisers expect researchers to prioritise.
• The article's discussion of how data protection tooling fits into visibility and governance across hybrid environments.
• The business-facing rationale for why Black Hat themes matter for mid-market security programmes.

👉 Safetica's full article adds the event framing, trend breakdown, and cloud protection context behind the analysis.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It gives security practitioners a practical way to connect cloud access risk to identity controls.