Clarion Street

Shadow AI Is Now Hiding Inside the Tools You Approved

·8 min read

Shadow AI used to be a single legible thing: an employee pasting company data into a chatbot IT never approved. The fix was legible too. Block the domain, run the awareness training, ask everyone to stop.

That definition is now too narrow in two directions, and the directions are not the same kind of problem. The first is scale. WalkMe’s fifth State of Digital Adoption asked 3,750 leaders and workers at enterprises of 1,000 or more across 14 countries. At least 45% said they had used an unsanctioned AI tool in the prior 30 days, and 36% said they had done so while handling confidential data. Only 21% had ever been warned about their employer’s AI policies, and 34% did not know which tools their employer had approved. I read those as one finding rather than four. The adoption and the ignorance are the same event. People are reaching for tools outside the perimeter, and the perimeter is not telling them where it is.

The behavior is not malice. QA’s research found 13% of professionals are confident using AI for basic tasks, 32% have had no formal training, and 9% call themselves advanced users. People bypass sanctioned tools that are hard to use or do not fit their workflow. WalkMe’s CIO puts the fix as enablement and knowledge transfer: give people a sanctioned tool with 80% of the value and most of them will use it. Blanket bans have a known failure mode. They do not eliminate usage; they eliminate visibility, and users migrate to personal devices and consumer accounts that are harder to see, as the awareness vendor Adaptive Security describes. Samsung’s engineers pasted source code into ChatGPT out of efficiency, not malice, which is the same source’s example.

The shadow moved inside the approved tool

The second direction is the one I want to write about, because it changes the unit of governance. The tools people reach for are no longer just chatbots. Claude Code, OpenAI Codex, GitHub Copilot, and Claude Cowork are now extensible runtimes. Skills, plugins, hooks, repository instruction files, and MCP servers change what the agent reads, which tools it selects, what it runs, and where data goes. Approving the application no longer tells you what is installed inside it. A governance program that stops at approving the agent cannot tell you whether a developer later installed a skill that reads the repo and ships its contents somewhere.

There is a line from a vendor piece that I keep turning over: “The application is visible. The effective capability set is not.” The author is the CEO of Akto, a company that sells agentic AI security, and The Hacker News labels the piece a contributed partner article. I treat the thesis as expert opinion, not neutral reporting. The security concern underneath it is real, but what establishes that concern is the OWASP attack data, not Akto’s framing. That formulation, the agent’s effective authority, is Akto’s, and I use it below only as an attributed vendor observation.

OWASP’s Agentic Skills Top 10, version 1.0–2026 and updated in March 2026, documents the skill supply chain under active attack. OWASP is still soliciting public review of the v1 draft, which is worth keeping in mind when you cite the numbers below. Its headline numbers: 3,984 skills scanned, 36.8% with security flaws, 13.4% with critical issues, and 76 or more confirmed malicious payloads. The top two risks are Malicious Skills and Supply Chain Compromise, and its incident timeline runs from January 2026. The ClawHavoc campaign registered 341 malicious skills in three days, and the broader campaign totals 1,184 per Antiy CERT. ClawHub became the first AI agent registry to be systematically poisoned at scale. Check Point published two Claude Code CVEs, CVE-2025-59536 and CVE-2026-21852, showing repository configuration files now function as part of the execution layer. I have written about skills as a runtime layer from the other side in The Hidden Bloat in AI Agent Runtimes. That post was about what the agent ships to your disk. This one is about what the agent is allowed to do once the skills are installed.

Two definitions, converging

Here is the part I want to get right, because it is easy to blur. Two definitions of shadow AI are in play. The consumer-tool definition is the one the WalkMe survey and the SOC 2 audit firms use. The skill-supply-chain definition is the one Akto and OWASP use. The interesting thing is not that both exist. It is that they are converging. A developer who pastes a company spec into an unapproved chatbot and a developer who installs an unvetted skill into an approved agent are doing the same thing with different verbs: reaching for capability outside the controls, out of convenience. The unit of governance has to move from the AI application to the agent’s effective authority. That is Akto’s phrase, and it is the right one.

