Your Biggest Insider Threat Is No Longer Human

Governing Shadow AI: Managing Risk in the AI Era

Executive Summary

Artificial intelligence (AI) is silently reshaping insider risk along two emerging axes. First, shadow AI: unsanctioned tools employees use to accelerate work, moving sensitive data through unapproved and unmonitored channels. Second, the AI platforms themselves: features and services that vendors or individual teams can switch on in ways that quietly reclassify credentials, data, and workflows the organization had already assessed and signed off on. Both stem from the same blind spot: organizations cannot see where AI is being used, what data is entering it, how its outputs persist, or who is accountable when something goes wrong.

Recent research underscores the scale of the problem. Ponemon Institute and DTEX’s Cost of Insider Risks 2026 Global Report found that average annual losses from insider incidents have reached $19.5 million for organizations with 500 or more employees, a 20 percent increase since 2023—and AI is now a measurable driver of that trend. IBM’s Cost of a Data Breach Report 2025 found that shadow AI contributed to 20 percent of breaches studied and added an average of $670,000 to breach costs, while 63 percent of organizations reported no AI governance policy in place. Beyond user-driven exposure, the platforms themselves can shift the risk landscape. The Google Cloud/Gemini case study analyzed in this paper shows how AI enablement by one team can reclassify previously low-sensitivity credentials as high-sensitivity, without notice to the teams that originally deployed them — an exposure that traditional controls would not detect.

The response should be to govern AI as a coherent operating model: visibility, data lifecycle controls, identity and credential management, monitoring, third-party oversight, and safe alternatives.

The Rising Cost of Insider Risk

Insider incidents are increasing in financial impact. The Cost of Insider Risks report—which surveyed 354 organizations and interviewed 8,750 information technology (IT) and security professionals—observed nearly 7,500 insider incidents across the surveyed organizations, averaging twenty-five per company.

Shadow AI and modern insider risk are symptoms of a broader governance gap: organizations lack enterprise visibility into where AI is used, what data enters AI tools, how outputs persist, and which controls and accountabilities apply across the AI lifecycle. A governance framework—such as the “Confidence by Design” framework introduced by BRG’s Amy Worley—can help organizations align people, processes, and technology so that insider-risk controls become observable, enforceable, and defensible, while enabling AI adoption that creates value.

The financial burden is not evenly distributed. Regulated industries face the highest costs, with healthcare and pharmaceutical sectors averaging $28.8 million per company. Negligence accounts for more than half of total insider losses. Malicious incidents represent 27 percent of cases, averaging $4.7 million, while employees outsmarted by adversaries account for 20 percent, averaging $4.5 million.

The severity and cost of incidents are escalating despite improvements in containment times. The data underscores the critical need for robust insider risk management, especially as organizations face increasing complexity and digital transformation. Translating these figures into budgetary terms highlights the urgency for leadership to prioritize insider risk as a strategic enterprise concern.

The business case for investment is equally clear. Mature insider risk programs demonstrate strong return on investment, preventing at least seven incidents per year and saving $8.2 million in avoided breach costs. Realizing that return depends on treating shadow AI as an insider-risk vector within a coherent governance approach so controls, documentation, and accountability remain consistent across use cases.

Shadow AI is now a measurable component of that risk. Shadow AI was a contributing factor in 20 percent of breaches studied and added an average of $670,000 to breach costs; 63 percent of organizations reported no AI governance policy in place; and 97 percent of organizations that experienced AI-related security incidents lacked proper AI access controls.

Why Shadow AI Is an Insider Risk

These figures reflect a structural pattern rather than a series of isolated incidents. Shadow AI and modern insider risk are largely symptoms of a governance gap: limited enterprise visibility into where AI is used, what data enters AI tools, how outputs persist, and which controls and accountabilities apply across the AI lifecycle.

Shadow AI refers to employees using unsanctioned AI tools to accelerate work, often without organizational leadership’s knowledge or consent. This creates unmanaged data paths, exposing sensitive information to external platforms and bypassing traditional security controls.

Common examples include uploading internal documents to generative AI tools, using AI meeting assistants that generate publicly accessible summaries containing confidential information, and granting AI browsers or agents access to corporate systems. These practices introduce invisible data-exfiltration channels, increasing the risk of data breaches and regulatory penalties. The rise of shadow AI is driven in part by productivity incentives (e.g., speed, summarization, drafting, search capabilities), making it essential for organizations to balance the increased productivity AI provides with security, privacy, and overall risk mitigation.

