DSPM in 2026: Why shadow data and AI raise the stakes

At a glance

What this is: This is an analysis of why DSPM is becoming a baseline data security control as shadow data, AI systems, and fragmented tooling expand the attack surface.

Why it matters: It matters because identity and access teams now have to govern sensitive data access across human users, service accounts, and AI systems, not just storage locations.

By the numbers:

• The 2026 GigaOm DSPM Radar evaluated 25 vendors across technical capabilities, emerging features, and business criteria.
• Data breaches involving multiple environments cost an average of $5.05 million.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.

👉 Read Securiti's analysis of why DSPM matters more than ever in 2026

Context

DSPM has moved from a niche discovery category to a governance requirement because data now spreads across cloud repositories, SaaS platforms, on-premises stores, and AI pipelines faster than manual control processes can follow. The first problem is visibility: if teams cannot reliably see where sensitive data lives and who can reach it, they cannot enforce access policy, prove compliance, or contain blast radius when something goes wrong.

The article’s core point is that AI adoption makes this visibility problem worse, not better, because models, copilots, and AI agents ingest data in ways that often bypass the assumptions built into older data security programmes. That creates a genuine identity intersection: human access governance, service account controls, and AI agent permissions all now influence data exposure.

The article’s starting position is typical of modern enterprise environments, not an outlier, because shadow data and fragmented data estates are now common operating conditions rather than edge cases.

Key questions

Q: How should security teams govern sensitive data used by AI systems?

A: Security teams should treat AI as a data consumer that needs policy boundaries, not just authentication. Classify sensitive data, define which datasets may enter AI workflows, and monitor outputs, logs, and downstream reuse. If governance stops at login, the organisation can approve access while still losing control of the data itself.

Q: Why do shadow data repositories create so much security risk?

A: Shadow repositories create risk because they are often outside ownership, review, and access governance. Teams may not know the data exists, who can reach it, or whether the repository is still needed. Once that happens, classification, retention, and access controls all become unreliable, which expands the chance of leakage and compliance failure.

Q: What breaks when data security tools are split across cloud and SaaS environments?

A: When tools are split, security teams lose a connected view of data sensitivity, identity access, and policy enforcement. That leads to duplicated controls, inconsistent remediation, and weak breach investigations because the analyst cannot reconstruct the path from identity to data. A fragmented stack may still find assets, but it cannot govern them as one estate.

Q: How do organisations know whether DSPM is actually improving control?

A: They should look for fewer unmanaged repositories, faster classification of newly created stores, and better linkage between sensitive data and the identities that can access it. If analysts can answer who, what, and where without manual correlation across multiple tools, the control is working. If not, visibility is still fragmented.

Technical breakdown

Shadow data discovery and why abandoned repositories persist

Shadow data is data assets that exist outside formal governance, often because project teams create cloud repositories quickly and then leave them behind. In practice, the problem is not only discovery but lifecycle control: if repositories are created on demand without asset ownership, classification, or offboarding, they become invisible control gaps. DSPM tools try to map these assets back to business context so security teams can tell whether a repository is live, who can access it, and whether the contents are sensitive. Without that relationship view, teams treat data like isolated files instead of governed assets.

Practical implication: tie repository discovery to ownership, classification, and offboarding so abandoned stores do not remain outside policy.

How AI pipelines change data access governance

AI systems do not just consume data, they reshape who and what can access it. Large language models, copilots, and AI agents often ingest enterprise data through service connections, retrieval layers, and workflow automations that are not covered by traditional user-centric access review. That creates a new governance layer where the key questions are whether data was classified before ingestion, whether the AI system is authorised to see it, and whether the downstream use stays within intended scope. This is where identity and data governance meet: permissions granted to agents, pipelines, and supporting services can leak sensitive data even when human access looks correct.

Practical implication: govern AI data access as a distinct entitlement path, not as a by-product of user permissions.

Why siloed tools fail in multi-environment data estates

Point solutions tend to optimise for one environment, such as a single cloud, a data warehouse, or a specific compliance use case. The result is fragmented visibility, duplicated policy logic, and inconsistent remediation across estates that now span on-premises, SaaS, cloud, and AI workflows. A relationship graph approach tries to solve this by linking data, identities, policies, and systems in one context layer, which is more useful for breach impact analysis than a list of disconnected assets. The technical issue is not simply scale, but context loss across environments.

Practical implication: consolidate policy context across environments so remediation decisions are based on connected risk, not isolated alerts.

Threat narrative

Attacker objective: The attacker or risk event seeks to reach sensitive data through poorly governed storage and AI access paths, then exploit that exposure for theft, extortion, or downstream manipulation.

1. Entry begins with shadow repositories, SaaS stores, or AI-connected datasets being created faster than governance can classify them.
2. Escalation occurs when human, service, or AI identities inherit access paths that were never reviewed against the sensitivity of the data they can reach.
3. Impact follows through data leakage, regulatory exposure, or poisoned AI outputs when sensitive data is ingested, shared, or analysed outside intended boundaries.

