Coding assistants are widening the enterprise AI governance gap

At a glance

What this is: Cyberhaven's analysis shows that the fastest-growing enterprise AI categories are also the ones with the broadest access to code, credentials, and internal architecture.

Why it matters: For IAM, NHI, and AI governance teams, the issue is not just which AI tools are approved, but which tools can touch sensitive data before policy, monitoring, and containment catch up.

By the numbers:

• Total enterprise use of endpoint-based AI native apps, including Claude, ChatGPT, and Copilot desktop, grew 509% in a single year, from February 2025 to February 2026.
• Enterprise adoption of coding assistants grew 357% year over year.

👉 Read Cyberhaven's analysis of the fastest-growing and riskiest enterprise AI categories

Context

Endpoint AI adoption is expanding faster than most security programmes can classify, monitor, and govern. The primary risk is not simple tool popularity, but the combination of rapid adoption and access to sensitive enterprise data, especially in coding assistants and desktop AI applications that operate close to source code, credentials, and internal documentation.

That matters because AI tools are now behaving like privileged intermediaries in daily workflows. In practice, they can see data that traditional IAM, DLP, and SaaS monitoring approaches were not built to govern at endpoint level. For identity teams, this creates a genuine intersection with secrets management, workload identity, and NHI governance because the same repositories and environments that hold human access also contain machine credentials and tokens.

Key questions

Q: How should security teams govern coding assistants on developer endpoints?

A: Treat coding assistants as governed non-human identities with endpoint reach, not as simple productivity tools. Define ownership, scope, telemetry, and offboarding for the assistant, its runtime account, and every tool connection it can use. Without that boundary, the agent can act with inherited privilege in ways normal developer controls do not expose.

Q: Why do AI agents create a visibility problem for IAM teams?

A: AI agents often appear outside formal onboarding through shadow AI, scripts, or workflow tools, so they never enter the normal identity inventory. Without discovery across browsers, endpoints, and automation layers, IAM teams cannot enforce policy, certify access, or prove accountability.

Q: What breaks when AI governance only covers one approved vendor?

A: Coverage becomes partial the moment users adopt another model or a desktop client on a different operating system. Detection misses exfiltration paths, policy misses local file access, and incident response lacks the evidence needed to reconstruct what happened. A single-vendor strategy is fragile in mixed fleets because actual usage fragments faster than policy enforcement.

Q: Who is accountable when an AI assistant surfaces private code from a cached repository?

A: Accountability usually spans the repository owner, the platform owner, and the team governing indexing or retrieval. The source system may be private, but the cached copy may still be live in another layer. That is why privacy incidents involving code and secrets should be handled as cross-platform access governance failures, not isolated GitHub hygiene issues.

Technical breakdown

Endpoint AI adoption and the governance gap

Endpoint AI adoption means employees are using desktop or native AI applications on their devices rather than only in browser-based interfaces. That shifts the control problem from central SaaS monitoring to the endpoint, where local files, environment variables, and repositories are directly reachable. In mixed fleets, the same workflow can generate different exposure depending on whether the user is on Mac or Windows. Governance breaks when policy assumes a single AI stack or a single visibility plane. Practical implication: security teams need endpoint-level discovery and policy enforcement that follows the actual app, OS, and data path.

Practical implication: move AI control coverage to the endpoint and tie it to data path visibility.

Why coding assistants create privileged data exposure

Coding assistants are risky because they do more than answer prompts. They can read code, traverse directories, inspect build files, and, in agentic configurations, execute commands. That means they may encounter source code, API keys, internal architecture documents, and deployment scripts in the same session. The issue is not only disclosure but context collapse, where a tool designed to assist development becomes a transient observer of secrets and internal logic. Practical implication: apply scoped controls to coding assistants before they are allowed to touch repositories with credentials or production artefacts.

Practical implication: restrict coding assistant access to repositories and paths that contain secrets or production logic.

Model diversity widens the visibility gap

The article shows that employees are not converging on one sanctioned model. They adopt whichever tool fits the task, which means monitoring tuned to one vendor or one interface misses others entirely. This is a governance problem because detection, response, and policy enforcement all depend on knowing which AI systems are actually in use. A control model built around one platform does not scale when users mix Copilot, Claude, ChatGPT, and other desktop tools across different operating systems. Practical implication: build model-agnostic discovery and logging before trying to optimise policy nuance.

Practical implication: create model-agnostic discovery and logging across all AI tools in use.

Threat narrative

Attacker objective: The attacker objective is to obtain sensitive code, secrets, and internal architecture through AI tooling that already has legitimate workspace access.

1. Entry occurs when employees adopt endpoint AI native apps or coding assistants on managed devices and connect them to live work files, repositories, and internal content.
2. Escalation happens when the tool can read source code, credentials, API keys, or deployment materials that were never intended for an AI workflow.
3. Impact follows when those high-value assets are exposed, copied, or used to shape downstream development, creating a path to data leakage and infrastructure compromise.

NHI Mgmt Group analysis

