Home > Security and Compliance Blog > Cybersecurity Risk Management > Senior Executives Are Driving Your Shadow AI Risk

Senior Executives Are Driving Your Shadow AI Risk

by Patrick Spencer updated July 20, 2026 Cybersecurity Risk Management

Reading Time: 13 minutes

Most shadow AI programs are built on a flawed assumption: that the risk lives with junior staff pasting customer data into a free chatbot to save time on a deadline. New survey data says otherwise. Executives are the ones going around the rules, and they’re doing it at roughly double the rate of the employees they manage.

A survey conducted by TrustedTech, a Microsoft solutions partner, and reported by CSOonline, found that nearly two-thirds of senior decision-makers admit to using unapproved, “shadow” AI tools — compared with 31% of lower-level employees. That gap alone should reframe how security teams think about AI governance. It isn’t a training problem confined to the newest hires. It’s a leadership behavior problem, and leadership sets the tone for everyone below them.

Table of Contents

What makes the finding harder to dismiss is that the same survey found three in four employees already understand the security and privacy risks shadow AI creates. People aren’t using unsanctioned tools because they don’t know better. Executives, who typically have the most visibility into what a data breach costs the business, are choosing convenience over caution anyway. A separate report from Teramind adds a second data point that reinforces the same conclusion: more than two-thirds of C-level executives say they prioritize speed over security when using AI.

For a company that has spent years building out AI data governance programs, acceptable use policies, and employee training modules, this is an uncomfortable but necessary correction. Governance programs modeled on the assumption that risk flows upward from entry-level staff are aimed at the wrong part of the organization. The people approving the AI policy are frequently the same people breaking it.

Key Takeaways

1. Executives use shadow AI at roughly twice the rate of their employees.

A survey from Microsoft solutions partner TrustedTech found that nearly two-thirds of senior decision-makers admit to using unapproved AI tools, compared with 31% of lower-level employees.

2. Awareness of the risk isn’t the problem — behavior is.

Three in four employees in the same survey acknowledge the security and privacy risks that shadow AI creates, yet usage at the top of the org chart keeps climbing anyway.

3. Speed is winning over security in the C-suite.

Research from Teramind found that more than two-thirds of C-level executives prioritize speed over security when using AI tools at work.

4. Most enterprise AI activity already runs outside IT’s view.

Two-thirds of enterprise AI activity happens through personal accounts on platforms the company has already licensed, according to Teramind, meaning the tools are approved but the accounts are not.

5. Policy alone won’t fix an executive-level habit.

Closing this gap requires governing what sensitive content AI tools and agents can actually reach, with controls applied at the point of access rather than in a training deck no one reads twice.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

What the TrustedTech and Teramind Data Actually Shows

It’s worth sitting with the specific numbers rather than treating this as a vague trend, because the scale is bigger than most security teams have budgeted for.

TrustedTech’s finding of nearly two-thirds of senior decision-makers using unapproved AI tools isn’t a rounding error next to the 31% figure for lower-level employees — it’s more than double. In practice, that means the people with the broadest access controls, the widest view into financial results, M&A activity, litigation strategy, and unreleased product plans, are also the group most likely to be moving that information into tools IT never vetted. Executives don’t handle low-value files. They handle the files a board would ask about the day after a breach — contracts, M&A documents, and intellectual property that represent the organization’s highest-value and highest-risk content categories.

Teramind’s research sharpens the picture further. Two-thirds of enterprise AI activity runs through personal accounts on platforms the company already licenses. That distinction matters. This isn’t primarily employees reaching for obscure or unlicensed AI startups. In many cases, it’s people signing into a personal login on a tool their own company pays for under an enterprise agreement, which strips out the admin controls, audit logging, and data retention settings that the enterprise license was supposed to guarantee. The company bought the governed version of the tool. The executive is using the ungoverned one, on the same platform, from the same laptop.

This gap is precisely why most organizations still can’t answer a basic question about their own AI exposure: how much of it is actually happening on accounts nobody manages. Visibility, not another policy document, is the missing piece. A formal risk assessment that maps current AI tool usage across both corporate and personal accounts — quantifying which content categories are flowing through ungoverned logins — gives security teams the evidentiary baseline they need to prioritize governance investment rather than react to the next disclosure.