Shadow AI is emerging as a key accelerant of insider risk. Blocking popular AI tools is insufficient, as employees often seek alternative platforms, potentially increasing rather than reducing risk. The core gap is not just tool access but the absence of governance and observability over what AI tools are being used, what data is being entered into them, and how long AI-generated artifacts remain accessible.

Shadow AI is one side of the AI-era insider-risk problem. The other is what happens at the platform level: features and services enabled by vendors—or by individual teams within an organization—can silently change the risk profile of credentials, data, and integrations previously assessed under different assumptions. Human- and systems-driven AI risk are two expressions of the same underlying governance gap and require the same response: visibility, classification, accountability, and continuous monitoring across the AI lifecycle. The case study below illustrates the systems-driven dimension in concrete terms.

How Data Leaves the Enterprise

Data exfiltration by insiders often occurs through channels that organizations underestimate. Collaboration platforms such as Microsoft 365 and Google Drive are common vectors, enabling easy sharing and storage of sensitive information. When misclassified as low-sensitivity assets, these platforms allow uncontrolled proliferation of intellectual property.

Application programming interface (API) tokens and automation scripts designed for productivity can inadvertently create persistent data extraction mechanisms if left unmonitored. Personal devices accessing corporate identity providers further complicate visibility and control, especially when combined with off-channel communications via consumer messaging applications. These behaviors bypass traditional monitoring and create blind spots in data governance.

Leaders should assume that collaboration platforms and AI tools can be used to move sensitive data outside the organization and manage them accordingly. This includes setting clear rules on what data can be shared, limiting access based on role, monitoring usage for unusual activity, and implementing automated controls to prevent or stop data from being exposed. When combined with user training and ongoing policy refinement, these measures substantially reduce exfiltration risk.

Common Shadow AI Scenarios

Scenarios that illustrate the risk in practice include:

• Sensitive data exposure. Uploading internal documents into AI tools risks data leakage and regulatory noncompliance
• Unsecured AI notetakers. Publicly accessible recordings and summaries can inadvertently share confidential information.
• Bypassed security controls. AI tools and agents can create data pathways that bypass traditional controls and logging.
• AI browser misuse. Agents that access malicious sites or generate inappropriate or incorrect output introduce additional security and reputational risks.
• Model training and data persistence. Inputs may be retained, reviewed, or used to train provider models. Once incorporated, sensitive content cannot be recalled reliably. Downstream consequences are still emerging and not fully understood.

These behaviors are often motivated by productivity needs but may result in significant risk exposure, including data leakage, loss of observability, and potential regulatory violations.

A Case Study in Emergent AI Risk: API Key Privilege Expansion

Google Cloud API keys and the Gemini AI platform offer a concrete example of how AI enablement can silently alter an organization’s security posture—and of a core governance challenge: platform changes can retroactively shift risk, and organizations need mechanisms that trigger reassessment, credential review, and documentation when AI services are enabled.

For over a decade, Google had consistently documented its API keys as nonsensitive artifacts that could be embedded safely in public-facing client-side code. Official documentation instructed developers to paste API keys directly into HTML, and security guidance from Firebase, the web-based platform used to build AI agent services, explicitly stated that API keys are not secrets and do not control access to database or storage contents. API keys were used primarily to identify a project for routing, quota tracking, and billing purposes, not as authentication credentials. As a result, engineers and security teams reasonably distinguished between Google API keys and truly sensitive credentials, and entire development ecosystems evolved around this model.

That assumption changed when Google introduced Gemini. When the Gemini API was enabled on an existing Google Cloud project, previously exposed API keys in that project could silently gain access to sensitive Gemini endpoints, including those handling uploaded files, cached AI context, and billable large language model (LLM) usage. This change occurred retroactively, without warning, notification, or explicit consent from developers or security teams. The original key owner received no notification that the risk profile of its exposed key had changed.

Analysis revealed 2,863 live API keys publicly exposed across diverse organizations—a reflection of how broadly the original guidance had been followed in good faith. The point is that organizations had followed Google’s documented best practices. The subsequent security implications did not arise from misuse but from a fundamental change in how those same keys were interpreted once Gemini entered the platform.

Additionally, Gemini usage is billable, meaning abused keys could generate significant and unexpected financial impact. The result was a widespread, latent exposure that activated only when AI services were enabled—often by different teams for experimental purposes to test Gemini capabilities—without any signal to the teams that had originally deployed the keys.

