AI and data security are now the same boardroom question

At a glance

What this is: This is a board-level analysis of why AI adoption is forcing security teams to unify data visibility and access governance.

Why it matters: It matters because IAM, NHI, and AI governance teams now have to prove what humans, workloads, and agents can reach before AI is allowed to operationalise that access.

By the numbers:

• 96% of enterprise permissions granted to employees are never actually used.
• 91% of sensitive data available to workers goes untouched.
• A single user had a co-pilot tool enabled with access to over 400 million sensitive records.

👉 Read Cyera's analysis of why boards are linking AI strategy with data protection

Context

AI strategy is now a data access problem, because retrieval pipelines and agents act on what they can reach rather than what humans intended them to use. That shifts the centre of gravity from model capability to governance over permissions, data visibility, and blast radius across human identity, NHI, and emerging agentic workflows.

The gap is not that enterprises lack security controls. The gap is that many programmes still cannot answer basic questions about which data is exposed to which identity type, whether AI tools are approved, or how much dormant access can be activated the moment an AI system connects to it. For readers wanting a broader identity baseline, the Ultimate Guide to NHIs provides the grounding context for machine and workload identity governance.

Key questions

Q: How should security teams govern AI access to sensitive data sources?

A: Security teams should inventory every AI-connected identity, map the exact data sources it can reach, and validate that each connection is approved for the intended use case. The key is to govern exposure before deployment, because AI systems retrieve based on access rather than business intent. Without that mapping, dormant permissions can become immediate risk.

Q: Why do over-permissioned identities create outsized risk for AI systems?

A: Over-permissioned identities matter because AI systems can operationalise broad access instantly and at machine speed. What is dormant for a human user can become active exposure for a retrieval pipeline or agent. That makes least privilege, data classification, and entitlement scope central to AI governance, not secondary hygiene.

Q: What breaks when organisations enable copilots without data visibility?

A: What breaks is the organisation's ability to predict and defend the system's real attack surface. If teams cannot see which records, repositories, or APIs the AI can reach, they cannot set sensible boundaries, justify access, or detect overexposure. In practice, that turns AI enablement into uncontrolled delegation.

Q: Who is accountable when an AI tool exposes data it should not reach?

A: Accountability sits with the business owner of the AI use case, the identity team that granted access, and the data owner who approved the source system. If those responsibilities are unclear, the organisation has a governance gap rather than a technical one. The right answer is a named owner for every AI-connected identity.

Technical breakdown

Why retrieval pipelines turn dormant access into active exposure

Retrieval-augmented generation pipelines do not reason about entitlement intent. They query connected repositories, index what is reachable, and surface content the calling identity is allowed to see. That means dormant permissions, broad repository membership, and weak data classification become operational exposure the moment an AI system is pointed at them. The governance problem is not only who can log in. It is what the connected identity can enumerate, retrieve, and chain into a response. In practice, the control boundary moves from the model to the access layer and the data layer.

Practical implication: map AI-connected identities to the exact data sources they can query before deployment.

Shadow AI creates unreviewed access paths across human and machine identities

Shadow AI is the AI equivalent of shadow IT, but faster and harder to govern because agents, copilots, and embedded assistants can be enabled inside approved environments without a formal security review. Once active, they inherit the permissions of the user, workstation, integration, or service account that launched them. That is why visibility into AI-connected identities matters as much as visibility into the tools themselves. In identity terms, the control failure is unauthorised delegation: a seemingly normal account silently becomes the access path for a system that can move data at machine speed.

Practical implication: inventory all AI-connected identities and treat them as governed access paths, not only as applications.

Agentic AI expands the blast radius of over-permissioned access

Co-pilots answer questions, but agents act. They can query systems, call APIs, modify records, and continue operating without the pauses that normally limit human misuse. When such systems inherit broad permissions, the blast radius is determined less by the model and more by the scope of the identity behind it. This is where NHI governance and agentic AI governance converge: the same least-privilege logic applies, but the speed and continuity of execution make over-permissioned access materially more dangerous. The critical issue is not just data exposure, but autonomous action on that exposure.

Practical implication: separate read-only AI workflows from write-capable agent identities and review both against least privilege.

Threat narrative

Attacker objective: The attacker objective is to turn existing access paths into bulk data exposure by using the AI system as an amplifier for over-permissioned identities.

1. Entry occurs when a human user, co-pilot, or agent is given access to connected repositories, APIs, or datasets without tight visibility into the downstream data scope.
2. Escalation happens when the AI system inherits broad permissions and can retrieve sensitive records that were never intended to be actively used.
3. Impact follows when the system surfaces, combines, or operationalises data at machine speed, expanding exposure across records, records classes, and workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Data visibility has become the control plane for AI governance. The boardroom is no longer asking whether AI is powerful enough. It is asking whether the organisation can prove what AI systems can reach before they are switched on. That shifts security authority toward classification, entitlement mapping, and exposure analysis across human users, service accounts, and AI-connected identities. Practitioners should treat data visibility as the prerequisite for AI approval, not a post-deployment cleanup activity.

