Topic starter
07/06/2026 9:16 pm
TL;DR: AI adoption is outpacing AI security and governance, with IBM reporting that 97% of businesses suffering an AI-related breach had no proper AI access controls in place, while Cyera argues that extending DSPM into AI workflows is the practical way to restore visibility over data, access, and usage. The underlying issue is not just data sprawl, but governance built for static environments now being asked to control dynamic AI workflows.
Editorial analysis by NHI Mgmt Group, based on content published by Cyera: “Navigating the World of DSPM for AI and Why It is Mission Critical for Enterprise Organizations”.
By the numbers:
- 97% of businesses that suffered an AI-related breach reported they had no proper AI access controls in place.
- 72% of data breaches involved data stored in cloud environments.
- 30% of breached data spanned multiple computing environments.
Key questions
Q: What breaks when data access governance is too static for AI-driven workflows?
A: Static governance breaks when access decisions assume the data path is predictable, because AI-enabled workflows can reuse or expand entitlements faster than review cycles can track.
Q: Why do shadow AI tools create such a compliance problem?
A: Shadow AI creates a compliance problem because it bypasses the visibility controls that ISO 42001 depends on.
Q: How should teams decide whether DSPM is enough for AI governance?
A: DSPM is enough only if it can see the organisation’s real AI footprint, including training data, inference flows, third-party tools, and shadow AI usage.
Practitioner guidance
- Map AI workflows to data ownership and purpose Document where sensitive data enters training, inference, prompt, and output paths, and assign accountable owners for each workflow stage.
- Extend discovery into shadow AI channels Inventory sanctioned and unsanctioned AI tools, browser-based use, and third-party integrations so hidden data paths do not escape monitoring.
- Enforce least-privilege access for AI datasets Review dataset entitlements, model training inputs, and AI operator permissions to remove access that is broader than the declared task requires.
Bottom line: AI security failures often show up first as data-governance failures, because static controls do not map cleanly to dynamic model and prompt workflows.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 9:09 am
DSPM for AI is really about governance continuity, not just better discovery. The article’s core lesson is that AI changes the shape of the data security problem, but not the governance duty behind it. Discovery, classification, access visibility, and compliance reporting have to follow the data into training and inference paths, otherwise the control plane stops where AI begins. Practitioners should read DSPM for AI as a governance extension, not a separate security category.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- One in five organisations reported a breach due to shadow AI, and 97% of those breached through an AI model or application lacked proper AI access controls, according to IBM's 2025 Cost of a Data Breach Report.
A question worth separating out:
Q: What should security teams do when AI agents need access to tools and data?
A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities. Limit tool scope, define approval gates, and require explicit revocation triggers for sessions and delegated access. The goal is to prevent broad runtime behaviour from inheriting static privileges.
👉 Read our full editorial: DSPM for AI exposes the governance gap in enterprise data security
This post was modified 3 days ago by NHI Mgmt Group