TL;DR: Enterprise endpoint AI use grew 509% year over year, while coding assistants rose 357% and Claude 5,680%, according to Cyberhaven Labs data on hundreds of thousands of employees. The finding shows that adoption velocity, not tool popularity, is now the governance variable that determines exposure.
At a glance
What this is: Cyberhaven's data shows that the fastest-growing enterprise AI tools are also the ones with the widest access to sensitive engineering and business data.
Why it matters: IAM and security teams need to govern endpoint AI and coding assistants by access scope and device context, because growth is outpacing policy coverage across mixed fleets.
By the numbers:
- Total enterprise use of endpoint-based AI native apps grew 509% in a single year, from February 2025 to February 2026.
- Enterprise adoption of coding assistants grew 357% year over year.
- Engineering accounts for 33% of all AI native app usage across the enterprises in the Cyberhaven dataset.
Context
Enterprise AI governance now fails when control scope is built around popularity rather than access. Endpoint AI tools can read local files, reach environment variables, and operate inside developer workflows, which means the real risk sits where adoption speed meets sensitive data exposure. Cyberhaven's data makes that mismatch visible across mixed Mac and Windows estates.
Coding assistants are a particularly sharp version of that problem because they combine local context, repository access, and in some cases command execution. That creates a governance boundary issue for IAM, PAM, and NHI programmes: policy written for browser chat tools does not govern endpoint-native AI that can touch code, credentials, and infrastructure artefacts. The pattern is typical of fast-moving enterprise AI adoption, not an edge case.
Key questions
Q: What breaks when coding assistants are allowed broad endpoint access?
A: Broad endpoint access breaks the assumption that AI tools are only reading prompts. Once a coding assistant can reach source code, environment variables, and local files, it can expose secrets, internal architecture, and build logic. The control failure is not the model itself, but unbounded device-level reach.
Q: Why do fast-growing endpoint AI tools create governance risk even when approved?
A: Approval does not solve governance if usage expands faster than policy coverage. Fast-growing endpoint AI tools change where data is accessed and how it moves, so teams can miss exfiltration paths, unreviewed permissions, and unsupported workflows even when a tool is formally sanctioned.
Q: What are the signs that AI governance is failing in a mixed Windows and Mac estate?
A: The clearest signs are uneven visibility, tool-specific blind spots, and policies that only cover one dominant platform. If AI monitoring works on one operating system but not the other, or only sees one vendor's app, the governance model is incomplete.
Q: How should security teams govern AI-assisted data movement across endpoints?
A: Security teams should govern AI-assisted data movement by starting at the endpoint, where content is opened, copied, transformed, and redistributed. They need lineage-aware policy that tracks how information moves across applications and identities, including non-human actors. Without that sequence, teams can neither distinguish normal use from risky propagation nor enforce controls before exposure spreads.
Technical breakdown
Why endpoint AI expands the attack surface so quickly
Endpoint AI native apps sit on the device, not just in a browser. That matters because local applications can interact with files, environment variables, development tools, and internal repositories in ways cloud-only services usually cannot. When usage grows faster than security controls, the attack surface is not just more users. It is more places where sensitive data can be observed, copied, or acted on. The governance gap comes from assuming that AI access is a single control problem, when in practice it spans endpoint visibility, application permissions, and data movement paths.
Practical implication: Security teams need endpoint-level coverage for AI apps, not just SaaS monitoring.
Why coding assistants create higher blast radius than general chat tools
Coding assistants are not just conversational interfaces. They are embedded into developer workflows, often with access to source trees, version control, and build artefacts, and in agentic modes they may execute commands. That changes the control model because the tool can move from reading code to influencing production-relevant activity. If the assistant can see credentials in config files or API keys in environment variables, the blast radius includes both intellectual property and operational access. The issue is governed access scope, not tool category alone.
Practical implication: Treat coding assistants as privileged endpoints and limit what they can read, modify, or execute.
Why model diversity breaks single-vendor AI governance
Enterprises are not standardising on one assistant. Users choose whichever model helps them finish the task, which means risk moves across tools and operating systems faster than policy approval cycles. A control set built around one approved model misses the others, and that creates blind spots for detection, response, and data loss prevention. This is especially problematic in mixed fleets where Mac and Windows usage patterns diverge sharply. Governance has to follow the work pattern, not the vendor name.
Practical implication: Build discovery and enforcement around all endpoint AI apps, across both platforms and models.
Threat narrative
Attacker objective: Exploit the widened endpoint AI access pattern to expose sensitive code, secrets, and internal business data at scale.
- Entry occurs through ordinary employee adoption of endpoint AI apps and coding assistants inside developer and sales workflows, where local access is far broader than a browser session.
- Credential access happens when assistants can reach source code, configuration files, environment variables, and internal documentation that may contain API keys or other secrets.
- Impact follows when ungoverned AI activity expands the opportunity for data exposure, policy evasion, and accidental leakage across the enterprise endpoint estate.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Adoption velocity is now the primary governance variable for enterprise AI risk. Security teams that still organise controls around the most popular model or the most visible SaaS app are managing the wrong denominator. The real exposure grows where endpoint AI tools spread fastest while control coverage lags behind. Practitioners should rebase governance on device-level usage, data sensitivity, and workflow access.
Coding assistants create a distinct identity problem because they behave like privileged non-human actors inside developer environments. They can reach files, repositories, and in some configurations run commands, which makes them functionally closer to governed runtime actors than to simple chat interfaces. That intersection matters for IAM and NHI programmes because the control question becomes who or what is allowed to touch code and credentials from the endpoint.
Endpoint fragmentation is a policy failure mode, not just an inventory issue. When Mac and Windows users converge on different AI tools, a single control plane leaves part of the fleet outside effective monitoring. This widens the visibility gap across data loss prevention, incident response, and access governance, and it shows why mixed estates need control models that follow endpoints rather than vendors.
AI governance debt is accumulating in the same functions that hold the most sensitive data. Engineering and sales drive most endpoint AI usage in the dataset, yet those are the groups most likely to touch source code, credentials, contracts, and customer information. The lesson for practitioners is straightforward: the highest-growth AI usage and the highest-value data are now colliding in the same operating lanes.
Blast-radius control is becoming the decisive control variable for enterprise AI. In a fast-growing endpoint AI estate, the question is no longer whether employees will use AI, but how much access each tool is allowed to inherit from the device and the user session. Governance that cannot bound read, modify, and execute permissions will remain reactive, not preventive.
From our research library:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
- Read next: Agentic AI Security Guide
What this signals
Endpoint AI governance now needs a device-first model. The operational failure is not that employees use AI, but that many tools now live inside the endpoint and inherit local context that cloud-only controls never see. Security teams should treat AI discovery, data policy, and response as an endpoint governance problem first, then a vendor selection problem second.
AI governance debt is accumulating in developer workflows. Coding assistants sit close to source code, secrets, and build paths, so they should be reviewed through the same lens as privileged runtime activity. That intersection matters for NHI and IAM programmes because the real control question is who or what can inherit access from a user session on the device.
Shadow AI becomes more dangerous when model choice is fluid. Users move between tools as tasks change, and that means the governance boundary must follow usage, not approval lists. Teams that only monitor one sanctioned model will continue to miss the workflow paths where data exposure actually happens.
For practitioners
- Define endpoint AI inventory and ownership Map every AI native app and coding assistant in use across managed endpoints, including browser, desktop, and agentic variants. Assign ownership for discovery, approval, and review so shadow AI does not sit outside policy scope.
- Constrain coding assistant access to minimum required scope Limit repository, file system, environment variable, and command execution access to the least amount needed for the developer task. Separate read-only assistance from execution-capable workflows wherever possible.
- Expand detection beyond sanctioned AI brands Build telemetry and DLP rules that detect AI usage patterns at the endpoint layer, not just approved vendor names. This is necessary when employees switch tools across Mac and Windows or adopt new models ahead of formal approval.
- Calibrate governance to sensitive departments first Prioritise engineering and sales workflows where AI usage concentrates and where exposure would be most damaging. Tune policy, logging, and response playbooks around source code, credentials, contracts, and customer data.
- Review agentic execution paths for privilege creep Where coding assistants can execute commands, separate assistive functions from task execution and require explicit control over elevated actions. That prevents local productivity tools from inheriting broader operational privilege than intended.
Key takeaways
- The core problem is not AI popularity but the speed at which endpoint tools enter high-value workflows before governance catches up.
- Coding assistants are riskier than general chat tools because they can see code, secrets, and sometimes execution paths inside developer environments.
- Mixed endpoint fleets make single-vendor AI policies unreliable, so discovery and enforcement have to span devices, tools, and departments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Coding assistants can read files and execute commands, which matches tool misuse risk in agentic workflows. |
| ASI03 — Identity & Privilege Abuse | The article centres on assistants inheriting endpoint privilege and local context beyond intended scope. | |
| Recommendation — Constrain tool permissions so coding assistants can only access files and actions required for the task. Separate user identity from assistant execution rights and limit inherited privilege on the endpoint. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance coverage lagging behind AI adoption velocity. |
| Recommendation — Define ownership, policy scope, and accountability for endpoint AI before broad adoption spreads. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The risk arises from overly broad access to code, secrets, and internal data on endpoints. |
| Recommendation — Review and reduce endpoint AI entitlements so tools cannot reach more data than required. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Coding assistants can expose embedded secrets and enable data leakage from developer environments. |
| Recommendation — Map assistant and endpoint telemetry to credential access and exfiltration behaviors for detection. | ||
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.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- Governance Gap: A governance gap is the distance between knowing an asset exists and being able to enforce policy on it. In identity programmes, it appears when discovery, review, and enforcement are split across different tools or teams, leaving access partially visible but not truly controlled.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It is designed for practitioners who need to connect identity controls to modern AI and endpoint risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org