Microsoft 365 Copilot: Shadow AI Governance Must Include Executives

TrustedTech’s Andy Nolan is putting a sharp point on one of enterprise IT’s most uncomfortable AI realities: Shadow AI is not merely an employee-behavior problem. It is increasingly a leadership problem. In an interview focused on the company’s research and services strategy, TrustedTech’s Vice President of Technology argues that decision-makers are among the most frequent users of unapproved AI tools—even while many express concern over staff doing the same thing. That disconnect turns AI governance from a policy-writing exercise into a test of executive accountability, technical visibility, and whether sanctioned alternatives are genuinely useful enough to win adoption. Pulse 2.0’s interview with Nolan frames the issue as a central risk for organizations expanding their Microsoft 365, Azure, security, and AI footprints.
For Windows administrators, Microsoft 365 architects, CIOs, and security leaders, the message has immediate relevance. Copilot rollouts, tenant migrations, endpoint management, data classification, and cloud licensing may appear to sit in separate workstreams. In practice, they converge at the moment an employee—or a member of the C-suite—copies sensitive company information into an AI prompt.
TrustedTech’s position is therefore broader than a pitch for another security control. Nolan describes an operating model in which licensing, cloud design, identity, endpoint management, security operations, business continuity, and AI readiness are treated as a connected system. The strengths of that model are clear, particularly for organizations that want a single Microsoft-focused partner. But the interview also highlights a more universal lesson: no partner credential, AI policy, or Copilot license can substitute for disciplined data governance and leadership behavior.

---

Overview: Why Shadow AI Has Moved Up the Organizational Chart​

Shadow AI refers to the use of AI services, models, browser extensions, agents, or automation tools that have not been approved, configured, or governed by an organization. It can range from a staff member using a public chatbot to polish an email to an executive uploading a board presentation, financial forecast, contract draft, customer dataset, or strategic plan into an external generative AI service.
The latter scenario is where the stakes become acute. Nolan told Pulse 2.0 that TrustedTech’s research found 65% of global decision-makers and 67% of U.S. decision-maker-level employees using unapproved AI tools. In the same research, 56% of global decision-makers reportedly said they were concerned about employees using Shadow AI. The contrast is potent: leaders may see unauthorized AI use as a workforce risk while simultaneously treating their own use as an acceptable exception.
Those figures should be understood as vendor-sponsored research findings, rather than universal measurements of every enterprise environment. The interview does not provide the underlying sample design, respondent counts, or detailed definitions of “decision-maker” and “unapproved” in the published discussion. Still, the direction of travel is difficult to dismiss. Senior staff have the same incentives as everyone else—speed, convenience, and a desire to reduce administrative work—but they often work with data that carries a much higher commercial, legal, and regulatory impact.
This changes the traditional governance model. Many IT policies were designed for a world in which risk flowed largely from the bottom upward: users installed unsanctioned apps, bypassed controls, or stored business data in inappropriate places. Generative AI creates a more symmetrical problem. The person with the greatest access to strategic information may also be the person most able to bypass the rules without being challenged.
Nolan’s core argument is that AI governance must become visibly role-neutral. If the controls apply to employees but not to executive leadership, they are not controls so much as signals about which people are allowed to create unmanaged risk.

TrustedTech’s Expanding Microsoft-Centered Strategy​

TrustedTech began as a Microsoft licensing specialist and has broadened into a service provider spanning licensing, cloud, support, security, and AI enablement. Its own website lists on-premises licensing for products including Windows Server, SQL Server, Exchange Server, SharePoint Server, Office, and Windows, alongside Microsoft 365, Azure, endpoint protection, managed detection and response, backup, security awareness training, migrations, and Intune-related services. TrustedTech’s service catalog reflects the company’s effort to position itself as a lifecycle partner rather than simply a reseller.
That expansion is significant because enterprise AI initiatives rarely begin on a blank slate. A Copilot implementation may depend on identity hygiene, Microsoft Entra configuration, Conditional Access, data residency requirements, SharePoint permissions, sensitivity labels, endpoint posture, retention policies, and a defensible licensing model. Organizations with complicated hybrid estates also need to consider legacy Windows Server workloads, SQL Server licensing, virtual machines, Azure consumption, and the often-underestimated work of tenant consolidation.