NHI Mgmt Group analysis

Shadow data is now an access-control problem, not just a discovery problem. Once abandoned repositories fall outside ownership and review, they become unmanaged entitlement surfaces. DSPM only matters when it links inventory to who can actually reach the data, which is why identity context must sit beside data discovery. Practitioners should treat orphaned repositories as governance defects, not storage hygiene issues.

AI has turned data governance into a runtime control issue. Copilots and agents can ingest, transform, and re-expose sensitive data in seconds, which means static classification alone is no longer enough. The governance gap is not whether data was labeled at rest, but whether the permissions attached to the consuming system were valid at the moment of access. Practitioners need runtime policy around AI data use.

Platform-level context is becoming the new baseline for breach investigation. The named concept here is data identity graph fragmentation, where identities, policies, repositories, and AI systems are tracked separately and security teams lose the ability to reconstruct exposure paths. That fragmentation weakens investigation, access review, and compliance evidence at the same time. Practitioners should favour control architectures that preserve relationships across the full data estate.

DSPM is converging with IAM, PAM, and AI governance whether teams plan for it or not. The article reflects a broader market shift toward unified policy views that connect data sensitivity to identity privilege and machine access. That does not replace IAM or PAM, but it does expose where those controls stop short of governing data use inside AI and multi-cloud workflows. Practitioners should align data security and identity governance roadmaps rather than run them as separate programmes.

What this signals

Shadow data and AI access are converging into the same governance problem: control what can be discovered, what can be reached, and what can be re-exposed. The useful operating model is not more inventory for its own sake, but a connected entitlement view that ties repositories to identities and policy outcomes.

Data identity graph fragmentation: when data, identity, and policy are tracked in separate systems, the organisation loses the ability to explain exposure paths quickly. That matters for breach response, privacy obligations, and AI oversight because the evidence chain is only as strong as the weakest context link.

Teams should expect DSPM to pull closer to IAM, PAM, and AI governance planning over the next cycle. The immediate signal is whether your programme can answer not just where sensitive data lives, but which human, workload, or AI identity can reach it without relying on manual joins.

For practitioners

• Map abandoned data stores to accountable owners Inventory cloud, SaaS, and on-premises repositories that were created for short-term projects, then assign ownership, classification, and review cadence before they age into shadow data. Include a clear offboarding step for every temporary repository so the estate does not accumulate invisible exposure.
• Treat AI data access as a governed entitlement path Review the service connections, retrieval layers, and agent permissions that allow copilots or AI workflows to reach sensitive data. Apply least privilege to the consuming system, not just the human user, and validate that access remains within intended scope after deployment.
• Build relationship-based breach impact analysis Connect data, identities, policies, and systems into a single context model so analysts can see which identities reached which repositories and through what path. That shortens investigation time and makes exposure assessment more defensible across hybrid estates.
• Consolidate policy decisions across environments Reduce duplicate controls by aligning data discovery, classification, and enforcement across SaaS, cloud, and on-premises platforms. Use one policy source for high-value datasets so exceptions do not drift between teams and tools.

Key takeaways

• DSPM is becoming a baseline control because shadow data and AI workflows now create governance gaps faster than manual processes can close them.
• The real exposure is not just data discovery, but whether identities, agents, and services can reach sensitive data outside intended scope.
• Programmes that connect data, identity, and policy in one context layer will investigate faster and reduce leakage risk more effectively.

Key terms

• Shadow Data: Shadow data is sensitive information that exists outside the places security teams expect to find it. It often appears in testing copies, ad hoc exports, SaaS tools, or AI workflows, which makes it hard to govern with inventory-based controls alone.
• Data Security Posture Management: Data Security Posture Management, or DSPM, is the continuous discovery and monitoring of where sensitive data lives, how it is exposed, and where policy gaps exist. Its value rises when it feeds remediation rather than generating findings alone, especially in environments where AI expands the number of data paths.
• Data Identity Graph: A contextual model that links data assets, identities, policies, and systems so security teams can understand exposure in relationship, not isolation. It is especially useful when investigations need to show which identity accessed which dataset through which path.
• AI Data Governance: AI data governance is the set of rules, ownership decisions, and enforcement mechanisms that determine how data can be used by AI systems. It covers classification, access control, retention, and remediation, and it must account for both human users and autonomous software entities.

What's in the full article

Securiti's full post covers the operational detail this analysis intentionally leaves for the source:

• Vendor-specific explanation of the Data Command Graph and how it is used to correlate data, identities, policies, and AI systems.
• Evaluation context from the 2026 GigaOm DSPM Radar, including the criteria behind the platform and innovation placement.
• Product-level discussion of AI tuning, AI asset discovery, and undo capabilities for restoring files after AI-related mistakes.
• Examples of how the vendor positions consolidated governance across privacy, compliance, and AI security workflows.

👉 The full Securiti post covers the radar placement, platform context, and data-and-AI trust narrative 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, and secrets management. It helps practitioners connect identity controls to the broader security programme that now has to govern AI and data access together.