What Attackers Can Do with Exposed Keys

The practical impact of this type of exposure is significant despite the simplicity of the attack. An attacker needs only to view the source code of a public website or scrape common crawl datasets to obtain exposed API keys. With a valid key, they can probe AI endpoints to determine access. Successful access may allow retrieval of uploaded files, cached AI content, or contextual data that organizations assumed was private.

Beyond data exposure, attackers can consume LLM tokens, generating substantial usage charges billed directly to the victim organization. Depending on model choice and context window size, malicious usage can result in thousands of dollars in costs and exhaust quotas that disrupt legitimate services.

Importantly, this attack requires no infrastructure compromise, credential theft from internal systems, or sophisticated tooling. It exploits trust assumptions embedded in public-facing code. The risk spans cybersecurity, financial exposure, service availability, and reputational harm and introduces legal and compliance considerations when sensitive or regulated data is processed through AI systems believed to be protected. This combination of low attack complexity and high potential impact elevates the issue from a technical curiosity to a material enterprise risk.

The key failure involves the absence of governance processes that require change control, risk reassessment, and credential lifecycle management when AI capabilities are introduced.

Abuse of Legitimate Platforms

A defining characteristic of sophisticated insider and external malicious activity is the extensive use of legitimate platforms and services. Threat actors routinely use cloud services, consumer VPNs, mainstream email providers, and collaboration platforms to blend malicious traffic and communications into normal enterprise patterns.

By operating within trusted tools that organizations depend on, threat actors reduce behavioral anomalies that traditional security controls might otherwise flag. Security risk is no longer confined to obviously malicious infrastructure. Trusted developer ecosystems, collaboration platforms, and open-source workflows can be co-opted as adversary infrastructure.

This raises complex policy and oversight questions, including: How much monitoring is appropriate within development platforms? How does the organization balance productivity with risk controls? How does the organization ensure that trusted tools are not becoming blind spots in its risk posture? The use of personal accounts on consumer messaging applications to conduct firm business compounds this challenge by creating opaque data flows beyond corporate oversight.

Lessons from Real-World Incidents

Real-world insider threat incidents highlight recurring patterns that organizations must address. One case involved a contractor granted excessive access without proper vetting, resulting in months of undetected data movement. Another example featured productivity scripts leveraging API tokens, which created persistent data extraction channels outside formal governance. In a third incident, employees used personal devices to access corporate identity platforms, bypassing endpoint monitoring and enabling unauthorized data transfers.

These cases underscore the importance of rigorous access governance, contractor due diligence, and continuous monitoring of collaboration tools. These failures often stem from cultural and procedural gaps rather than technical limitations. Leadership intervention—such as implementing a comprehensive AI governance framework—could have prevented escalation in each case.

Governance and Controls

Why Blocking Fails

Blocking popular AI tools can backfire and push employees to alternative, potentially riskier platforms. The gap is not just tool access but the absence of governance and observability: organizations often lack visibility into which AI tools are used, what data is entered, and how long AI-generated artifacts remain accessible. Security teams must balance productivity with control and transparency, focusing on sanctioned options, logging, training, monitoring, and data controls. The imperative is to provide approved, instrumented tools that meet business needs and are monitored for compliance.

Controls Roadmap

Organizations should implement insider-risk and shadow-AI controls as part of a structured AI governance operating model. Our Confidence by Design framework typically includes:

• Visibility and inventory (map the AI ecosystem): Maintain an enterprise inventory of AI tools, models, agents, plug-ins, and third-party AI services—including unsanctioned shadow AI—and map where sensitive data can enter and exit.
• Data lifecycle governance by design: Define what data may be used with AI tools; how outputs are classified, retained, and shared; and which use cases require heightened controls or approvals.
• Identity, access, and credential governance: Treat AI agents and API credentials as privileged access pathways. Enforce least privilege, lifecycle management, rotation, and revocation.
• Monitoring and accountability: Implement logging, observability, and escalation workflows that tie AI use back to owners, approvals, and defined controls so deviations are detectable and actionable.
• Third-party AI governance: Extend diligence, contracting, and ongoing oversight to vendors and platforms, recognizing that AI enablement by one team can alter risk owned by another.
• Training and safe alternatives: Provide approved, instrumented AI tools and practical user guidance to reduce incentives for risky workarounds.

