Copilot exposure shows why data and identity controls must converge

At a glance

What this is: This is a webinar about converging DSPM and ITDR to reduce identity and data risk as AI tools expand access paths.

Why it matters: It matters because IAM, NHI, and data governance teams need a single view of who and what can reach sensitive data before AI-driven oversharing becomes an incident.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Register for Netwrix's webinar on converging DSPM and ITDR for Copilot risk

Context

AI productivity tools do not create identity risk from nothing. They magnify the access model already in place, which means over-permissioned accounts, weak data classification, and scattered secrets become more dangerous once a tool can surface or move sensitive information at speed. For IAM and security teams, the question is not whether Copilot introduces a new class of issue, but whether current governance can still explain who has access to what and why.

DSPM and ITDR are usually bought as separate disciplines, but the article’s core point is that they increasingly converge in practice. Data exposure often begins with identity exposure, especially where hybrid environments, shadow data, and excessive sharing meet AI-assisted workflows. That makes the operational problem less about point tools and more about whether the programme can enforce least privilege across both data and identity paths.

For teams already dealing with service account sprawl, third-party access, and stale entitlements, this is a familiar pattern rather than an edge case. The article frames Copilot as an amplifier of pre-existing weaknesses, and that is the right lens for most enterprises.

Key questions

Q: How should security teams govern AI assistants that can access sensitive business data?

A: Security teams should treat AI assistants as access amplifiers, not as a separate control domain. Start by limiting the identities, groups, and repositories they can reach, then confirm that sensitive data is classified and owned. The goal is to make AI output dependent on justified access, not on inherited broad entitlements.

Q: Why do AI tools increase the risk created by over-permissioned identities?

A: AI tools increase risk because they make existing access easier to use, search, and share at scale. If a user or workload already has broad entitlements, the tool can surface more sensitive material faster and across more contexts. The real problem is permission excess, not the assistant itself.

Q: What breaks when data security and identity security are managed separately?

A: What breaks is the ability to explain actual exposure. Data teams may know what is sensitive but not who can reach it, while identity teams may know who has access but not which permissions matter most. That split makes prioritisation weak and response slower in hybrid environments.

Q: Who should be accountable when AI-assisted access leads to data leakage?

A: Accountability should sit with the programme that owns access governance across identity and data, not with the AI tool alone. If the leakage came from excessive entitlements, stale sharing, or poor classification, the failure is in governance. The responsible teams are usually IAM, data security, and the business owner together.

Background and context

DSPM and ITDR in the same control plane

DSPM, or data security posture management, discovers and classifies sensitive data across cloud, SaaS, endpoints, and file stores. ITDR, identity threat detection and response, watches for risky identity behaviour such as anomalous sign-ins, privilege misuse, and suspicious access paths. When combined, they create a fuller picture of exposure: which identities can reach which data, where that access is overbroad, and whether the access pattern looks normal. The key technical value is correlation, not duplication. A sensitive dataset without identity context can look safe while being broadly reachable. An identity event without data context can look benign while touching regulated data.

Practical implication: unify exposure and identity telemetry so the team can prioritise the accounts that matter most to sensitive data.

AI tools and permission amplification

AI assistants can surface data that users already have access to, which means they rarely invent a new permission problem. Instead, they accelerate a pre-existing one by making broad entitlements more usable and more visible to the operator. If an account can search, summarise, or retrieve content across large repositories, then the real control issue is whether those permissions were ever justified. That is why AI-assisted access should be reviewed as an entitlement problem first and a feature problem second. In practice, the risk grows fastest where data classification is weak, sharing is informal, and identity hygiene has not kept pace with workforce or machine access.

Practical implication: review broad read access and shared repositories before enabling AI assistants against them.

Why unclassified data becomes shadow exposure

Shadow data is information the organisation stores, shares, or replicates without clear ownership, classification, or governance. It often accumulates in collaboration tools, exports, backups, and ad hoc integrations. Once AI tools can index or retrieve that material, shadow data stops being an abstract hygiene issue and becomes an exposure path. This is especially relevant in hybrid environments where access is distributed across SaaS, on-premises systems, and connected accounts. The technical challenge is not only finding the data, but proving which identity paths can reach it and whether that reach still matches policy.

Practical implication: map unclassified data to the identities that can access it, then remove the broadest paths first.

NHI Mgmt Group analysis

Copilot-style data exposure is really a governance acceleration problem: the tool does not invent weak permissions, but it makes weak permissions operationally expensive much faster. In practical terms, existing IAM and data controls now have to answer the same question at machine speed that they previously answered at human speed: who can reach what, and should that still be true. The implication is that access governance and data posture can no longer be run as separate programmes.