Why Executives Bypass the Rules They Approved

There’s a reasonable question buried in all of this: why would the people who signed off on the AI policy be the ones most likely to ignore it?

Part of the answer is access. Executives generally face fewer practical obstacles to using whatever tool they want. They aren’t subject to the same device management, network restrictions, or manager oversight that a mid-level employee works under. If a policy relies on friction — a blocked domain, a flagged download, a manager who notices — executives are often the group with the least friction in their way.

Part of the answer is incentive. Senior leaders are measured on outcomes: revenue, timelines, competitive positioning. An AI tool that drafts a board deck overnight or summarizes a due diligence pile in an afternoon is an easy trade against an abstract, future risk of data exposure. Teramind’s finding that more than two-thirds of C-level executives prioritize speed over security isn’t really a mystery once you consider what executives are rewarded for.

And part of the answer is simply that policy documents don’t scale to behavior. An acceptable use policy can say precisely which tools are approved and which aren’t, but a document has no way to stop someone from opening a personal account in a browser tab. Security awareness training can raise the three-in-four number on risk recognition even higher, and the executive shadow AI numbers would likely stay flat, because awareness was never the missing piece. What’s missing is a control that applies regardless of which account, which device, or which login a person chooses to use. Shadow AI — ungoverned AI operating entirely outside the enterprise policy perimeter — is structurally different from a policy violation by a known employee using a known tool; it is invisible to the security team unless governance is attached to the content itself rather than to the login screen.

The Personal Account Problem: Governed Tools, Ungoverned Access

The personal-account finding from Teramind deserves its own attention because it exposes a specific failure mode that most AI governance programs aren’t built to catch.

Security teams tend to evaluate AI risk at the tool level: is this AI platform approved or not, does it appear on the sanctioned vendor list, has legal reviewed its data processing terms. That evaluation works when the risk is “an employee is using an unvetted AI tool.” It does almost nothing when the risk is “an employee is using a vetted AI tool through an account the company doesn’t manage.” The tool passes review. The account bypasses every control that review was supposed to attach.

This is why data governance built around tool approval lists is necessary but not sufficient. An enterprise contract with an AI vendor typically includes data residency commitments, retention limits, admin-level audit logs, and a guarantee that customer inputs aren’t used for model training. A personal account on the same platform typically includes none of that. Two-thirds of enterprise AI activity running through personal logins, per Teramind, means two-thirds of that activity is likely happening outside every one of those protections, even though the company already negotiated for them. For organizations handling PII, PHI, or other regulated data categories, this gap is not merely a security concern — it is a regulatory compliance failure that notification obligations, audit requirements, and supervisory authority inquiries will expose when the next incident surfaces.

The practical fix isn’t a longer list of banned domains. It’s controlling what sensitive content can reach an AI tool in the first place, independent of which account is doing the asking. If a policy engine sits between the content and the request rather than between the employee and a login screen, it doesn’t matter whether the request comes from a corporate account or a personal one — the sensitive file either meets the access rule or it doesn’t. Data classification applied to enterprise content before it reaches any AI tool is the prerequisite that makes this enforcement precise: a policy engine cannot apply sensitivity-based access rules to content that has not been categorized.

Why Training and Policy Alone Won’t Close an Executive-Level Gap

Most enterprise AI governance efforts to date have leaned on three tools: an acceptable use policy, security awareness training, and a list of approved vendors. All three are worth having. None of them address what the TrustedTech and Teramind data actually describes.

A policy document changes behavior only for the people who read it, believe it applies to them, and have no easier path around it. Training raises awareness, and the surveys already show awareness isn’t the gap — three in four employees already recognize the risk. A vendor approval list governs which tools IT will support, not which login an executive uses to reach an approved tool from a personal account.

None of these controls operate at the moment that actually matters: the point where a file, a folder, or a dataset would be handed to an AI system. That’s the layer where zero trust data protection principles apply directly — never trust a request by default, verify it against policy every time, and enforce that policy the same way regardless of title, device, or account type. An executive’s request to summarize a client file gets evaluated by the same rule as anyone else’s, because the rule is attached to the data, not to the person’s rank. Data minimization applied at this layer — passing only the minimum content the AI task requires, rather than granting broad access to entire document repositories — further reduces the blast radius of any governance failure that does occur.

