Completing CNAPP with DSPM closes the cloud data visibility gap

At a glance

What this is: This report argues that CNAPP is incomplete without DSPM because cloud security teams need data visibility, not just posture and workload coverage.

Why it matters: For IAM, cloud security, and NHI practitioners, the gap matters because exposed secrets, service accounts, and AI API keys turn data visibility into an access-control problem as much as a detection problem.

By the numbers:

• AI-specific secrets grew by roughly 140% year over year, turning shadow AI into a primary cloud exposure point.

👉 Read SentinelOne's report on completing CNAPP with DSPM

Context

Cloud security programmes often fail when they can see infrastructure state but not the data and credentials that attackers actually target. CNAPP covers misconfiguration, workload risk, and runtime protection, while DSPM adds visibility into where sensitive data lives and how it is exposed, which is why the intersection matters for NHI, secrets, and AI API key governance.

The primary governance gap is not simply detection. It is the lack of a unified picture that links sensitive data, identity material, and exploit paths across cloud environments, AI tooling, and workloads. In practice, that means teams may know a workload is exposed but not whether the exposed asset includes secrets, tokens, or data that can be used for lateral movement.

Key questions

Q: What breaks when CNAPP is deployed without DSPM?

A: CNAPP without DSPM can show misconfigurations and workload risk, but it leaves security teams blind to where sensitive data and usable credentials actually sit. That gap matters because attackers target what they can reach, not what is merely misconfigured. Without data discovery tied to identity context, teams can miss the access path that turns exposure into compromise.

Q: Why do AI-specific secrets create new governance risk in cloud environments?

A: AI-specific secrets behave like non-human identities because they authenticate software, not people, yet they are often managed as ordinary configuration. That creates governance gaps in ownership, rotation, and revocation. If those credentials are exposed or poorly scoped, they can become direct routes into cloud services, automation pipelines, and sensitive data.

Q: How do security teams know if exploit path analysis is working?

A: Exploit path analysis is working when teams can identify which exposed secrets or vulnerabilities actually lead to production access, then remove those paths first. The useful signal is not the size of the finding set, but whether remediation is reducing reachable attack chains into critical workloads and data.

Q: How should organisations govern shadow AI access to cloud data?

A: Organisations should classify shadow AI tools as access-bearing systems and require the same lifecycle controls used for other non-human identities. That means explicit ownership, approved secret storage, periodic rotation, and revocation when a tool is no longer in use. If the access path is unmanaged, the data exposure is unmanaged too.

Technical breakdown

Why CNAPP leaves a data visibility gap without DSPM

CNAPP brings together cloud posture, workload protection, and runtime controls, but it does not automatically tell teams where sensitive data sits or which identities can reach it. DSPM fills that gap by discovering sensitive data at rest, mapping exposure, and showing how that data intersects with cloud accounts, storage, and applications. The technical issue is correlation. Without data discovery tied to identity and access context, defenders can miss the path from exposed secret to reachable workload. Practical implication: treat data visibility as a control plane, not a reporting layer.

Practical implication: connect data discovery to entitlement and workload inventories so exposed data can be acted on, not just reported.

How exposed secrets become verified exploit paths

Attackers do not need a full compromise to create damage if they can find usable secrets, API keys, or tokens in cloud-connected systems. Once a secret is exposed, it can be tested quickly against cloud services, AI APIs, or automation pipelines, and any working credential creates an exploit path into higher-value workloads. Verified exploit path analysis matters because it shows not only where secrets exist, but which paths are actually exploitable. Practical implication: prioritise secrets and identities that connect directly to production workloads, not just those flagged as weak.

Practical implication: rank remediation by exploitability and workload reach, not by the number of findings alone.

Why AI-specific secrets change cloud governance

AI-specific secrets include API keys, service credentials, and tokens used by AI tools, agents, and pipelines. These assets behave like non-human identities because they authenticate software rather than people, yet they are often governed by cloud teams as generic configuration items. That creates a lifecycle problem: creation, storage, delegation, rotation, and revocation all need identity-style controls. The report's reference to shadow AI is a warning that unmanaged AI tooling can become a new exposure layer. Practical implication: classify AI secrets as identity assets and govern them with the same discipline used for NHIs.

Practical implication: put AI secrets under explicit ownership, rotation, and offboarding processes instead of leaving them inside ad hoc application workflows.

Threat narrative

Attacker objective: The attacker objective is to turn a single exposed secret or token into authenticated access to valuable cloud workloads and sensitive data.

1. Entry occurs when AI API keys, cloud secrets, or other exposed credentials are discovered in cloud-connected systems or shadow AI workflows.
2. Escalation follows when the exposed secret is validated against cloud services and gives access to storage, compute, or automation pipelines.
3. Impact occurs when attackers use that access to reach critical workloads, sensitive data, or higher-privilege cloud operations.

NHI Mgmt Group analysis

DSPM is the missing data plane in modern cloud governance. CNAPP can expose misconfigurations and workload risk, but that is not the same as knowing where sensitive data, secrets, and AI credentials actually live. Without DSPM, security teams are governing infrastructure visibility while attackers are targeting the data path. The practical conclusion is straightforward: cloud control must follow the asset that creates the breach potential, not just the asset that hosts it.

