Notifications
Clear all
Topic starter
18/08/2026 2:43 pm
TL;DR: Shadow AI has moved from an edge-case productivity habit to a board-level governance gap, with Verizon reporting 45% of employees now use AI on corporate devices and 67% of those users logging in through personal accounts, according to ArmorCode. The control problem is no longer discovery alone, but deciding which AI use cases expose sensitive data, compliance obligations, and code risk before they spread.
NHIMG editorial — based on content published by ArmorCode: The Hidden Threat, Understanding and Mitigating Shadow AI Risks
By the numbers:
- 45% of employees are now regular users of AI on their corporate devices, up from 15% the year before.
- 67% of users accessing AI platforms from corporate devices are doing it through non-corporate accounts.
Questions worth separating out
Q: How should security teams govern shadow AI without blocking productivity?
A: Use visibility-based controls instead of blanket bans.
Q: What breaks when employees use personal and corporate AI accounts interchangeably?
A: Interchangeable account use breaks attribution, policy enforcement, and data handling assumptions.
Q: How do you know if Shadow AI controls are working?
A: Look for a shrinking set of approved AI services, visible logs for prompt and integration activity, clear data-class restrictions, and documented review steps for outputs.
Practitioner guidance
- Inventory AI usage by identity and device context Correlate browser activity, SaaS logs, and endpoint telemetry to identify which users are accessing public or unapproved AI tools, then rank them by the sensitivity of the data they can reach.
- Block regulated data paths to unapproved AI services Apply policy controls that prevent PII, PHI, source code, and financial records from being submitted to AI applications that lack enterprise terms, retention controls, or approved jurisdictional handling.
- Treat AI-generated code as untrusted input Require security review for model-generated code, dependency recommendations, and authentication logic before merge, especially when suggestions come from unmanaged tools or personal accounts.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- How ArmorCode maps AI usage into exposure management workflows across SASE, EDR, firewalls, identity systems, and cloud platforms
- The decision logic behind prioritising one shadow AI finding over another when dozens of unsanctioned tools appear at once
- How AIEM assigns ownership, approval status, and risk decisions to each AI asset for audit and board evidence
- What the AIEM solution brief says about connecting AI risk with application security and software supply chain security
👉 Read ArmorCode's analysis of shadow AI risks and AI exposure management →
Shadow AI governance gap: are your controls keeping up?
Explore further
18/08/2026 3:27 pm
Shadow AI is fundamentally an access-governance problem, not only a tooling problem. Employees adopt AI through personal accounts, browser extensions, and unsanctioned services that sit outside standard approval workflows. That means entitlement review alone cannot tell security teams what data those users can expose. The stronger governance lens is to treat AI usage as a controlled access path to enterprise information, with policy attached to identity, device context, and data sensitivity.
A question worth separating out:
Q: Who is accountable when shadow AI uses corporate credentials to process sensitive data?
A: Accountability sits with the identity owners, the platform owners, and the governance function that approved the underlying access. If a service account or OAuth app can reach regulated data and an AI feature uses that path, the organisation is responsible for the resulting exposure and audit trail.
👉 Read our full editorial: Shadow AI is outpacing perimeter controls and exposing data