Governing AI at the Data Layer: What Actually Closes the Gap

If executive behavior is the source of the risk, the fix has to work regardless of executive behavior. That means shifting control from “which tools are approved” to “what sensitive content can any AI tool or agent actually access, and under what conditions.”

A governance model built at the data layer evaluates every AI request against policy in real time: what is the file’s classification, who or what is asking, what’s the business justification, and does this specific request meet the rule. It doesn’t matter whether the requester is a person using a sanctioned corporate login, a person using a personal account on that same platform, or an AI agent acting on someone’s behalf — the request either satisfies the access policy or it’s denied. This is the same logic already applied to role-based access control and attribute-based access control for human users, extended to cover the requests AI systems generate on their behalf.

Two capabilities matter most in this model. The first is per-request access control: every single AI interaction with sensitive content is evaluated against classification, context, and policy at the moment it happens, not approved once and forgotten. The second is a complete audit trail of that evaluation — who or what asked, what was requested, what the policy decided, and when. When a CISO has to answer a board question about AI exposure, “we have a policy” is a much weaker answer than “here’s the log of every request an AI tool made against regulated data last quarter, and here’s what was allowed or blocked.” Feeding that audit log in real time into a SIEM platform gives security teams behavioral alerting when AI access patterns deviate from the established baseline — the detection layer that converts shadow AI from an invisible risk into a flagged, actionable event.

This also solves the personal-account problem directly. If governance is attached to the data rather than the login, it no longer matters whether the two-thirds of AI activity Teramind identified is happening through a corporate account or a personal one. The content itself carries its own access rule.

How Kiteworks Compliant AI and the Secure MCP Server Govern AI Access to Sensitive Data

This is the specific problem Kiteworks Compliant AI and the Kiteworks Secure MCP Server are built to address: governing what sensitive content any AI tool, human user, or AI agent can reach, rather than leaving that decision to which login someone happened to use.

Regulators write rules about data access, handling, and protection — not about which large language model or AI framework touched the data. That’s the operating premise behind Kiteworks Compliant AI: a person and an AI agent are both an identity type whose access to and use of regulated data needs governing, under one policy layer, not two separate ones. An employee prompting an AI assistant and an AI agent acting on that same employee’s behalf are both subject to the same rules, because the regulation only cares about the data.

In practice, that means every AI-driven request — whether initiated by a human through a chat interface or generated by an agent completing a task — passes through role-based and attribute-based access controls that evaluate data classification, requester identity, and context before any content moves. The Kiteworks Secure MCP Server connects AI clients like Claude and Copilot to an organization’s governed content using the Model Context Protocol, with every file access, folder operation, and metadata request inheriting the same OAuth 2.0-authenticated permissions and policy checks that already apply to that person elsewhere in the environment. Credentials stay in the OS keychain rather than the AI model itself, and every operation feeds a real-time audit trail that reports into existing SIEM and compliance workflows. The CISO Dashboard surfaces all AI data access events in a unified view, giving security leadership the real-time visibility into AI-mediated content flows that the personal-account problem makes otherwise invisible.

None of this depends on an executive choosing to comply with a policy. It depends on the sensitive content itself carrying enforceable access rules that apply the same way whether the person on the other end is following the rules or trying to route around them. That’s the difference between hoping the C-suite reads the AI policy and knowing the data is protected either way.

What CISOs Should Do With This Data

The TrustedTech and Teramind findings give security leaders a specific place to start looking, not just another statistic for a board deck.

Start with usage visibility rather than a policy rewrite. Most organizations already have logging capability on their licensed AI platforms; the gap is usually that nobody has pulled a report comparing sanctioned-account activity against total estimated AI usage across the org. If the Teramind ratio holds inside your environment — two-thirds of activity outside the governed account — that’s a measurable, trackable number, and it’s a far more persuasive data point for the board than “we think shadow AI is a risk.”

Next, look specifically at the executive layer instead of assuming the usual security-awareness audience of general staff. If senior decision-makers are the group driving unapproved usage, the account provisioning process and the escalation path both need an executive-specific track, not a company-wide email a VP skims and deletes.