Identity hygiene is the hidden dependency behind AI-assisted data risk: if service accounts, shared accounts, or overbroad user entitlements already reach sensitive repositories, an AI layer simply increases the probability of misuse, oversharing, or accidental disclosure. That is why this topic belongs in the same control conversation as NHI governance, lifecycle review, and privileged access oversight. Practitioners should treat AI data exposure as a symptom of identity sprawl, not a standalone AI problem.

DSPM and ITDR together create a more defensible exposure model: data controls tell you what is sensitive, while identity controls tell you who or what can touch it. Neither view is sufficient alone in hybrid environments, especially where SaaS, cloud workloads, and user assistants intersect. The practitioner takeaway is to govern exposure by access path, not by tool category.

Shadow data and shadow identity reinforce each other: undiscovered datasets are often reachable through equally undiscovered accounts, tokens, or service identities. That pairing creates an identity blast radius that standard access reviews miss because the data owner and the identity owner are not looking at the same evidence. The implication is that programmes need joint ownership across IAM, data security, and cloud operations.

Runtime visibility is becoming the real control boundary: once AI tools can query or move data on demand, static policy statements are no longer enough to describe actual exposure. Continuous observation of entitlements, data classification, and anomalous access becomes the deciding factor. Practitioners should assume that yesterday’s access model is already stale when AI is involved.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• For a broader control model, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline.

What this signals

Shadow access and shadow data will converge faster than most programmes expect: as AI tools sit on top of existing permissions, the organisations that cannot see both identity scope and data classification will struggle to bound exposure. The practical signal is clear: if IAM and DSPM are not jointly owned, AI rollouts will expose governance gaps rather than create them. For a control baseline, align the programme with the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs.

With 79% of organisations having experienced secrets leaks and 77% of those incidents causing tangible damage, the governance gap is already operational, not theoretical. Teams should expect more pressure on classification, entitlement review, and response workflows as AI assistants make broad access easier to exploit or disclose. The signal is not to slow AI adoption, but to make access evidence visible before expansion.

Identity blast radius: this is the amount of sensitive data an identity can expose when its permissions are broader than its business need. That concept will matter more as AI assistants, service accounts, and human users increasingly touch the same repositories. Practitioners should shrink blast radius first, then allow AI workflows to scale only where access is provably justified.

For practitioners

• Unify identity and data exposure review Create a shared review path for IAM and DSPM so teams assess sensitive datasets alongside the identities and workloads that can reach them. Start with high-value repositories in cloud and SaaS, then map privileged users, shared accounts, and service identities to each location.
• Reassess AI-enabled access against least privilege Before enabling tools such as Copilot on business repositories, verify that access is already tightly scoped and that broad read permissions are not acting as an invisible escalation path. Prioritise files, sites, and folders with weak ownership or incomplete classification.
• Reduce shadow data exposure Identify data stored outside formal governance paths, including exports, collaboration spaces, and unmanaged repositories, then assign ownership and classification. The goal is to remove reachable sensitive content that AI tools can index or summarise without a clear business need.
• Correlate identity anomalies with sensitive-data access Tune detection so identity alerts are evaluated against the sensitivity of the data being touched, not only the account behaviour itself. That correlation helps the team separate routine activity from access to regulated or high-impact information.

Key takeaways

• AI assistants do not create access risk in isolation. They expose and accelerate the permission gaps already present in IAM and data governance.
• When identity visibility and data classification are weak, hybrid environments make it harder to prove who can reach sensitive information and why.
• The practical response is joint ownership of access, classification, and response so AI-enabled workflows inherit tighter controls rather than broader exposure.

Key terms

• Data Security Posture Management: Data Security Posture Management is the discipline of discovering, classifying, and protecting sensitive data across systems and repositories. It focuses on where data lives, how it is exposed, and whether access and handling controls match its sensitivity in cloud, SaaS, and on-premises environments.
• Identity Threat Detection and Response: Identity Threat Detection and Response is the monitoring and response layer that looks for suspicious identity behaviour, misuse of privileges, and abnormal access patterns. It helps teams detect when an account, token, or workload is acting outside expected boundaries and supports fast containment.
• Shadow Data: Shadow data is sensitive or business-critical information stored, copied, or shared outside formal governance processes. It often appears in collaboration tools, exports, and unmanaged repositories, creating exposure because ownership, classification, and access oversight are incomplete or missing.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, or functions an identity can affect when its access is broader than necessary. The larger the blast radius, the more damaging any misuse, error, or compromise becomes, especially when AI tools or service identities can act quickly across many repositories.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Netwrix: Netwrix 1Secure PRO webinar on data and identity risk visibility. Read the original.