Was That AI Plugin Ever Scanned Before You Installed It?

Someone on your team installed an AI skill or plugin six months ago. It still runs today. Do you know who approved it, what data it can touch, or whether anyone ever checked it for malicious code? For most businesses, the honest answer is no — and until very recently, there was no vendor-side mechanism that would have caught a problem even if you had asked.

Direct answer: Anthropic's Claude release notes confirm that automatic security scanning for third-party skills and plugins only became available to Enterprise customers on August 6, 2026. Anything installed before that date, on Claude or on any comparable AI platform, ran without that check. The operational question for every business is not whether your AI tool is secure today — it is what got installed into it before anyone was checking, who installed it, and whether it is still running.

What Did Anthropic Actually Announce?

According to Anthropic's own release notes, the entry dated August 6, 2026 states plainly: "Enterprise plans can now turn on skill and plugin security scanning to automatically check third-party skills and plugins for malicious content when someone uploads or edits them." It is labeled a beta feature, scoped to Enterprise plans, and triggered specifically at the moment of upload or edit.

Read that carefully and the framing flips. This is not a story about a vendor adding a nice-to-have control. It is an admission, straight from the primary source, that the scanning did not exist before. Every third-party skill and plugin uploaded to Claude prior to that date, on a plan without this feature turned on, went in unchecked by Anthropic's own systems. The vendor is telling you, in its own release notes, when the checking started. That means you now have a firm date to work backward from in your own environment.

Why Doesn't a New Scanner Just Fix the Problem?

A scanner examines what gets uploaded from the moment it is switched on. It does not retroactively examine what a team member already installed last quarter, and it does not tell you whether that plugin still has the permissions it was granted on day one. Turning on a new gate does not audit what already walked through the old one. That gap — between when a control appears and when someone actually goes back and checks what predates it — is exactly where operational exposure hides, and it is not unique to Anthropic.

The same structural gap exists in every AI agent and plugin marketplace: Microsoft's Copilot ecosystem, the various GPT and agent stores, the growing catalog of Model Context Protocol (MCP) connectors, and browser-based AI extensions. Each of these platforms is maturing its governance controls in real time, which is a good thing. But maturing controls is a different claim than having always had them. If your organization adopted any of these tools early, the safest assumption is that whatever got installed in the early period was never vetted by anything more rigorous than a store listing and a click.

Why Is an AI Plugin Different From a Browser Extension?

This is the part most leaders underestimate, and it is worth being precise about. A browser add-on generally runs inside the browser's sandbox and asks for a defined, visible set of permissions — read this tab, access this data. An AI skill or plugin is different: it typically inherits the permissions of the account that installed it, which means it can act with the same reach the user has into mail, files, calendars, CRM records, and any other connected system.

That is functionally closer to an OAuth application grant than a browser add-on. When you approve an OAuth connection, you are not approving a static piece of code — you are approving a standing relationship where that application can act on your behalf, continuously, until someone revokes it. An AI plugin with delegated access works the same way. Microsoft's own documentation on Copilot describes this model directly: extensions and agents only surface data the signed-in user already has permission to access, which sounds reassuring until you remember that most employees have far broader access than their job actually requires. The plugin does not need to be malicious to be a problem. It only needs to be running with more reach than anyone is tracking.

The Open Web Application Security Project's current guidance on large language model applications names this directly as one of the two fastest-rising risks in its field: excessive agency, where an LLM-based system is granted broader functionality, permissions, or autonomy than its task requires, alongside supply chain vulnerabilities from compromised or unvetted third-party components. Those two risks are not separate problems in a plugin. They are the same problem: a piece of external code, with delegated access, that nobody re-evaluates once it is installed.

What Does This Look Like Across a Typical Organization?

I have spent two decades in IT service management watching this exact pattern play out with every prior wave of software — browser toolbars, unsanctioned SaaS trials, personal Dropbox folders syncing corporate files. AI plugins are the newest version of the same operational gap, just with more access and less visibility. The table below is the comparison I actually walk clients through when we start an AI exposure review.

What Should a Business Actually Do About It?

The fix is not a new tool. It is a discipline your operations function should already be running for every other category of software, applied to AI. Start with a real inventory: every AI skill, plugin, connector, and browser extension currently active across your accounts, not just the ones IT remembers approving. The NIST AI Risk Management Framework's playbook is explicit that organizations should have policies addressing third-party AI components across the full product lifecycle, not only at the point of adoption — which means the inventory has to look backward, not just forward.

From there, require approval before installation rather than discovering it after the fact, and scope every plugin's permissions to the minimum it needs to do its job. CISA's secure-by-demand guidance for software buyers makes the same point about vendor relationships generally: customers should evaluate a manufacturer's security practices as part of procurement, not assume them. Assign a named owner for the AI plugin inventory and put a review cadence on the calendar — quarterly at minimum, and immediately after any vendor announces a new control, because that announcement is your signal to go check what predates it.

This is the same posture Securafy builds into every client environment by default: nothing runs, connects, or executes until it has been evaluated, because default-deny and Zero Trust mean unknown code does not get the benefit of the doubt. That is a harder discipline to retrofit onto AI tools than to build in from the start, but it is the only version of "AI security" that actually holds up when a vendor's own release notes are the thing revealing the gap.

Why Does the Contrarian Case Matter Here?

Most AI governance budget and attention goes toward policing what employees type into AI tools — the prompt hygiene conversation, the "don't paste customer data into ChatGPT" training. That is worth doing, and Securafy has written about how employees can safely use ChatGPT, Copilot, and similar tools at work. But it addresses the visible risk, not the higher-severity one.

A plugin does not need anyone to paste anything. It persists after installation, runs with delegated permissions, and touches data continuously in the background, whether or not a human is actively using it that day. A risky prompt is a single event you can catch in a log. An over-permissioned plugin is a standing condition that quietly holds access until someone notices, revokes it, or it is exploited. That asymmetry — one-time visible act versus continuous invisible access — is why installed extensions deserve at least as much governance attention as what people type, and in most environments I have reviewed, they get far less.

How Does This Connect to Broader AI Governance?

None of this is really about Anthropic specifically. It is about what a single vendor's release note reveals about an entire category of tools that businesses have been adopting faster than they have been governing. Securafy's main blog has covered why AI adoption for SMBs is fundamentally a governance problem, not a technology one, and why AI without governance is risk, not innovation. A plugin inventory is one of the most concrete, checkable pieces of that governance — you can point to it, audit it, and prove it exists, which is more than most businesses can currently say about the AI skills quietly running inside their tools.

If you want the deeper mechanics of how this plays out inside Microsoft's ecosystem specifically, we have also covered how to safeguard sensitive data in Microsoft Copilot for SMBs and how to secure Copilot and AI agents before they become shadow IT — both of which start from the same premise: you cannot govern what you have not inventoried.

Where To Go From Here

A vendor's new scanner is a good development, but it should prompt a question inward, not relief outward: what did your organization install before anyone was checking, and is it still running? That is an inventory and process gap, and it is fixable starting this week.

If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.

If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.