Finally, treat “the sanctioned tool is too slow or too limited” as a real product complaint, not just a compliance violation to punish. If two-thirds of activity is happening on personal accounts on platforms the company already pays for, that often signals the governed version of the tool has friction the personal version doesn’t — extra approval steps, missing features, a login process nobody wants mid-meeting. Fixing that friction, paired with content-level governance like Kiteworks secure data exchange, addresses the behavior and the underlying data exposure at the same time. The Kiteworks Private Data Network delivers the unified governance environment — one policy engine, one audit trail across all content channels — that makes the governed option as frictionless as the personal account, so executives choose it not because policy requires it but because it works as well.

To learn more about governing what sensitive content AI tools and agents can access across your organization, schedule a custom demo today.

Frequently Asked Questions

Shadow AI refers to employees using AI tools that IT hasn’t reviewed, approved, or configured with enterprise controls. Executive shadow AI use is a distinct problem because senior leaders typically have the broadest access to sensitive data — financial results, M&A activity, litigation strategy — and face fewer practical restrictions on which tools or accounts they use. A TrustedTech survey found nearly two-thirds of senior decision-makers use unapproved AI tools, compared with 31% of lower-level employees, which means the highest-risk data is disproportionately exposed to the least-governed usage. Governing this risk requires controls at the data governance layer rather than relying on executives to self-police. Organizations subject to regulatory compliance obligations — HIPAA, GDPR, CMMC — should treat executive shadow AI as a direct compliance risk: the regulatory obligation applies to the data regardless of whether the person accessing it through an ungoverned account is the CEO or an intern.

Because awareness was never the actual gap. The same TrustedTech survey found that three in four employees already recognize the security and privacy risks that shadow AI creates, yet usage keeps rising anyway, particularly among senior decision-makers. Training can raise awareness further, but it can’t stop someone from opening a personal account on a licensed platform when there’s no control preventing it. Closing the gap requires enforcement at the point where sensitive content would reach an AI tool, using zero trust data protection principles that verify every request regardless of who’s making it. Data classification of enterprise content before it reaches any AI tool is the foundational prerequisite — a governance policy engine cannot enforce sensitivity-based rules on content it has not categorized, and awareness training cannot compensate for missing classification infrastructure.

It means the risk isn’t primarily about unapproved tools — it’s about unmanaged accounts on approved tools. An enterprise AI license typically includes admin-level audit logs, data retention limits, and a guarantee that inputs aren’t used for model training. A personal account on the same platform generally has none of those protections. According to Teramind, two-thirds of enterprise AI activity happens this way, which means most of the governance an organization negotiated for in its vendor contract may not actually apply to how the tool gets used day to day. Controls need to follow the access controls on the content itself, not the login screen. A risk assessment that inventories which content categories are flowing through unmanaged AI accounts — mapped against the regulatory notification obligations that apply to each category — converts this from a vague “shadow AI is bad” concern into a prioritized, documented risk that the board can act on.

An acceptable use policy is a document that defines which tools are approved and how employees should behave — it has no mechanism to enforce that behavior in the moment. Per-request access control evaluates every individual AI interaction with sensitive content against classification, requester identity, and context at the time the request happens, and either allows or blocks it based on policy. This is how Kiteworks Compliant AI governs AI access: the rule travels with the data, so it applies the same way whether the request comes from a corporate account, a personal account, or an AI agent acting on someone’s behalf. Data minimization enforced at this layer — passing only the minimum content the AI task requires rather than granting broad repository access — further limits the blast radius of any governance gap that does occur, regardless of whether the requester is complying with policy or routing around it.

No. Agents are a second identity type alongside human users, both governed under the same policy layer — not a separate category that operates outside it. The Kiteworks Secure MCP Server authenticates every AI agent request using the same OAuth 2.0 permissions, role-based and attribute-based access controls, and audit logging already applied to human users in the environment. Whether a request to access a file originates from an employee prompting an AI assistant or from an agent completing a task on that employee’s behalf, it passes through the same governance and generates the same audit trail. The CISO Dashboard provides the unified real-time visibility across all AI-mediated access events — human and agent alike — that gives security leadership the detection surface needed to identify anomalous AI behavior before it escalates to a reportable incident.

Additional Resources