TL;DR
AI tool adoption is happening in every function across the enterprise, largely outside procurement and IT visibility, at a pace that formal governance processes were not designed to match.
AI tools are software with Trust Chain dependencies: the same package registries and artifact types that Q1 2026 campaigns targeted are what LangChain, LlamaIndex, CrewAI, and MCP connector ecosystems pull from.
Blast Radius scales with access: for example, finance AI tools touch financial data, while engineering tools touch code and credentials. A compromised tool inherits the access of the team that installed it.
Teams are using AI coding assistants to build tools that never enter vendor or IT review, carry the same Trust Chain dependencies as any third-party software, and feed off the same package registries that saw 454,600 new malicious packages in 2025 alone.
The architectural answer is Communication Governance: governing what AI workloads can reach across the enterprise, not just whether someone approved the installation.
CISOs have two AI problems right now. Most are focused on one.
The first is AI tool adoption. It comes in two forms:
Known AI tools, the ones that went through some version of a review process, are being fast-tracked into production faster than governance frameworks were designed to handle.
Shadow AI tools, the ones that didn’t go through any process, are running in every business function: the finance team’s ERP-connected model, the HR summarization layer, the marketing research assistant with access to internal document stores, the legal contract review tool. They arrived via Slack recommendations, GitHub links, and community-distributed integrations. The CISO knows about some of them. Not all of them.
The second problem is harder and less visible. Teams across the organization are using AI coding assistants to build their own tools. A detection engineer builds a triage interface wired into the SIEM in an afternoon; a finance analyst uses AI to automate variance reporting in an hour; an operations team builds an internal workflow tool because the approved software didn’t solve their problem.
These tools are almost entirely unregulated. They never enter the vendor review process because they aren’t third-party software, they’re “ours.” There’s no procurement trail, security questionnaire, or review board. Most CISOs have no inventory of them at all.
IBM’s 2025 Cost of a Data Breach Report put a number on it: 1 in 5 organizations experienced a security incident tied to shadow AI. Those incidents cost $670,000 more to contain than standard ones. 97% of those organizations lacked AI access controls.
Attackers are already moving on it. CrowdStrike’s 2026 Global Threat Report documented adversaries exploiting legitimate GenAI tools at more than 90 organizations in 2025, injecting malicious prompts to steal credentials and cryptocurrency. The governance conversation is happening in boardrooms, but the exploitation is happening in production.
They don’t need to be malicious to become your next incident; they just need to run.
The Procurement Process Lost While AI Tool Adoption Won
The productivity math wins every time, and IT usually finds out afterward.
A finance team member sees a demo of an AI model that queries their ERP in natural language and builds variance reports in minutes. IT is skeptical. The tool is too useful to wait on. It gets installed in a development environment, proves itself, and migrates to production access within a month. An engineering team adopts an AI coding assistant with MCP connectors into their version control system, CI/CD pipeline, and issue tracker. Each connector arrived as a community-published integration, reviewed by no one in the security organization.
There was no malice or recklessness at any step: just teams operating under resource pressure, finding tools that work, and making the rational call that a 90-day procurement timeline is not a viable answer to a productivity problem they have today. The compliance policy describes Shadow AI as an employee using a consumer chatbot to summarize emails. What’s actually running in the environment is AI agents with persistent access to production systems, built on dependency graphs nobody in IT has reviewed.
The CFO is already asking about it too. EY analysis puts token consumption for agentic AI systems at 30x a simple 2023 workflow. Uber gave 5,000 engineers access to an AI coding tool in December 2025 and had burned through its entire annual AI budget by April 2026. Ungoverned AI adoption creates financial exposure alongside security exposure, and both scale with access.
AI Tools Carry Bigger Risk Than Other Shadow IT
When an employee installs an unapproved file-sharing app, the risk has a natural ceiling: one person’s files. The damage, if something goes wrong, reflects what one individual can access.
AI tools break that ceiling differently.
One dimension is access scope. Useful AI tools require production access, not as a design flaw, but as the definition of useful. A tool that can’t reach your data can’t do the job. That access is what creates value, and it’s exactly what creates Blast Radius when something in the tool’s Trust Chain goes wrong.
The other is output authority. An AI tool isn’t just reading data. In most deployments, it’s generating outputs that affect decisions: financial reports, candidate evaluations, code commits, contract interpretations, investigation summaries. In agentic deployments, it’s taking actions. The risk doesn’t stay inside the tool. It propagates through everything the tool’s output touches.
This is why the Q1 2026 Trust Chain campaign pattern maps directly onto enterprise AI tooling. As our Threat Research Center documented across that series, the campaigns consistently targeted software with two characteristics: high access scope and low scrutiny. Developer tools, CI/CD integrations, package manager plugins. Categories where the software was trusted and the dependency tree wasn’t reviewed. Enterprise AI tools fit that profile in every function.
In May 2026, that pattern reached two named targets. Two OpenAI employee devices were compromised via a poisoned TanStack npm package, exfiltrating code-signing certificates for OpenAI’s consumer apps. One week later, a trojanized update to a widely-trusted VS Code extension traced back to that same Trust Chain event and exfiltrated 3,800 of GitHub’s internal repositories. The path ran through tools developers use every day.
An engineering team’s AI tooling with access to source code and CI/CD credentials sits at one end of that spectrum. A security team’s AI tooling sits at the highest-stakes end.
Security teams are among the most active AI tool builders in the enterprise, not just adopters: detection engineers building LLM-powered triage interfaces wired directly into SIEM query layers, incident responders using AI agents to surface investigation relationships that would take hours to map manually. The productivity case is real. The Trust Chain exposure is identical to every other team, and the consequences are uniquely high. A compromised tool in that environment can not only exfiltrate data, but affect what the organization sees, what it responds to, and in agentic deployments, what actions it takes.
Homegrown AI Tools Skip the One Process That Would Have Caught Them
Third-party software has a paper trail. A vendor goes through procurement. Someone fills out a security questionnaire. There is a SOC 2 to review, a review board to satisfy, an approval to obtain before the tool touches production data.
Homegrown tools built with AI coding assistants skip that process entirely because the process was never designed for software your own team wrote. Gartner’s 2025 research found that 41% of all employees now qualify as “business technologists”: workers outside IT who build technology for their own teams. CISA’s May 2026 agentic AI guidance calls them “shadow agents”: unmonitored back doors with aggregated permissions across every system they touch.
An analyst identifies a gap in their workflow. They use an AI coding assistant to build a solution in an afternoon. It works and gets shared. Within a week, it has access to production systems – not because anyone approved it, but because the person who built it had that access and the tool needed it to be useful.
The Trust Chain exposure is identical to a third-party tool. The AI coding assistant that built it pulled packages from PyPI and npm. The LLM framework it was built on carries its own transitive dependency tree. If MCP connectors were used to wire it into production systems, those connectors are Trust Chain artifacts too. The fact that a team member wrote the application layer doesn’t change what the dependencies underneath it do.
Shadow adoption of a third-party tool might surface in DNS traffic or billing records. A homegrown tool built by someone with legitimate access to every system it touches leaves almost no signal. The only way to find it is to ask what is communicating with what, persistently, at the network layer.
The Trust Chain Problem Is Inside the Tool
The risk is not just that unreviewed AI tools are running in the environment, adopted or built, but what’s inside them.
AI coding assistants have dramatically lowered the barrier to building and publishing software, and package publication to PyPI and npm has been accelerating faster than anyone can audit. Sonatype’s 2026 State of the Software Supply Chain Report counted 454,600 new malicious packages in 2025 alone, a 188% surge compared to the same period in 2024, with over 99% appearing on npm. Review capacity, both automated and human, has not kept pace. Automated scanning catches obvious payloads. It does not catch the Trust Chain attack pattern that succeeded in 2026: a legitimate package at publication that changes behavior later, via an update or a dependency substitution, after it has been pulled into environments that trust it. The Q1 2026 campaigns targeted exactly that second tier: tooling practitioners trust because peers recommended it, it works, and nobody audits it.
The Q1 Trust Chain campaign pattern does not require compromising the end-user tool directly. It requires one package in the dependency graph, resolved and executed in an environment with elevated access. On a developer’s laptop, that access reaches source code and build credentials. In a finance analyst’s environment, it reaches ERP data and financial models. In a security analyst’s environment, it reaches operational telemetry and active investigation context. The attack scales with the environment it lands in.
The LLM is the front end. The Trust Chain exposure is in the infrastructure underneath it: the Python packages, the MCP connector definitions loaded at startup, the external configuration endpoints the tool calls during initialization. These are the same artifact categories that the Q1 2026 campaigns targeted in developer tooling. Enterprise AI tools are developer tooling running at every access level in the organization, built faster than ever, reviewed less than ever.
4 Questions for Your Next Security Review
If a Trust Chain compromise hit your three most-used AI tools today, would you know what each of them could reach? Most CISOs would have to admit the answer is no. The tools that went through IT are the ones you know about. The Blast Radius exposure lives in the rest: the GitHub projects, the community-shared MCP connectors, the LLM interfaces that never appeared in a vendor review.
Is your governance framework keeping pace with how AI tools are actually being adopted, and are those controls applied consistently? Procurement approval is a one-time gate. It doesn’t keep pace with community adoption timelines, and it doesn’t cover what a tool can communicate with after it’s been running for six months. A 90-day review cycle produces a gap between approved and deployed that grows every quarter, and tools that passed review last year may have a different set of reachable systems today. The real question is whether Communication Governance is applied persistently at the network layer across all AI workloads, not just the ones IT managed.
When an AI tool is compromised in a team environment, what is the Blast Radius, and is it bounded? This is the architectural question, not the procurement question. A compromised tool with ungoverned access to production systems has a Blast Radius that reflects the team’s full access scope. Communication Governance bounds that Blast Radius at the network layer regardless of how the compromise occurred.
Does your security review process cover tools your own teams build, and does anyone own them when they become load-bearing? A tool built internally using an AI coding assistant is “ours,” which means it doesn’t trigger a vendor questionnaire, procurement workflow, or review board. But it carries the same Trust Chain dependencies as any third-party tool: PyPI packages, LLM framework dependencies, MCP connectors wired into production systems. And when it becomes load-bearing, nobody owns it: no SLA, no runbook, no vendor to call when the underlying model changes or the API goes down. If your process only catches what comes through procurement, it isn’t catching the security exposure or the operational dependency.
Bottom Line
Every team in the enterprise has AI tools, and most of them are building more. The adopted tools largely bypassed procurement. The homegrown tools never had a procurement process to bypass. Both carry Trust Chain dependencies. Neither is governed at the architectural layer. The Blast Radius scales with access, and right now access is everywhere.
The organizations not in this situation have one thing in common: they extended Communication Governance to AI workloads across all teams, not just IT-managed deployments. Not just approval gates at installation. Persistent, network-layer governance of what AI workloads can communicate with, applied consistently whether the tool was adopted by finance, engineering, HR, or security. In the Containment Era, the question is what that tool can reach if its Trust Chain is compromised. Those are different questions, and the second one requires architecture, not policy.
Start with a current picture of your workload communication paths: the Workload Attack Path Assessment is free and gives you the visibility to see what your AI tools can actually reach across the organization. For ongoing Trust Chain campaign coverage and AI tooling risk research, the Aviatrix Threat Research Center tracks the full series.
Ready to see Aviatrix in action?
Get a personalized live demo walkthrough or explore our latest deep-dive cloud threat research intelligence.
Gartner Strategic Roadmap for Zero Trust Security Programs 2025 Report
Download and gain actionable insights to advance your cloud security strategy.