Adoption velocity is now the core AI governance variable. When AI tools grow 500% in a year, policy written around quarterly review cycles is already behind the operational reality. The issue is not whether the tool is approved in principle. It is whether governance can observe and constrain what the tool can touch before sensitive data is traversed. For identity teams, that is the same design problem seen in NHI governance when access outpaces lifecycle control. Practitioners should treat speed of adoption as a control signal, not just a usage metric.

Endpoint AI creates a new class of implicit trust in developer workflows. Coding assistants sit close to source control, build artefacts, and environment variables, which makes them structurally different from general-purpose chat tools. That proximity turns them into a data-bearing control point, not just a productivity layer. The governance question becomes whether the organisation can prove which repositories, secrets, and local paths an AI application can reach. Practitioners should align AI controls with the same scrutiny used for privileged service accounts and sensitive workload identities.

Model diversity is creating a visibility debt. A programme that watches only one sanctioned AI system will miss the majority of real behaviour once users shift between models and operating systems. Visibility trust gap: the organisation believes it has AI oversight when it really has tool-specific coverage that leaves blind spots across the rest of the fleet. This is where the intersection with IAM becomes clear: identity controls fail when access is distributed across unmanaged interfaces. Practitioners should assume the inventory is incomplete until endpoint discovery proves otherwise.

The fastest-growing AI categories will be the first to expose governance debt. The article shows that the largest growth is concentrated in tools that can reach source code, credentials, and internal architecture. That means the harm is not evenly distributed across AI use cases. Governance should prioritise the categories with the highest blast radius, even if they are not the most widely used. Practitioners should re-rank AI risk by data sensitivity and execution capability, not by adoption alone.

What this signals

Visibility trust gap: the AI governance problem is no longer only approval control, it is proving that the organisation can see every desktop model, native app, and operating system in use. That requires endpoint discovery, policy correlation, and inventory discipline across the same access surfaces that now carry secrets and source code.

For identity programmes, the lesson is direct. Endpoint AI behaves like another privileged interface into enterprise data, so the controls that matter are provenance, scope, and observability. Map those controls to the same governance thinking used for machine identities and secrets, then align them with the NIST Cybersecurity Framework 2.0.

The practical next step is to separate low-risk AI experimentation from high-blast-radius workflow access. If a tool can read repositories, local files, or environment variables, it belongs in a tighter control tier than a chat-only use case. That distinction will shape how teams design monitoring, escalation paths, and review cadence over the next programme cycle.

For practitioners

• Instrument endpoint discovery for all AI native apps Track native and desktop AI usage on managed devices, including the operating system, application name, and data paths it can reach. Pair that telemetry with DLP and identity logs so you can detect when a tool touches repositories, local files, or environment variables that should remain outside AI workflows.
• Restrict coding assistants around repositories with secrets Apply repository, path, and workload restrictions before coding assistants are permitted near files that contain API keys, deployment scripts, or internal architecture. Treat these tools as privileged intermediaries and require tighter controls for source trees that support production systems.
• Build model-agnostic AI inventory and logging Maintain discovery across Claude, ChatGPT, Copilot, and any other desktop AI tools so that monitoring does not depend on a single sanctioned interface. The control objective is complete visibility into actual usage, not coverage of the most popular model.
• Prioritise high-blast-radius AI use cases first Rank AI categories by the sensitivity of the data they can access and by whether they can execute actions or traverse file systems. Coding assistants and other endpoint-native tools should sit ahead of low-risk conversational use cases in policy, alerting, and review priority.

Key takeaways

• The central risk is not just that employees use AI tools, but that the fastest-growing tools are also the ones with the deepest access to enterprise secrets and source code.
• A 509% rise in endpoint AI and a 357% rise in coding assistants shows that governance models built on slower adoption curves will undercount exposure.
• Security teams should shift from vendor-centric approval to endpoint discovery, model-agnostic logging, and tighter controls around repositories that contain credentials or production logic.

Key terms

• Endpoint AI adoption: Endpoint AI adoption is the use of native or desktop AI applications directly on employee devices rather than only through browser or SaaS interfaces. It matters because local apps can reach files, environment variables, and repositories that cloud-only monitoring may miss.
• Coding Assistant: A coding assistant is an AI-powered software tool that helps developers read, edit, and generate code. In governance terms, it may also act as a non-human identity when it can invoke tools, reach data sources, and perform actions inside trusted workflows.
• Visibility trust gap: A visibility trust gap exists when an organisation believes it has adequate monitoring, but coverage only applies to a subset of the tools, models, or devices in use. The gap matters most when users can switch quickly between AI apps across mixed fleets.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Cyberhaven's full blog post covers the operational detail this post intentionally leaves for the source:

• Department-level AI usage breakdowns that show where engineering and sales concentration changes the control strategy.
• OS-specific usage patterns that explain why Mac and Windows fleets need different monitoring assumptions.
• Examples of how endpoint-native AI tools reach source code, credentials, and internal architecture in daily workflows.
• The article's own recommended framing for prioritising high-risk AI categories over merely popular ones.

👉 Cyberhaven's full post adds the usage breakdowns, OS split, and workflow risk detail behind the headline findings.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps practitioners connect identity governance to the broader security decisions that shape access, exposure, and auditability.