The objective is not simply to block AI tools but govern AI-enabled workflows in a way that is auditable, defensible, and consistent with business value creation.

Control Mapping: NIST SP 800-53 Rev. 5 and SOC 2

From a controls perspective, the API key privilege expansion scenario maps directly to established frameworks. Under NIST SP 800-53 Rev. 5, the most direct linkage is authenticator governance: IA-5 (Authenticator Management) applies because API keys become authenticators once they can authorize AI service calls and must be protected, rotated, revoked, and scoped appropriately. IA-2 (Identification and Authentication) is implicated where API keys serve as the only authentication factor without sufficient identity assurance. AC-6 (Least Privilege) and AC-3 (Access Enforcement) are impacted because unrestricted keys and retroactive privilege expansion violate least-privilege expectations. SI-4 (System Monitoring) is critical for detecting anomalous AI usage, including cost spikes and unusual endpoint patterns.

Under SOC 2 trust services criteria, the same issues surface as logical access and change control failures. CC6.1 (Logical Access) covers mechanisms preventing unauthorized access. CC6.3 (Provisioning/Authorization) is relevant because access expanded without explicit approval. CC8.1 (Change Management) captures the governance failure: enabling an AI service should trigger formal evaluation, testing, and approval, including reassessment of existing credentials. Auditors will look for evidence including key inventories and ownership records, documented API restrictions, change tickets approving AI service enablement, monitoring dashboards and alerts, and post-change reviews confirming public keys cannot authenticate to sensitive AI endpoints.

Business, Legal, and Regulatory Impact

Successful compromise of sensitive information through insider channels can lead to intellectual property loss, service disruption, and erosion of customer trust. Because developers often have broad system access, the potential blast radius is significant. From a legal and regulatory perspective, these incidents intersect with export controls, sanctions compliance, and data protection obligations. Organizations that unknowingly employ or contract with unauthorized actors could face regulatory scrutiny—even in the absence of malicious intent. Effective oversight requires documented risk assessments and controls that demonstrate due diligence in identity verification, access management, and third-party oversight.

What Leaders Should Do Now

Proactive AI governance, change monitoring, and credential management are now core components of enterprise risk management rather than just optional controls. The remainder of this section sets out the questions board members and senior executives should be prepared to answer and the operating-model elements that turn those answers into a defensible program.

Board-Level Questions

Senior leaders and boards should be prepared to address the following questions:

• Where does sensitive data enter AI tools today?
• Do our controls treat AI agents as privileged insiders?
• Do employees have safe, approved AI alternatives?
• How do we measure avoided incidents and financial exposure?

Building an Effective Insider Risk Management Program

As an effective insider risk management (IRM) program is established, companies should extend to AI-enabled workflows the same accountability, documentation, and monitoring expectations that apply to other cybersecurity risks. The program requires a structured model integrating people, processes, and technology that is continuously adapted to address evolving threats. IRM should be a cross-functional initiative involving security, legal/compliance, human resources, and business units with clearly defined roles and responsibilities. Key capabilities include user and entity behavior analytics (UEBA) to detect anomalies, robust data loss prevention solutions with automated remediation, and identity lifecycle management to enforce timely access revocation. Case management workflows must ensure consistent escalation and documentation while governance committees provide oversight and accountability.

Technology alone is insufficient. Cultural and procedural elements—policy enforcement, ethical monitoring, and privacy safeguards—are critical to maintaining trust and compliance. Regular tabletop exercises validate readiness and response protocols. Metrics such as time-to-detect, time-to-remediate, and insider incident trends should be reported to leadership, reinforcing transparency and continuous improvement.

Lessons for Senior Leadership

AI enablement can fundamentally and silently change security assumptions embedded in legacy systems. Credentials that were intentionally public can become sensitive overnight due to platform evolution. AI risk extends beyond model outputs to include access control, billing exposure, and third-party architectural decisions. AI features enabled by one team can materially impact risk owned by another.

Organizations should ensure that enabling AI services triggers security review workflows, inventory updates, and credential audits. Vendor documentation should not be treated as static truth, especially in rapidly evolving AI ecosystems. All API keys should be treated as credentials requiring lifecycle management, monitoring, and rotation regardless of historical guidance. This is not an isolated issue specific to any single platform; it is a warning signal for how AI platforms can reshape risk landscapes without clear indicators to the organizations that depend on them.

Proactive AI governance, change monitoring, and credential management are no longer optional. They are core components of enterprise risk management.