From licensing decision to operating model​

Nolan characterizes TrustedTech’s three pillars as:

• Licensing, including on-premises Microsoft licensing and Microsoft 365/Azure optimization.
• Cloud and professional services, including Copilot implementation, Azure infrastructure, tenant migrations, modern work, mobile-device management, and Intune acceleration.
• Security and resilience, including email security, endpoint protection, managed detection and response, awareness training, backup, and retention.

This is a strategically coherent grouping. Licensing decisions influence which security features and management capabilities are actually available. Security requirements affect the architecture of a migration. Poorly governed file permissions can become far more visible—and more damaging—when an AI assistant can retrieve content from across a tenant. An organization can therefore buy an AI product and still be unprepared to use it safely.
The strongest element of TrustedTech’s stated approach is this insistence on connection. It recognizes that AI readiness is not a standalone SKU. It is an operational condition created by appropriate data controls, user readiness, service design, and a clear understanding of where data is allowed to travel.

Credentials are meaningful, but not a substitute for due diligence​

TrustedTech says it holds all six Microsoft Solutions Partner designations, covering Business Applications, Data & AI, Digital & App Innovation, Infrastructure, Security, and Modern Work. Microsoft’s Partner Center documentation confirms that these are the six current Solution Partner areas, while Microsoft’s program FAQ explains that the designations are tied to partner capability measures involving performance, skilling, and customer success.
TrustedTech’s website also presents itself as a top-tier Cloud Solution Provider and a six-designation Microsoft Solutions Partner. Its company overview identifies the firm as founded in 2017 and highlights its Microsoft-oriented implementation and support business. The company’s August 2025 rebrand from Trusted Tech Team to TrustedTech was explicitly presented as a shift from a licensing provider toward a broader AI, modernization, cloud, and security partner. TrustedTech’s rebrand announcement describes that repositioning directly.
These are useful indicators for prospective customers, especially those seeking one provider across Microsoft procurement and deployment. A Direct-Bill CSP relationship is also operationally meaningful: Microsoft explains that direct-bill partners purchase offers from Microsoft and sell them to customers while taking on billing, support, managed-services, security, compliance, and integration responsibilities. Microsoft’s CSP relationship guidance outlines those responsibilities.
However, credentials should be treated as entry criteria, not a final purchasing decision. An enterprise evaluating a provider should still test its actual delivery model:

1. How are Microsoft 365 Copilot permissions, data classification, and oversharing risks assessed before rollout?
2. Which services are delivered by the partner’s own staff versus subcontractors?
3. What logging, incident-response, and escalation paths exist for AI-related security events?
4. Can the partner document its data handling practices and the boundaries of any administrative access?
5. How are cost optimization recommendations reconciled with security, retention, and compliance needs?

The answer to those questions matters more than a badge alone.

---

The Executive Shadow AI Paradox​

Nolan’s most consequential observation is not that executives are reckless. It is that most governance programs were never built around the way executives work.
Senior leaders handle compressed timelines, ambiguous decisions, sensitive material, and requests that demand rapid synthesis. An AI assistant that can create a board briefing from notes, summarize a long legal document, compare forecasts, or produce talking points is exceptionally attractive. The productivity appeal is not theoretical. The danger is that convenience can erase the pause that normally precedes sensitive-data handling.
According to the Pulse 2.0 interview, Nolan attributes executive Shadow AI adoption partly to a belief that rules were created for the workforce, not the people setting strategy. Whether consciously held or not, that attitude is corrosive. Once a chief executive, finance leader, business-unit president, or board member uses an unsanctioned tool, it becomes harder for the IT department to credibly insist that other employees use the approved platform.

High-value data creates high-consequence exposure​