AI-specific secrets are becoming a cloud identity problem, not only a data problem. When API keys and tokens authenticate AI tools, they function as non-human identities with their own lifecycle, access scope, and revocation risk. That means cloud teams and identity teams have to share ownership of the same control surface. The stronger governance model is to treat AI credentials as first-class identities, not incidental configuration.

Verified exploit paths are more useful than raw vulnerability counts. Attackers do not monetise every weakness, only the ones that connect to usable access. A report that shows which secrets and exposures lead to critical workloads helps teams separate theoretical risk from operational risk. The practitioner takeaway is to prioritise the chain that reaches production, because that is where compromise becomes impact.

Cloud exposure management is moving toward identity-informed data security. The market signal here is that posture, workload, and data controls are converging around the same question: what can an attacker actually authenticate to, reach, and exfiltrate? That convergence will force IAM, NHI, and cloud security programmes to share more telemetry and ownership. Practitioners should expect governance models that cannot correlate data exposure with identity reach to age poorly.

Shadow AI creates governance debt faster than traditional cloud sprawl. AI tools introduce new secrets, new integrations, and new delegation chains before most organisations have a policy model for them. That is why unmanaged AI adoption belongs in the same risk conversation as unmanaged NHIs. Teams that do not extend identity governance to AI workflows will keep discovering access paths after attackers do.

What this signals

AI-specific secrets are becoming a governance class of their own. Once those credentials sit inside pipelines, copilots, and automation hooks, the practical unit of control is no longer the application alone but the identity that lets software act. Teams should expect the same pressure that service accounts created for cloud automation already placed on IAM and PAM, with more volume and less visibility.

Data-centric cloud security will increasingly depend on identity correlation. If a team cannot tie sensitive data to the identities and tokens that can reach it, then posture tools will keep producing partial answers. The governance model is moving toward correlation across DSPM, CNAPP, and IAM, with exposure measured by reachable paths rather than isolated misconfigurations.

The post-shadow AI problem is not discovery alone but offboarding and revocation. When AI tools are removed or replaced, any associated secrets, service accounts, or delegated tokens need the same lifecycle treatment as human access. That is where identity governance becomes the difference between a short-lived exposure and a persistent breach window.

For practitioners

• Map sensitive data to reachable identities Correlate DSPM findings with IAM, service account, and workload inventories so every sensitive dataset is tied to the identities that can touch it. Focus on storage, pipelines, and AI integrations where a single credential can create broad access.
• Treat AI API keys as governed identities Assign explicit owners, rotation intervals, and revocation paths for AI-specific secrets used by tools, agents, and automation. Do not leave them embedded in developer workflows or shared configuration stores.
• Prioritise exploit paths over generic findings Rank remediation by whether an exposed secret or unpatched system reaches production workloads, not by severity labels alone. Verified exploit path analysis should drive sequencing because it reflects what an attacker can actually do.
• Unify cloud and identity telemetry Bring IAM, CNAPP, and DSPM signals into a single triage workflow so responders can see whether exposure is a configuration issue, a credential issue, or both. That reduces the chance of fixing surface symptoms while leaving the access path intact.
• Extend offboarding to machine and AI credentials When apps, workflows, or AI tools are retired, revoke their secrets, tokens, and service accounts as part of the same closure process. Offboarding that stops at the application layer leaves hidden access behind.

Key takeaways

• CNAPP without DSPM leaves a blind spot where sensitive data, secrets, and reachable identities intersect.
• AI-specific secrets are rising fast enough to behave like a distinct non-human identity risk class.
• Practitioners should prioritise verified exploit paths, not just raw findings, because attacker value sits in the path to critical workloads.

Key terms

• Data Security Posture Management: DSPM is the practice of discovering where sensitive data lives, how it is exposed, and which systems can reach it. In cloud environments, it turns data visibility into an operational control by connecting storage, access paths, and governance obligations.
• Verified Exploit Path: A verified exploit path is a demonstrable route from exposure to meaningful compromise, such as a secret that actually grants access to a workload or dataset. It is more actionable than a raw vulnerability count because it reflects what an attacker can truly use.
• AI-Specific Secret: An AI-specific secret is a credential, token, or API key used by AI tools, agents, or pipelines to authenticate to services and data sources. These secrets behave like non-human identities and need explicit ownership, rotation, and revocation controls.
• Shadow AI: Shadow AI refers to AI tools, agents, or automations operating without formal oversight or inventory coverage. In governance terms, it creates hidden credential, data, and delegation paths that can bypass normal review and remain active after the tool is forgotten.

What's in the full report

SentinelOne's full report covers the operational detail this post intentionally leaves for the source:

• How CNAPP and DSPM are combined in practice to close data visibility gaps across cloud environments
• The verified exploit path approach used to connect exposed AI keys, cloud secrets, and unpatched vulnerabilities
• The report's deeper treatment of shadow AI as a cloud exposure source and how it changes remediation priority
• The specific data visibility and compliance assurance angles practitioners can use in implementation planning

👉 SentinelOne's full report covers the cloud data visibility gap, verified exploit paths, and AI-specific secret exposure in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It is designed for practitioners who need to translate identity discipline into operational control across cloud and AI-adjacent environments.