Shadow AI: 21,639 Exposed Agent Instances and the Class of Risk Mid-Market Healthcare Has Not Inventoried

A new exposure surface, with numbers In late January 2026, the security firm Censys ran a pass on a single open-source AI agent platform that had crossed one hundred thousand GitHub stars in roughly three months. The agent was not exotic, a self-hosted assistant that read messages, controlled browsers, executed shell commands, and connected to consumer messaging platforms (WhatsApp, Telegram, Slack, Discord, Signal, iMessage). The Censys count came back at 21,639 publicly exposed instances, instances reachable from the open internet, up from roughly one thousand a few days earlier. The number tracked with a single coordinated disclosure window after a high-severity CVE (one-click remote code execution via crafted link, CVSS 8.8) hit the platform. Around the same window, Snyk audited nearly four thousand skills published to the platform's skill marketplace and reported that 7.1% mishandled secrets through LLM context windows, credentials and API tokens flowing into model prompts where they could be exfiltrated through prompt injection or surfaced through normal model responses. Reuters reported that the project's adjacent social network for AI agents had a database that exposed six thousand owner emails and over a million credentials. Reco classified the category, autonomous agents with shell, persistent memory, and zero enterprise visibility, as a new shadow-AI risk class. The vendor in this case is not the point. The category is. A regulated mid-market buyer who reads this briefing as "an open-source platform had a bad month" misses the structural shift. Shadow AI has graduated from people pasting prompts into a chat tool to autonomous agents installed on workforce-owned hardware, with credentials, with memory, with the ability to act. The risk register most healthcare security teams maintain does not have a row for this class. The next OCR investigation that touches AI is going to ask for the inventory. What changed about shadow AI Shadow AI in 2024 and most of 2025 was a content-leakage problem. A clinician pasted a discharge summary into ChatGPT to clean it up. The DLP tool caught some of it. The IT team blocked some of it. The remediation was awareness training, an acceptable-use policy, and a sanctioned tool the workforce could use instead. Imperfect, but the threat model fit inside the security team's existing surface. The prompts were content. The disclosure was data egress. The control was DLP plus a sanctioned channel. The 2026 shadow-AI surface is structurally different. Two things changed. The first is autonomy. The agent is not chatting with the clinician; it is running on the clinician's machine, holding a credential to the clinician's email, scheduling on the clinician's calendar, calling tools the clinician authorized once and never reviewed again. The blast radius is a function of what the agent can do, not what the clinician asked it to do. The second is exposure. Self-hosted agents commonly bind to localhost by default, but a misconfiguration exposes them to the network in a way that a chat session does not. The 21,639 number is what happens when an agent's default-localhost gate is overridden by a single configuration error and replicated across thousands of instances. The combination is what creates the new risk class. An agent on a clinician's laptop, with shell access, with a persistent memory of patient names and case details, with a misconfigured listener on a public address, with a vulnerable WebSocket origin check, becomes an exfiltration surface that is not detectable by the controls the security team built for the previous shadow-AI threat model. DLP does not see it. The acceptable-use policy does not cover it. The sanctioned tool list does not include it because the workforce installed it last Tuesday. What the audit would ask Run the question forward. A regulated healthcare org sits across a table from an OCR investigator in 2027. The investigator asks: "What AI agents on your network or your workforce's devices have access to PHI, and what is your inventory of them?" The answer the buyer wants to give is a structured list, agents named, identities scoped, BAA chain confirmed, audit-log surface enumerated. The answer most buyers would actually give today is "we use Microsoft Copilot for Office 365." The gap between the two answers is the shadow-AI surface. The investigator's follow-ups are predictable. What is your control over agents the workforce has installed on personal-administered devices? What is your visibility into the messaging-platform integrations those agents have established? Which credentials does each agent hold, and which of those credentials provide access to systems containing PHI? What is your audit-log surface for agent activity, separate from the user activity that initiated it? When the workforce member leaves, what is the deprovisioning process for the agent and its persisted memory? For most mid-market healthcare orgs we audit, the answers do not exist as artifacts. They exist as informal practice, "we don't think we have any", which the audit will not accept as evidence. The question is not whether the workforce has installed shadow agents. We have run inventories. They have. The question is whether the org can produce the structured answer. The minimum inventory artifact We work with mid-market healthcare clients on the Adopt-AI-Safely Diagnostic to produce a four-column shadow-AI inventory artifact. The artifact is the working baseline for governance and the structured answer to the audit's first set of questions. Column one: agent class. Each row names a class of agent the workforce has access to, sanctioned vendor agents (Microsoft Copilot, Abridge, ChatGPT Enterprise), bring-your-own-agent installations (open-source agent platforms, self-hosted assistants), browser-based agents (Perplexity Computer, Cowork, in-browser Claude Code sessions), and developer agents on engineering hardware (Claude Code, Codex, Cursor). Column two: credential and tool surface. For each class, the credentials the agent typically holds, email, calendar, file storage, messaging platforms, EHR, and the tool surface the agent can call. This is the column that produces the immediate findings. A bring-your-own-agent installation that holds an email credential and a messaging-platform credential is an agent with the ability to read PHI from email and forward it through a channel the security team has no audit log for. Column three: audit-log surface. For each class, the audit log the security team can pull on demand. Sanctioned vendor agents typically have a vendor-provided audit log; bring-your-own-agent installations frequently do not, which is itself a finding. Column four: BAA chain status. For each agent class that touches PHI, the BAA chain status, executed, in negotiation, declined, not pursued. A class of agent in column one that has PHI access in column two and "not pursued" in column four is a structural finding. The artifact is short, typically four to eight rows for a mid-market healthcare org, but it is the artifact the audit will ask for. Producing it is the first move; updating it quarterly is the discipline. The orgs that produce it find that the conversation about which agent classes to sanction, which to disallow, and which to provide a sanctioned alternative for becomes concrete instead of abstract. Without the inventory, the conversation is hypothetical, and the audit finds the gaps. What we recommend A mid-market healthcare buyer should treat the Q1 2026 shadow-AI numbers, the 21,639 exposed instances, the 7.1% skill-secret leakage rate, the credential-database exposures, as the leading indicator they were waiting for. The category has compounded. The buyer-side response is straightforward. First: produce the four-column inventory artifact. The artifact is the baseline; without it, every subsequent governance decision is conjecture. Second: extend the existing acceptable-use policy to name the bring-your-own-agent class explicitly, with a clear distinction between sanctioned and unsanctioned categories. Third: surface the inventory in the next risk-register review and the next BAA-chain audit. Fourth: tie the inventory to the trust-architecture audit (covered in the Trust Architecture Field Guide) so that each agent class is mapped to its identity, permission scope, behavioral monitoring, and escalation policy. The exposure surface is no longer hypothetical, and the regulator's first question is no longer years away. The artifact is small. The class of risk is new. Inventory it before the audit asks for it.