The risks Nolan identifies are practical rather than abstract. Sensitive information entered into an unauthorized tool may be subject to provider terms that differ sharply from the organization’s requirements. Depending on the service, data could be retained, processed in a different geography, exposed through connected tools, used in ways incompatible with contractual obligations, or placed beyond the organization’s normal audit and eDiscovery controls. Nolan’s interview specifically identifies financial models, customer records, strategic plans, and sensitive documents as examples of executive material that may be mishandled through unapproved AI usage.
The consequences can span multiple domains:

• Confidentiality: Nonpublic financial information, acquisition planning, product strategy, or customer data may leave approved collaboration systems.
• Compliance: Industry rules, contractual commitments, legal holds, records requirements, and data-residency obligations can be undermined.
• Intellectual property: Source code, designs, product roadmaps, and internal analysis can be exposed to third-party services.
• Insider risk: A user deliberately avoiding organizational visibility is not simply seeking productivity; that behavior may conceal inappropriate data handling.
• Incident response: Security teams cannot investigate or contain activity they cannot observe.

TrustedTech’s research, as relayed by Nolan, adds another uncomfortable data point: 21% of global Shadow AI users said they used such tools because they did not want their organization to see or access their data. Pulse 2.0 presents that figure as an insider-risk concern. Again, without the full methodology, it should not be stretched beyond its evidentiary scope. But it reinforces the need to distinguish between benign experimentation and deliberate attempts to evade enterprise controls.

Blocking alone can make the problem worse​

The predictable security response is to block public AI services through proxy policy, DNS controls, endpoint restrictions, browser management, and firewall rules. Those techniques have a role. A company should not leave obvious data-exfiltration paths entirely open.
But Nolan is right to caution that blocking is not a complete strategy. Employees who derive real value from an unapproved tool may switch to personal devices, cellular networks, personal accounts, pasted screenshots, or less visible services. Executives may simply ask an assistant to do it outside the enterprise environment. The result is a false sense of control paired with weaker visibility.
The better goal is not unrestricted use. It is a controlled migration from informal AI behavior to a sanctioned AI operating model. That model must give people a credible route to accomplish their work without resorting to unauthorized tools.

---

Why Microsoft 365 Copilot Is an Important, but Incomplete, Answer​

Nolan points to Microsoft Copilot as an example of a sanctioned AI environment that can reduce the incentive for Shadow AI. That proposition has merit for organizations already invested in Microsoft 365, but it demands careful technical interpretation.
Microsoft states that Microsoft 365 Copilot operates within the Microsoft 365 service boundary and respects the organization’s existing data protection, access control, privacy, and compliance capabilities. Microsoft’s Copilot data-protection architecture documentation also says Copilot interaction data can be discovered, audited, and retained using Microsoft Purview capabilities.
Microsoft further states that prompts, responses, and data accessed through Microsoft Graph are not used to train foundation large language models for Microsoft 365 Copilot. Microsoft’s privacy and security documentation explains that Copilot uses Microsoft Graph to ground responses in organizational content, while adhering to existing user permissions. Microsoft’s technical architecture guidance similarly says Copilot does not access data the individual user is not authorized to view. Microsoft’s Copilot architecture overview details that permission-based model.
Those properties make Microsoft 365 Copilot categorically different from an employee casually pasting work content into a consumer-facing AI account. It can operate under enterprise contractual terms, organizational identity, audit capabilities, retention settings, and existing access boundaries.

Existing permissions are the opportunity—and the warning​

There is, however, an important caveat. Copilot honors existing permissions; it does not repair poor permissions.
If broad SharePoint sharing, stale group membership, unlabeled data, inherited access, or exposed OneDrive content already create oversharing, Copilot can make that content easier for appropriately entitled users to discover and synthesize. This is not a Copilot flaw in isolation. It is a reflection of the tenant’s existing information-governance state.
Microsoft’s documentation is explicit that Copilot surfaces only data users are permitted to access, and that organizations should use Microsoft 365 permission models to ensure that users and groups have appropriate access. Microsoft’s Copilot privacy guidance points to the need for correct permission architecture, including how external access is managed. The practical translation is simple: a Copilot deployment is also a data-governance project.
That is where TrustedTech’s combined licensing, cloud, and security framing becomes sensible. A successful deployment needs more than a purchase order. It may require:

• A review of SharePoint, Teams, OneDrive, and Exchange permissions.
• Identification and remediation of overshared sites and folders.
• Microsoft Purview sensitivity labels and retention policies aligned to business requirements.
• Data loss prevention rules designed around realistic prompt and file-sharing patterns.
• Conditional Access and multifactor authentication enforcement.
• Clear rules for web grounding, plugins, connectors, agents, and third-party integrations.
• User education that explains what is allowed, what is restricted, and why.

Microsoft notes that Copilot prompts, responses, and referenced content can produce audit records, while interaction data can support eDiscovery and retention workflows through Purview. Microsoft’s data-protection architecture guidance makes those governance capabilities a major differentiator from opaque consumer AI use. Yet auditability is only helpful if an organization has assigned people, processes, and escalation paths to review and act on what the logs reveal.

---

Rebuilding AI Governance Around Behavior, Not Just Policy​

The governance response described by Nolan aligns well with the structure of the NIST AI Risk Management Framework. NIST organizes AI risk activities around four functions: Govern, Map, Measure, and Manage, with governance designed as a cross-cutting activity rather than a one-time compliance checkpoint. NIST’s AI RMF Core emphasizes that these activities should be continuous throughout the AI lifecycle.
For enterprise IT leaders, that offers a useful practical model.

Govern: establish visible executive ownership​

An AI policy that exempts senior leaders in practice—even if not on paper—has already failed. The policy must state that requirements apply to all roles, including board-facing, finance, legal, HR, and executive functions.
Governance should identify:

• Approved AI services and approved tenant configurations.
• Data categories prohibited from external AI tools.
• Requirements for vendors, connectors, agents, and browser extensions.
• Ownership for exceptions and risk acceptance.
• Training expectations for employees, managers, and executives.
• Incident reporting and investigation procedures.
• The review cadence for AI tools and policies.

The most important point is cultural: executives should be early adopters of sanctioned tools, not privileged users of unsanctioned ones. Their visible participation makes the policy operationally credible.

Map: discover the real AI estate​

Before imposing a broad restriction, organizations need to understand what is already happening. Nolan recommends beginning with visibility into what tools are used, by whom, and for which tasks. Pulse 2.0’s interview argues that many organizations lack this infrastructure.
Discovery should cover more than approved enterprise applications. IT and security teams should look for:

• Browser-based consumer AI services.
• Unsanctioned browser extensions and plug-ins.
• Personal-account logins on managed devices.
• AI functionality embedded in SaaS applications.
• Shadow automation built through no-code platforms.
• External AI agents with access to cloud repositories.
• File-sharing and clipboard patterns that may signal sensitive-data movement.

This is not about building a surveillance culture. It is about identifying where business data is going and whether the organization can meet its obligations once it leaves controlled systems.

Measure: assess usefulness and risk together​

Security teams often measure only exposure. Business leaders often measure only productivity. Both measurements are incomplete.
A useful AI governance program should assess:

• The business value users obtain from a tool.
• The type and sensitivity of data used with it.
• The tool’s terms, training practices, residency, retention, and access controls.
• Whether an approved alternative exists.
• The impact of blocking the tool.
• The technical capability to monitor, audit, retain, and investigate its use.

This dual measurement avoids a simplistic “yes or no” approval process. A marketing team’s low-risk ideation use is different from an executive finance team analyzing nonpublic revenue projections. Both may need AI, but they need different technical controls and approval paths.

Manage: replace unsafe convenience with secure convenience​