Shadow AI is a governance failure before it is a tooling problem. Unauthorised copilots and embedded assistants do not need novel exploits to create risk. They only need inherited access that no one has reviewed, which means the real failure mode is unaudited delegation. That collapses the old assumption that an application inventory is enough to understand exposure. The implication is that identity governance must extend to every AI access path, not just approved platforms.

Agentic workflows turn dormant permissions into live operational risk. Traditional access reviews assume privilege is static long enough to be observed, certified, and removed. That assumption weakens when a system can retrieve, correlate, and act continuously at machine speed. For NHI and AI governance teams, the question is no longer whether access exists, but whether the organisation understands the business meaning of every permission an agent can exercise.

AI and NHI governance are converging on the same blast-radius problem. The same over-permissioned repository, dataset, or API that is merely inconvenient for a human user can become a major exposure when consumed by a co-pilot or agent. That means IAM, NHI, PAM, and data security teams need a shared exposure model instead of separate control stories. Practitioners should evaluate AI access with the same rigour they apply to high-risk machine identities.

From our research:

• 96% of enterprise permissions granted to employees are never actually used, according to Ultimate Guide to NHIs , Key Research and Survey Results.
• 91% of sensitive data available to workers goes untouched, which means dormant access remains a massive governance surface until AI activates it.
• For the broader identity baseline, see Ultimate Guide to NHIs , Key Research and Survey Results and then reassess how AI-connected identities inherit that exposure.

What this signals

AI security programmes will increasingly be judged on exposure mapping, not model approval. The practical benchmark is no longer whether the organisation has a policy for AI use. It is whether the security team can explain which identities, datasets, and APIs any AI system can reach before production use begins. For a foundational identity baseline, teams can compare this with NIST Cybersecurity Framework 2.0 and then translate the control expectations into access visibility.

AI retrieval has exposed a new named concept: identity blast radius. In this context, identity blast radius is the amount of data, process, and downstream action a single AI-connected identity can affect once it is allowed into the environment. The larger the blast radius, the less useful generic approval workflows become. That is why visibility into AI-connected identities has to be paired with entitlement scoping and data classification.

With 96% of enterprise permissions never used, per the Ultimate Guide to NHIs , Key Research and Survey Results, the hidden risk is not only excess access. It is the tendency of AI to convert latent access into live exposure unless teams narrow the permissions first.

For practitioners

• Map AI-connected identities to reachable data sources Catalogue every co-pilot, retrieval pipeline, and agentic workflow, then record the exact datasets, indexes, APIs, and record classes each can reach. Revalidate after every connector change so exposure does not drift beyond the approved use case.
• Separate read-only from write-capable AI identities Design distinct identities and approvals for systems that only retrieve information versus systems that can update records, send messages, or trigger downstream workflows. A write-capable agent should never inherit the same standing access as a read-only assistant.
• Review dormant permissions before enabling AI access Identify privileged but unused access on the human and machine side, then remove or narrow it before AI tools are connected. The risk is not just exposure volume, but the speed at which dormant access becomes active once an AI system can query it.
• Treat shadow AI as an identity inventory problem Scan for unauthorised copilots, embedded assistants, and local AI labs that may already be operating inside the enterprise. Tie each discovery back to its launching identity, approval trail, and connected data sources so the governance gap is visible.

Key takeaways

• AI changes the governance problem from who can use data to what an AI system can reach and operationalise.
• Dormant permissions become active exposure as soon as copilots, retrieval pipelines, or agents inherit them.
• The control priority is exposure mapping first, then AI enablement, because visibility determines whether the programme can safely scale.

Key terms

• AI-connected identity: An AI-connected identity is the account, token, service principal, or credential that allows an AI system to reach data or tools. It behaves like a non-human identity because its security risk comes from what it can access and do, not from who is sitting behind a keyboard.
• Shadow AI: Shadow AI is the use of AI tools, copilots, or agents that security teams have not discovered, approved, or governed. The risk is not just unapproved software. It is unreviewed access paths that can inherit human or machine permissions and move data without proper oversight.
• Identity blast radius: Identity blast radius is the total scope of data, systems, and actions that a single identity can affect once access is granted. In AI environments, it often expands quickly because retrieval and agentic workflows can operationalise broad permissions at machine speed.
• Retrieval pipeline: A retrieval pipeline is the process an AI system uses to query connected data sources, select relevant content, and feed that content into a model response. The security issue is that the pipeline acts on access, so broad entitlements become visible exposure when the system runs.

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 governance maturity, it is worth exploring.

This post draws on content published by Cyera: Why Boards Are Asking About AI and Data in the Same Breath. Read the original.