Shadow AI is outpacing perimeter controls and exposing data

At a glance

What this is: This is ArmorCode’s analysis of shadow AI as an enterprise governance problem, showing that unmanaged AI usage now exposes data, compliance, and code-security risks faster than perimeter controls can see them.

Why it matters: It matters because IAM, NHI, and broader security teams increasingly need to govern who can use AI tools, what data they can reach, and how those interactions are recorded, approved, and reviewed.

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.
• 60% of organizations don’t know the specific requests employees make to generative AI tools.

👉 Read ArmorCode's analysis of shadow AI risks and AI exposure management

Context

Shadow AI is the use of public or unapproved AI tools by employees without central oversight, and it creates a governance gap because data can leave the organisation through ordinary browser traffic that existing controls often treat as benign. In this article, ArmorCode argues that the primary failure is not just unsanctioned adoption, but the loss of visibility into what data, code, and regulated information are being sent to external models.

The article’s core point is relevant to identity and access governance because the same employee can interact with AI through personal logins, unmanaged browser extensions, and approved work devices, making entitlement review only part of the problem. That pattern is now typical rather than exceptional, which means security teams need policy, discovery, and data controls to converge rather than operate as separate programs.

Key questions

Q: How should security teams govern shadow AI without blocking productivity?

A: Use visibility-based controls instead of blanket bans. Identify which tools are in use, who is using them, and what data they can access, then apply targeted policies by role and data sensitivity. That approach preserves legitimate AI adoption while reducing exposure from unsanctioned tools and unreviewed data paths.

Q: What breaks when employees use personal and corporate AI accounts interchangeably?

A: Interchangeable account use breaks attribution, policy enforcement, and data handling assumptions. Security teams can no longer tell whether a prompt came from a governed enterprise identity or a personal account with different terms and controls. That weakens both auditability and the organisation's ability to enforce acceptable use.

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. If employees still rely on unofficial tools for core work, the programme is not yet governing behaviour, only issuing guidance.

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.

Technical breakdown

Why browser-based AI usage bypasses traditional perimeter controls

Shadow AI often enters the enterprise as normal web traffic, not as a malicious download or obvious rogue application. A browser tab, SaaS sign-up, or extension can move sensitive prompts and files out of the organisation without triggering classic firewall or malware rules. That is why the problem sits closer to exposure management and data governance than to network blocking alone. The security challenge is not simply detecting access to a known site, but understanding the content and identity context behind each interaction.

Practical implication: add AI application discovery to exposure workflows and classify traffic by data sensitivity, not just destination.

How unmanaged AI creates data lineage and compliance failures

When staff paste regulated or confidential information into unapproved AI tools, the organisation loses control over where that data is stored, retained, or reused. That breaks basic governance assumptions behind GDPR, auditability, and retention policy because the data may now exist outside approved jurisdictional and contractual boundaries. The failure is often invisible at the moment of submission, which makes post-incident reconstruction difficult. In practice, the issue is less about model capability and more about broken data stewardship.

Practical implication: require approved AI usage paths for regulated data and log every prompt or file submission that could affect retention or disclosure obligations.

Why AI-generated code introduces a new AppSec failure mode

Unauthorized coding assistants can accelerate delivery while also inserting flawed dependencies, weak authentication logic, or insecure patterns into production code. The risk is not that every AI suggestion is harmful, but that unreviewed model output can bypass the organisation’s normal secure development checks. Once that code is merged, the vulnerability becomes part of the application estate, often without a clear record of provenance. This creates a control problem across both application security and software supply chain governance.

Practical implication: treat AI-assisted code the same way you treat other untrusted third-party input and enforce review gates on model-generated changes.

NHI Mgmt Group analysis

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.

Browser-based AI usage creates a visibility trust gap that older perimeter models were never designed to close. Traditional network controls see an HTTPS request, not the prompt content or the business context behind it. That leaves teams with discovery data but no reliable prioritisation model. The named concept here is visibility trust gap: the organisation assumes it can govern what it cannot actually inspect. Practitioners should use that framing when deciding where exposure management must be paired with identity and data governance.

Shadow AI turns compliance into an evidence problem as much as a policy problem. If regulated data has passed into an unapproved model, the organisation may be unable to prove where it went, how long it persisted, or whether a deletion request can be honoured. That is why frameworks such as GDPR and the NIST Cybersecurity Framework matter here. Security teams need evidence trails, not just acceptable-use language, when auditors or regulators ask what happened.

AI-generated code should be governed as untrusted software supply input until it passes review. The article correctly shows that developer productivity gains can coexist with latent application risk. That means the organisation should not debate whether AI is allowed in development in the abstract. It should decide which classes of AI output are permitted, how provenance is recorded, and which code paths require human approval before merge.

Shadow AI will force identity programmes to think beyond login controls and toward data-path control. The same worker may authenticate through a sanctioned account while exfiltrating data through an unsanctioned AI service. That means IAM, DLP, and exposure management must be designed together. Practitioners should expect shadow AI to become a standard governance domain rather than a temporary exception.

What this signals

Shadow AI is already forcing security teams to move from perimeter logic to data-path governance, and that shift will only intensify as personal accounts and unmanaged browser extensions become normal work patterns. The practical challenge is not whether employees will use AI, but whether the programme can classify and control that use before regulated information and source code leave the organisation.

Visibility trust gap: shadow AI exposes the gap between what discovery tools can see and what governance teams can prove. If your operating model cannot assign ownership, data class, and approved use case to each AI interaction, then the organisation is collecting alerts without building defensible control. That is where identity, exposure management, and policy enforcement must converge.

For identity and access programmes, this is the moment to treat AI usage as another governed access surface alongside service accounts, APIs, and workloads. The teams that succeed will not just catalogue tools; they will connect user identity, device context, and data sensitivity so that AI adoption is measurable, reviewable, and explainable.

For practitioners

• 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. Use that inventory to separate low-risk experimentation from high-risk prompt exposure.
• 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. Keep the control focused on data classes rather than broad AI bans.
• 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. Pair that review with provenance tracking so teams can trace where the code came from.
• Build a decision record for every high-risk AI exception For each approved or tolerated AI tool, record the owner, business use case, data classes in scope, and the reason the exception was accepted. That makes later audit and incident response faster than reconstructing the decision after a data exposure event.

Key takeaways

• Shadow AI is no longer a fringe productivity habit. It is a governance gap that exposes data, compliance, and code risk through ordinary employee behaviour.
• The scale is already material. Nearly half of employees are using AI on corporate devices, while most access still happens through non-corporate accounts and poor request visibility.
• Effective control depends on prioritising by data sensitivity, identity context, and business risk, not on trying to ban every AI interaction.

Key terms

• 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.
• 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.
• AI Exposure Management: AI exposure management is the practice of identifying AI use, classifying the associated data and access risk, and turning that context into a governed decision. It extends beyond discovery by linking ownership, approval, and remediation into a repeatable control workflow.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.

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

👉 ArmorCode's full blog covers prioritisation, ownership tracking, and the control model behind AI exposure management.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that supports identity and security practitioners building control models. It is a practical fit for teams that need to connect access governance to real-world exposure management.