The final function is where organizations either gain trust or drive behavior underground. If users must choose between an approved tool that is slow, inaccessible, poorly configured, or unfamiliar and an external tool that solves the task in seconds, the policy will lose.
TrustedTech’s research, according to Nolan, found that 46% of U.S. respondents said their organization lacked adequate training on secure AI use, while 41% said they lacked clear workplace guidance. Pulse 2.0 also reports that 36% of employees primarily teach themselves AI skills, compared with 23% receiving formal employer training. The precise figures require the same methodological caution as other vendor research, but the underlying operational point is sound: self-directed experimentation fills the gap when employers fail to provide practical enablement.
Training must therefore be role-specific. A generic annual security module is not enough for an executive handling board materials, a developer using code-generation tools, a finance team building models, a legal team reviewing contracts, or a Windows administrator using AI to troubleshoot PowerShell, Intune, Azure, and endpoint issues.

---

A Practical First-90-Days Response to Shadow AI​

Organizations that discover widespread unapproved AI use should avoid panic, perform disciplined triage, and establish a credible path toward secure adoption.

Days 1–30: create visibility and stop the highest-risk behavior​

Start by identifying tools, accounts, integrations, data flows, and high-risk user groups. Focus immediately on obvious red flags: sensitive regulated data in public AI tools, unauthorized connectors to corporate repositories, unmanaged agent access, or employees using personal accounts for business content.
At the same time, communicate a short interim policy. It should plainly state what cannot be entered into external AI services, who can approve exceptions, and which sanctioned tools users should employ instead.

Days 31–60: establish governance and deploy workable alternatives​

Create an AI steering group that includes security, IT, compliance, legal, privacy, HR, procurement, and business leadership. Critically, include an executive sponsor whose own use of AI is inside the policy scope.
For Microsoft-centric enterprises, this is the period to validate readiness for Microsoft 365 Copilot or Copilot Chat. Review identity, access permissions, Purview configurations, retention, audit, data classification, third-party integrations, and user access to sensitive sites before scaling licenses broadly.

Days 61–90: train by role, monitor outcomes, and revise​

Move from policy announcement to workplace practice. Teach employees how to recognize approved environments, protect sensitive data, use prompts responsibly, validate generated output, and escalate unclear cases.
Then measure whether the sanctioned tools are actually solving the tasks that drove people to Shadow AI. If the answer is no, governance has uncovered a usability or capability gap that leadership must address. Secure AI adoption succeeds when users see the approved route as the fastest professional option—not merely the least punishable one.

---

The Larger Lesson for Windows and Microsoft Environments​

TrustedTech’s interview with Andy Nolan lands at a moment when enterprise AI governance is becoming inseparable from ordinary Microsoft administration. Windows endpoint management, Intune policies, browser configuration, identity controls, Microsoft 365 permissions, Azure architecture, Purview compliance, and licensing are no longer adjacent topics. They define the boundaries within which AI can be used safely.
The company’s differentiated proposition—joining licensing, implementation, cloud modernization, security, and AI readiness—has clear appeal for organizations trying to reduce vendor fragmentation. Its Microsoft partner credentials and broad service catalog offer evidence of a mature Microsoft-focused practice. At the same time, buyers should scrutinize operational details, insist on measurable readiness work, and avoid assuming that a product deployment automatically equals governance maturity.
The key contribution of Nolan’s argument is its challenge to the usual hierarchy of blame. Shadow AI is not solved by policing employees while executives retain informal exceptions. It is solved by giving every role, from frontline worker to boardroom leader, the same combination of approved capability, clear accountability, technical visibility, and practical training.
That standard is demanding. It requires leaders to model the controls they expect others to follow, IT teams to understand actual user needs, and organizations to treat data governance as a prerequisite for AI productivity. But it is also the only standard likely to turn enterprise AI from an unmanaged shortcut into a durable business capability.

---

References​

1. Primary source: Pulse 2.0
   Published: 2026-07-27T21:37:34+00:00
   
   

   TrustedTech: Interview With VP Of Technology Andy Nolan About Shadow AI And Enterprise Governance

   TrustedTech operates across licensing, cloud solutions, professional services, and security, helping organizations build a cohesive technology strategy that connects licensing decisions with cloud infrastructure, security posture, and AI readiness. Pulse 2.0 interviewed their VP of Technology...

   pulse2.com