This is also the human-facing version of something I have written about from the machine side. The rogue-agent posts covered agents acting on their own, breaking out of test environments and reaching real systems. I covered those in The Rise of the ‘Agentic Virus’ and the accountability gap they leave in Who Investigates the Machine. This post is the other actor: people quietly reaching for tools outside governance. The root cause is the same, the capability outran the controls, but the actor is an employee rather than an agent, and the fix is different in kind. You cannot contain a person the way you sandbox a process.

The compliance consequence

The compliance consequence follows, and I will keep it short because I have made most of this argument here before. SOC 2 auditors flag shadow AI as a multi-control failure. Logical access (CC6) breaks when employees OAuth an external AI service into internal systems. Detection (CC7.1) breaks when AI traffic rides standard HTTPS past monitoring. Vendor risk (CC9.1) breaks when an AI provider gets onboarded outside vendor management with no DPA or security assessment.

The deeper point I have argued on this site is that point-in-time attestation cannot certify software that decides its own tool calls at runtime. I made that case in Auditing the Unpredictable and sharpened it in Certifying the Loop. Shadow AI adds one concrete inventory item to that argument. The thing you now need to attest to is not only the model. It is the skills, plugins, and MCP servers inside the agent, an asset that changes after approval. CMMC’s point-in-time model is the wrong shape for that, and I have covered the current state of that regime here.

Observe first, block later

The response pattern is the part that gives me some optimism, and it is a leadership story more than a security one. Thomson Reuters started by tracking AI rather than blocking it, on the reasoning that blocking would push users toward worse behavior like moving data to personal devices. Its COO described the early approach as “we just tracked AI. We didn’t stop it”. Chase refused the shadow framing entirely and embedded controls in an internal agentic platform. Gill Haus put it plainly: “Everything goes through our trusted secure pipeline, meaning there isn’t a shadow.” WalkMe’s CIO distilled the balance: an unrestricted toolset is horrible for the CISO, and a fully locked-down toolset is horrible for the employee.

I have mixed feelings about the Chase answer, and I want to be honest about why. Giving everyone a sanctioned sandbox is the cleanest version of the fix, but it assumes you can build a sandbox that keeps up with the capability people actually want. Most firms cannot. The Thomson Reuters version is more honest about the starting point: watch first, then route people into the governed path as it gets good enough.

The practical playbook is the same whether you are worried about the human version or the skill version. For the human side, a three-tier model of approved, limited-use, and prohibited tools, plus CASB or SWG monitoring, OAuth grant audits, browser-extension allowlisting, DLP on AI endpoints, and anonymous usage surveys, the checklist a SOC 2 auditor would run. For the agent side, inventory the full extension layer, review plugins as dependency graphs rather than marketplace listings, and re-evaluate behavior on every update. OWASP is explicit that the goal is not to forbid skills. It is to run them in a secure-by-default environment.

Bottom line

The definition of shadow AI has moved, and the move is the news. It used to mean pasting data into an unapproved chatbot, a problem you could block at the domain level. It now also means installing capabilities inside an approved agent, a problem you can only see if you govern what the agent can actually do. The survey numbers say the human version is already mainstream. The OWASP numbers say the skill version is already under attack. The firms handling both well are the ones that stop trying to block and start observing, then route people into a governed path good enough to keep. Approving the tool was never the whole job, and it has stopped being the hard part.

Sources

  1. Shadow AI Is Now Hiding Inside Sanctioned AI Tools — The Hacker News (contributed piece, August 2026)
  2. 45% of professionals use shadow AI tools — ZDNET
  3. OWASP Flags Top AI Skill Risks, Security Blueprint — Dark Reading (via Wayback Machine, snapshot August 29, 2026)
  4. Just 13% of professionals are confident using AI — ZDNET
  5. WalkMe State of Digital Adoption 2026 press release — WalkMe
  6. OWASP Agentic Skills Top 10 (AST10) — OWASP
  7. Shadow AI and SOC 2: How It Creates Audit Gaps — Linford & Co
  8. Understanding Shadow AI Risks — Adaptive Security