Claude Skills Security Scanning: HIPAA and ZDR Gaps in Pharma

Anthropic announced skill and plugin security scanning for Claude Enterprise on August 6, 2026, and its release notes label the feature a beta (^[1]). The scan checks third-party skills and plugins for malicious content when someone uploads or edits them (^[2]), and returns pass, warn, or fail. Most scans finish in about one to two minutes, and results are cached (^[3]). Since October 2, 2026 the control is on by default for Enterprise organizations that had not chosen a setting (^[4]).

The coverage is narrower than the feature name suggests. Anthropic excludes skills and plugins that existed before scanning was enabled (^[5]), skills created with Claude, skills shared through a connected Model Context Protocol (MCP) server, and MCP servers. Organizations using customer-managed encryption keys (CMEK), zero data retention (ZDR), or HIPAA configurations are excluded entirely (^[6]). The scanner article describes hook scanning only for hooks shipped inside a plugin. Anthropic states that a pass "isn't a guarantee" of safety (^[7]), and that scanning will not catch a skill that behaves in unintended ways without being malicious.

The default change interacts with publishing policy. For Enterprise organizations that never chose a publishing setting, "Open" applies where scanning is on, and "Requires review" applies to all others (^[8]). Under "Open", an item that passes the scan is listed without waiting for owner approval. In HIPAA-configured organizations skills are available but not covered under the business associate agreement (BAA) (^[9]), and Anthropic tells administrators to review each skill and plugin themselves because scanning is unavailable.

This report builds a coverage and control-gap model rather than a setup guide. Using a hypothetical 134-artifact inventory, the scanner touches 46 artifacts (34.3%), completed-review coverage with human sign-off is 26.9%, and 65.7% of the inventory sits in classes the scanner does not address. In academic work, the regex prefilter of one purpose-built skill gateway caught 135 of 150 malicious benchmark files, but also had a 27.1% false-positive rate on that benchmark (^[10]), and Anthropic publishes no efficacy benchmark in the pages reviewed. The recommended posture is to enable scanning where it is available as a pre-filter, keep human review as the approval gate, and prohibit or tightly limit skills in HIPAA, ZDR, and CMEK tenants until compensating controls (provenance, allowlists, pinned versions, sandbox tests, egress limits, and runtime monitoring) are evidenced.

Skills are folders of instructions, scripts, and resources that Claude loads on demand (^[11]). Because a skill can contain executable code alongside instructions (^[12]), a skill is closer to a software package than to a document. Anthropic's own guidance says to use skills only from trusted sources, meaning ones a user created or obtained from Anthropic (^[13]) (^[14]), and it warns that a malicious skill can direct Claude to call tools or run code in ways that do not match its stated purpose (^[15]).

For pharma and biotech organizations the stakes are specific. Skills run next to data that may include protected health information (PHI), unpublished research, and records governed by quality systems. The audience for this report is the group that has to decide whether Anthropic's scanner changes the approval process: security architects, Claude Enterprise owners, AI platform teams, privacy officers, research IT, quality partners, and procurement. The question is not whether to scan. It is what the scan covers, what it does not, and what review must fill the gap, especially where the scanner is unavailable.

The report is anchored on three Anthropic Help Center pages accessed on November 10, 2026: the scanner article, the organization provisioning article, and the release notes. Where those pages disagree or are silent, the report says so. For example, the scanner article says an Owner can choose "Allow anyway" for a blocked item, while the organization article says a blocked skill "can't be approved for the organization at this time" (^[16]). Anthropic also notes that the override is rolling out gradually, which is one plausible reconciliation, though the pages do not say so.

The analysis relies on third-party and regulator sources, and product behavior is dated to the November 10, 2026 reading because scope and defaults may change quickly.

What launched on August 6, 2026

The release note for August 6 says Enterprise plans can turn on scanning to check third-party skills and plugins for malicious content at upload or edit. The scanner article specifies the surfaces: Claude, Claude Cowork, and Enterprise plugin marketplaces. Scope includes standalone skills, plugins, and the skills bundled inside a plugin (^[17]). There is no extra charge. Admins can narrow the feature to custom roles, and a custom-role capability governs who is subject to scans (^[18]).

Content handling is documented in two sentences. Contents are processed in an isolated environment kept separate from normal Claude sessions, and the scanned copy is deleted after the scan, leaving only the result and basic metadata (^[19]). The pages reviewed do not say why CMEK, ZDR, and HIPAA organizations are excluded.

The October 2 default change

The scanner article states that scanning is on by default for Enterprise organizations that had not chosen a setting before October 2, 2026. The organization article repeats that the default applies "where available" and that organizations which already chose keep their choice. Two consequences follow for an Enterprise owner who never opened the policy tab. Scanning may now be on without anyone having decided it, and the publishing default has moved with it.

Publishing has three settings. "Requires review" means an owner approves each submission, "Open" publishes without review, and "Off" hides the publish button. For Enterprise plans that had not chosen, Publishing defaults to "Open" where scanning is on and "Requires review" for all others (^[20]). Under "Open", items that users publish go straight to the organization library without owner review, and the organization article marks this as important (^[21]). Where scanning is on, a new item is not listed until it passes the scan, which usually takes a few minutes. The practical reading is that a scanner pass can substitute for a human approval in a default configuration.

Scan semantics: pass, warn, fail

Table 1 below summarizes the three results as documented, and adds a proposed response for a regulated organization. The response column is analyst recommendation, not Anthropic guidance.

Result	Documented behavior	Who can override	Proposed response (analyst recommendation)
Pass	The item installs normally with no extra message ([22]). A pass means the scan did not find one kind of threat, and Anthropic says it is not a guarantee of safety in every respect.	Not applicable	Treat as an input to review, not as approval. Record the scan result in the artifact manifest and continue to provenance, version pinning, and intended-use checks.
Warn	Claude could not fully verify the item ([23]). It stays usable behind a caution banner that users acknowledge.	Users acknowledge the banner. Owners, Primary Owners, and roles with Libraries set to "Can manage" can choose "Allow anyway" where shown.	Block for regulated data classes until a named reviewer completes static and manual review. A warn is an inability to verify, so the burden of proof moves to the reviewer.
Fail	The scan detected malicious content, and the item is blocked ([24]). A failed submission cannot be approved until the author fixes it and resubmits ([25]).	The uploader cannot override. Owners and "Can manage" roles may allow a version, and an unchanged re-upload returns the same result.	Treat as a security event. Do not use "Allow anyway" without a documented exception (see the exception process below). Quarantine the source and preserve the package for analysis.

Two details matter operationally. First, an override applies only to the version it was granted on, and each new version is scanned again (^[26]). Second, results are cached, so re-uploading the same content returns the earlier result almost instantly. Together these mean scan outcomes are tied to content, not to a publisher's reputation, which is a useful property for a fixed-version approval model.

The coverage-gap matrix

Table 2 crosswalks artifact classes against the scan coverage documented in the scanner article. "Not described" means the Anthropic pages reviewed do not address the class, which is different from "excluded". These entries are the analyst's reading of silence in those pages, not documented exclusions.

Artifact class	Upload or delivery path	Scan coverage (per Anthropic)	Review that must fill the gap
Third-party skill uploaded after enablement	Member or owner upload, or edit	Scanned	Provenance check, pinned version, intended-use gate
Third-party plugin, including bundled skills	Upload to org settings or plugin marketplace	Scanned, including bundled skills	Same as above, plus review of any MCP server or hook it declares
Hooks shipped inside a plugin	Plugin package	Scanned	Manual review of every command hook, which run with full user permissions ([27])
Hooks outside a plugin	Managed settings, repository configuration	Not described in the scanner article	Settings review, and restrict non-plugin customization where possible ([28])
Items present before scanning was enabled	Existing library or user uploads	Excluded	Back-scan and re-review as a one-time inventory exercise
Skills created with Claude	Created in a Claude session	Excluded, relies on built-in safeguards	Control through the User-created skills toggle ([29])
Skills delivered through MCP	Connected MCP server	Excluded, follows the MCP trust model	Treat as part of the MCP server review
MCP servers	Connector or local server	Not scanned at this time	Server allowlist, scoped tokens, and sandboxing; Anthropic says it does not security-audit or manage any MCP server ([30])
Any item in a CMEK, ZDR, or HIPAA tenant	Any	Scanning not available	Full manual review under the tenant's change control
Repository-synced marketplaces	GitHub sync into org marketplace	Not described; a sync replaces all plugins with the repo state ([31])	Review the repository, not only the listing

The matrix has an asymmetry worth stating plainly. The classes the scanner covers are the ones with the clearest human chokepoint, an upload or an edit. The classes it excludes are those that arrive without such a chokepoint: items already installed, content generated inside a session, and anything delivered by a server at runtime.

Publishing policy and fixed-version review

The organization article gives reviewers real tools. A reviewer sees who submitted the item, its scan result, every file, and a diff against the published version for updates (^[32]). The reviewed version is fixed: author edits do not reach the organization until a new version is submitted and approved. When an owner approves a new version, everyone using the item gets the update automatically (^[33]). Owners' own submissions skip review.

Update drift is the second half of the version story. A shared skill updates for recipients at next use when the owner saves a new version. Inside Claude Code, plugin auto-update is off by default for third-party marketplaces and on for some official ones (^[34]), and when it is on, the files a user reviewed can change on disk (^[35]). Group scoping is possible by bundling skills into a plugin assigned to a group, but custom-role permissions are additive, so one role cannot remove what another grants (^[36]). Where a member belongs to several groups with different plugin settings, the most permissive setting applies (^[37]).

A usable threat model for skills has five classes, each with a different detection profile.

• Malicious instructions. Natural-language directions that redirect the agent. OWASP notes that it is unclear whether any prevention of prompt injection is fool-proof (^[38]).
• Package and code execution. Bundled scripts and plugin commands. A Claude Code plugin can execute arbitrary code with the user's privileges (^[39]), and command hooks are shell commands that run with the user's full permissions (^[40]).
• Exfiltration. Moving data out. On claude.ai and in Claude Code, skill network access can match any other program on the user's computer (^[41]), while skills on the API run in a container without network access (^[42]).
• Privilege misuse. Using granted access beyond purpose. OWASP's Excessive Agency entry covers extensions "sometimes referred to as tools, skills or plugins" (^[43]) and applies regardless of what causes the model to malfunction (^[44]).
• Unsafe but non-malicious behavior. Anthropic is explicit that a pass does not mean the item will not behave in unintended ways. This class is outside what the scanner is described as checking.

A 2026 taxonomy of agent-skill threats organizes seven categories and nineteen scenarios across three attack layers (^[45]), and attributes the most severe to structural properties such as the absence of a data-instruction boundary and a single-approval persistent trust model (^[46]). The same logic explains why supply-chain controls matter even when a scan passes: dependency change after approval is a documented risk, since even trustworthy skills can be compromised if external dependencies change (^[47]).

What the research says about scanner efficacy

Anthropic does not publish detection-rate benchmarks in the pages reviewed, and this report found no published independent evaluation of Anthropic's scanner. Research on other skill scanners is informative about the category, with the caveat that results do not transfer automatically.

• SkillGate (July 2026) is a screening gateway built as a hybrid regex prefilter plus a large-language-model judge (^[48]), with 530 regex patterns (^[49]). Its prefilter alone caught 135 of 150 malicious benchmark files but also flagged 406 benign ones, a 27.1% false-positive rate the authors call far above deployable constraints (^[10]), and the hybrid design cut LLM input tokens by 77% (^[50]). The authors state that the 150 malicious files are hand-crafted exemplars, not in-the-wild samples (^[51]), that the judge is nondeterministic (^[52]), and that adaptive adversaries are out of scope (^[53]).
• A large-scale static study reported that 26.1% of analyzed skills contain at least one vulnerability (^[54]), with a detector at 86.7% precision and 82.5% recall on a validated sample (^[55]). Its error analysis calls evasion patterns fundamental limits of static and single-pass analysis (^[56]).
• Adversarial evasion work reports that a multimodal attack achieved 78 to 100 percent attack success against every one of six baseline scanners (^[57]), and that splitting intent across several plausible skills reached an average 96.0% success (^[58]).

Read together, these studies support a modest conclusion: scanners reduce exposure to unsophisticated or known patterns, and the literature's own authors position them as one layer. None of this evaluates Anthropic's service, whose methods Anthropic does not describe.

Compensating controls

Each control below is verifiable against a vendor or standards source.

• Provenance. NIST's secure software development framework asks organizations to collect and maintain provenance data for all components of each release (^[59]). SLSA defines provenance as what entity built the artifact, what process they used, and what the inputs were (^[60]), and notes that its lowest level is trivial to bypass or forge (^[61]). OWASP's agentic list adds a mitigation to verify provenance before install or activation and reject unsigned or unverified components (^[62]).
• Allowlists. Claude Code's managed settings decide which marketplace sources plugins may come from (^[63]), applied before anything downloads and again at session start (^[64]). The allowlist does not restrict entries inside an allowed marketplace, and plugin keys apply to every user who receives the settings (^[65]).
• Pinned versions and checksums. A plugin source can be pinned to a full 40-character commit SHA (^[66]), and Claude Code refuses an archive install whose digest does not match (^[67]). GitHub's guidance notes a tag can be moved or deleted (^[68]), and that pinning to a full SHA requires an attacker to produce a SHA-1 collision (^[69]).
• Static and manual review. Cisco's scanner detects prompt injection, data exfiltration, and malicious code patterns (^[70]) using static, behavioral, and language-model analysis (^[71]), and its documentation advises pairing results with manual code review for high-risk deployments (^[72]). HOL's plugin scanner checks security posture such as secrets, action pinning, and lockfiles (^[73]). Snyk's agent-scan sends component information to an analysis API (^[74]), which matters if skill content is confidential.
• Secrets and dependencies. Gitleaks finds secrets in repositories and files (^[75]), TruffleHog can confirm whether a found secret is live (^[76]), and OSV-Scanner finds known vulnerabilities in dependencies (^[77]).
• Sandbox tests. gVisor places a per-sandbox application kernel between the workload and the host (^[78]), and a Docker container with no network driver isolates its networking stack (^[79]).
• Least privilege. OWASP advises limiting the extensions an agent may call to the minimum necessary (^[80]) and requiring human approval for high-impact actions (^[81]). In Claude Code, permission rules are evaluated deny first (^[82]), and no command-line argument can override a managed rule (^[83]). The managed MCP allowlist is a separate setting that other permission flags do not enforce (^[84]).
• Egress controls. The Claude Code sandbox sends network traffic through a proxy that checks each host against allowed domains, which start empty (^[85]). Built-in tools such as WebFetch follow permission rules rather than the sandbox (^[86]), so both layers need configuration.
• Secret isolation. The sandbox's default read access covers most of the machine, including credential files (^[87]), so credentials should not live on hosts where skills run.
• Runtime monitoring and revocation. Anthropic's November 5, 2026 security update describes inference hooks that send prompts and tool calls to a customer's data security tools (^[88]). Skill-sharing events appear in the audit log, but not skill contents (^[89]). OWASP recommends an emergency revocation mechanism that can disable specific tools quickly (^[90]).

A fixed-version provenance manifest ties these together. For every approved artifact, record:

• Identity. Name, type (skill, plugin, hook, MCP server), and publisher of record.
• Source reference. Repository URL, full commit SHA, or archive SHA-256 digest.
• Content inventory. File list with hashes, declared dependencies, and any network endpoints, in a format such as CycloneDX, which describes first-party and third-party components (^[91]).
• Signatures. Sigstore-style signature and transparency-log entry where available (^[92]).
• Scan result. Anthropic scan outcome and date, plus any open-source scanner outputs.
• Human review. Reviewer, date, intended use, data classes permitted, and tools granted.
• Approval scope. Groups, default access (available, installed by default, or required), and expiry date.
• Rollback. The prior approved version and the revocation owner.

The CISA-led 2026 minimum elements for a software bill of materials add component hash, license, tool name, and generation context (^[93]), a convenient checklist for the content inventory.

HIPAA, ZDR, and CMEK control crosswalk

Table 3 crosswalks the three excluded configurations against what Anthropic documents about skills, and the minimum compensating controls proposed here.

Configuration	What Anthropic documents	Skill and plugin status	Minimum compensating controls (analyst proposal)
HIPAA, Enterprise chat	Only a Primary Owner can accept the BAA and enable HIPAA ([94]), and the change cannot be reversed from organization settings.	Skills are available but not covered under the BAA ([9]). Skills and sharing are off by default. Scanning unavailable.	Keep skills off for PHI workflows, or allow only owner-provisioned, human-reviewed, pinned skills. Set Publishing to "Requires review".
HIPAA configuration for Claude Code and Cowork (local mode)	Enabling HIPAA alone does not bring Claude Code or Cowork under the BAA ([95]).	Applying it turns off Cowork, the Code section of Desktop, skills, and Claude in Chrome. Plugins and skills stay outside the BAA even when turned on ([96]).	Treat any re-enabled skill as outside BAA scope. Prohibit PHI in sessions that use skills. Re-enable only for approved, reviewed items.
ZDR	On the API, ZDR means Anthropic does not store prompts or responses at rest ([97]). Claude Code ZDR cannot be enabled from admin settings ([98]).	The API skills feature is not ZDR-eligible and its data follows standard retention ([99]). The Agent Skills overview states it is not covered by ZDR arrangements. ZDR does not extend to third-party tools or MCP servers ([100]).	Do not use skills in ZDR-dependent workflows. If used elsewhere, keep them in a separate organization from ZDR workloads.
CMEK	CMEK on Enterprise encrypts chat content, including skills and plugins ([101]).	Scanning cannot be turned on, and skills and plugins install without a scan ([102]).	Full manual review and allowlisting. Encryption protects stored content, not the behavior of an installed skill.
CMEK plus ZDR	On Claude Enterprise an organization can use both ([103]).	Same exclusions apply.	Combine the controls above.
Standard Enterprise (no excluded configuration)	Standard plans have no BAA coverage until a Primary Owner acts.	Scanning on by default since October 2 for organizations that had not chosen.	Scanner as pre-filter. Publishing "Requires review" for regulated roles.

Two cautions on Table 3. First, the controls column is analytical, not a compliance determination, and any HIPAA conclusion needs the organization's privacy officer and counsel. Second, the HHS Security Rule is technology neutral and does not dictate specific measures (^[104]), but a risk analysis affects every safeguard (^[105]). A HIPAA tenant's risk analysis should therefore name skills and plugins as assets. HHS's proposed Security Rule update would also require a technology asset inventory and a network map of ePHI movement (^[106]), though HHS states the current rule remains in effect while the rulemaking is pending (^[107]).

Pharma data-class and intended-use gates

A skill's permitted use should depend on both the data it touches and the decision it informs. A five-class scheme works for most pharma programs:

• Class 0, public. Any approved skill.
• Class 1, internal non-GxP. Scanner pass plus provenance check.
• Class 2, confidential R&D or commercial. Human review, pinned version, egress allowlist.
• Class 3, PHI or personal data. Only in a tenant under a BAA, with skills excluded from BAA scope treated as prohibited unless the privacy officer accepts a documented risk. HHS notes that de-identified data under either method still retains some risk of identification (^[108]), and Safe Harbor identifiers include device identifiers (^[109]) and any other unique identifying code (^[110]), which can appear in tool logs.
• Class 4, GxP records or regulated decisions. Full intended-use assessment, quality approval, and audit trail.

For Class 4, the established frameworks are risk based and tied to intended use. FDA's computer software assurance guidance, reissued on February 3, 2026, defines assurance as a risk-based approach (^[111]), though its scope is device production and quality-system software, so for drug programs it is an analogy rather than a direct requirement (^[112]). GAMP 5 second edition says the regulated company determines the type and level of assurance by fitness for intended use (^[113]). ICH Q9(R1) states that effort, formality, and documentation should be commensurate with risk (^[114]).

Records rules apply as well. 21 CFR Part 11 requires validation of systems (^[115]), and secure, time-stamped audit trails (^[116]). The European Commission's draft Annex 11 requires quality risk management throughout a computerised system's lifecycle (^[117]) and sets validation effort by intended use and risk (^[118]). Draft Annex 22 states that it does not apply to generative AI and large language models (^[119]), and that for non-critical GMP applications qualified personnel remain responsible for output suitability (^[120]). The consultation closed on October 7, 2025 (^[121]), and this report found no final adoption notice as of the reading date. FDA's draft guidance on AI for regulatory decision-making scales credibility activities to model risk and context of use (^[122]) and excludes AI used only for operational efficiencies such as drafting (^[123]).

The implication: an agent skill that drafts internal text may sit outside these frameworks, while a skill that touches a record or a quality decision must be assessed for intended use and change-controlled. Draft Annex 22 requires change control over the model, the system, and the process (^[124]), which maps onto version pinning and update review for skills.

Pilot and negative-test pack

A pilot should answer two questions: what does the scanner catch in this tenant, and what do the other controls catch when it does not? Use synthetic data, canary secrets, and a non-production organization where possible. Confirm with the Anthropic account team and legal that test samples are permitted before uploading deliberately unsafe test content.

• Prompt injection. A skill whose instructions tell the agent to ignore prior directions and disclose its system context. Expected: scan warn or fail, or runtime refusal. OWASP recommends human-in-the-loop controls for privileged operations (^[125]).
• Data exfiltration. A script that posts a canary file to an unapproved host. Expected: egress proxy block and an alert, since sandbox traffic is checked against allowed domains (^[85]).
• Secret access. A skill that reads a planted fake credential file. Expected: no access, because default read access reaches credential files (^[87]) unless denied.
• Dependency install. A skill that installs an unpinned package at run time. Expected: block, because dependencies can change after review.
• Obfuscation. Encoded payloads, hidden characters, and instructions placed inside images. Research on evasion shows encoding-based false negatives remain.
• Unsafe tool scope. A skill that requests broad tool permissions. Expected: denial under managed deny rules (^[83]).
• Update drift. Approve version one, then push version two to the source. Expected: users remain on the approved version and the new one enters review.
• MCP delivery. A skill delivered through a test MCP server. Expected: not scanned, so detection must come from server allowlists and review. MCP guidance says clients should warn that servers run with the same privileges as the client (^[126]).

Record pass criteria per test and rerun the pack at each policy change and quarterly. A missed detection is a finding about the layer, not a failure of the pilot.

Exception and incident process

An exception is needed whenever a warned or failed version is allowed, or an excluded class is used with regulated data. The record should name the requester, the version or digest, the data classes, the reviewer, the compensating controls, and an expiry. Anthropic limits "Allow anyway" to Owners, Primary Owners, and roles with Libraries set to "Can manage", and allowing a version removes the banner for everyone with access to it (^[127]), so the decision is organization-wide in effect. An allowance can be undone with "Revoke", and an owner can remove an item from the library.

If a published item is suspected of misbehaving, the response is: remove or disable the item, hold dependent workflows, preserve the package and logs, review the audit log for sharing events, and notify the privacy officer if PHI could have been involved. NIST's generative AI profile recommends incident response plans for third-party generative AI technologies (^[128]). Plugins set to "Required" cannot be turned off by users (^[129]), so owners must be able to remove them centrally.

Enable, limit, or prohibit decision tree

1. Is the tenant under HIPAA, ZDR, or CMEK? If yes, scanning is unavailable. Default to prohibit for user-created and third-party skills. Allow limited use of owner-provisioned, fully reviewed, pinned skills for Classes 0 to 2 only. Keep Publishing at "Requires review".
2. If no, will the artifact class be scanned? Existing items, Claude-created skills, MCP-delivered skills, and MCP servers are not. For these, limit to reviewed and allowlisted items.
3. Does the skill touch Class 3 or 4 data? If yes, require human review and a fixed version regardless of scan result. If the BAA does not cover the surface, prohibit.
4. Is Publishing set to "Open"? For regulated roles, switch to "Requires review" so a scan pass cannot be the only gate.
5. Otherwise, enable scanning as a pre-filter with the manifest, and rerun the negative-test pack at each change.

Coverage calculation (Hypothetical Example)

The prescribed metric uses the reader's own inventory: reviewed applicable artifacts divided by total inventoried artifacts, with excluded classes reported separately and never counted as passes. The following worked example is a hypothetical inventory of 134 artifacts in a standard Enterprise tenant that has no CMEK, ZDR, or HIPAA configuration.

• Pre-enablement third-party items: 38 (excluded from scanning).
• Post-enablement third-party uploads and edits: 46 (scanned: 39 pass, 5 warn, 2 fail).
• Skills created with Claude: 21 (excluded).
• MCP-delivered skills: 9 (excluded).
• MCP servers: 12 (excluded).
• Hooks outside plugins: 8 (not described).

Scanner-touched artifacts are 46 of 134, or 34.3%. A completed review requires the scan result plus a documented human review. Suppose human review is complete for 31 of the 39 passes and all 5 warns, while the 2 fails remain blocked and out of the numerator. Reviewed coverage is (31 + 5) / 134 = 26.9%. The excluded classes total 38 + 21 + 9 + 12 + 8 = 88 artifacts, or 65.7% of inventory, and are reported separately. If compensating review is completed on 24 of those 88, combined reviewed coverage is (36 + 24) / 134 = 44.8%. In a HIPAA, ZDR, or CMEK tenant the scanner term is zero by construction, and the full inventory depends on compensating review. The numbers are illustrative; readers should compute the metric from their own inventory.

Ecosystem and risk statistics

The following figures are aggregate and come from originators. They indicate exposure context, not the behavior of any specific product.

• Skill ecosystem measurement. A study collected 42,447 skills from two public marketplaces (^[130]). In its analysis, data exfiltration (13.3%) and privilege escalation (11.8%) were the most prevalent patterns (^[131]), and 5.2% of skills showed high-severity patterns suggesting malicious intent (^[132]).
• Behaviorally confirmed malicious skills. A separate analysis of 98,380 skills (^[133]) identified 157 with confirmed malicious behavior, about 0.16%, and its authors note a 60-second dynamic window may miss delayed payloads (^[134]).
• MCP tool poisoning. A benchmark built on 45 live MCP servers and 353 tools (^[135]) concluded that safety alignment is ineffective against malicious actions that use legitimate tools (^[136]). A cross-framework measurement found metadata scanning alone is a partial control (^[137]).
• Breach cost context. IBM's 2026 Cost of a Data Breach Report puts the global average at USD 4.99 million (^[138]), based on 602 organizations (^[139]), and healthcare at USD 6.64 million, the highest of any industry for the 15th consecutive year (^[140]).
• AI access controls. In IBM's 2026 data, 92% of organizations reporting an AI-related breach lacked proper AI access controls (^[141]), and only 40% of organizations reported using access controls on AI models and data (^[142]). IBM lists compromised APIs, applications, or plug-ins as a cause in 27% of breaches targeting AI (^[143]).
• Third-party involvement. Verizon's 2026 Data Breach Investigations Report puts third-party involvement at 48% of breaches (^[144]), for incidents between November 1, 2024, and October 31, 2025 (^[145]).
• Healthcare reporting. HHS's report to Congress for calendar year 2024 records 663 breach notifications affecting 500 or more individuals (^[146]), covering approximately 242,908,056 individuals (^[147]).
• Package ecosystem. Sonatype identified more than 454,600 new malicious open-source packages in 2025 (^[148]).
• Analyst view. Gartner names AI application compromise, prompt injection, and software supply chains among four critical threats (^[149]).

These figures do not isolate Claude skills and should not be read as scanner efficacy evidence. The 0.16% and 5.2% figures are not comparable, because the studies define "malicious" differently and sample different registries.

Is Claude HIPAA compliant?

Anthropic offers a HIPAA-ready Enterprise configuration that is limited to Enterprise plans and requires the Primary Owner to accept the BAA. Features are sorted into covered, available but not covered, and disabled, and skills sit outside BAA coverage. Compliance remains a determination for the covered entity or business associate, so consult counsel and the privacy officer.

Does Claude zero data retention work with HIPAA?

They are different mechanisms. Anthropic describes HIPAA-ready API access as an alternative to ZDR (^[150]), and its Claude Code HIPAA configuration is meant to replace ZDR for local mode (^[151]). Even with ZDR or HIPAA, flagged content can be retained for up to two years (^[152]).

What do Claude plugin security scanning and malicious Claude skills detection cover?

Third-party skills, plugins, skills bundled in plugins, and hooks shipped in a plugin, at upload or edit. Existing items, Claude-created skills, MCP-delivered skills, and MCP servers are outside it. Anthropic does not describe methods or accuracy in the pages reviewed, while one academic study of public skills (arXiv 2601.10338) reports a detection methodology with 82.5% recall at 86.7% precision on a validated sample (^[55]); that result does not measure Anthropic's scanner.

What are the main Claude skills security risks, and how is Claude Code plugin marketplace security handled?

Skills can carry executable code, plugins run with the user's privileges (^[39]), and updates can change reviewed files (^[35]). A marketplace name shows who publishes the catalog, not what each plugin does, and administrators can restrict marketplace sources with a managed allowlist (^[63]).

What about Claude skills and pharma compliance, and agent skills supply chain security?

Treat each skill by intended use and data class. ICH Q9(R1) and GAMP 5 both scale effort to risk (^[114]) (^[113]). For supply chain security, use provenance records (^[59]), allowlists, pinned versions (^[66]), a component inventory (^[153]), and a revocation plan (^[90]).

Several uncertainties will shape how long this analysis stays current. First, Anthropic labels the scanner a beta, says MCP servers are not scanned "at this time", and says the override is rolling out gradually, so the exclusion list may change. Re-read the scanner article at each procurement review instead of carrying forward this report's matrix.

Second, regulators are moving toward explicit AI guidance for GxP. The European Commission's draft Annex 22 emphasizes the intended use of the model, performance metrics, training data quality, and test data management (^[154]), and it limits critical applications to static models (^[155]).

Third, agent security is shifting from perimeter checks toward runtime enforcement. OWASP's agentic guidance observes that agentic ecosystems compose capabilities at runtime, which expands the attack surface beyond static dependencies (^[156]), and Anthropic's inference hooks point the same way (^[88]).

HHS has also proposed, but not finalized, a Security Rule update that would require a technology asset inventory, so teams that inventory skills and plugins now are better placed for any final text (^[106]). The scanner is best framed as a useful pre-filter and not an approval. The practical agenda is to inventory artifacts, measure reviewed coverage with excluded classes reported separately, align publishing policy with data classes, and wire compensating controls into the quality system. Procurement teams should ask Anthropic for documented scope commitments, detection methodology, and a change-notification path for scanner coverage.

Anthropic's skill and plugin scanning is a real but bounded control. It reviews third-party skills and plugins at upload or edit, returns pass, warn, or fail, and is on by default for Enterprise organizations that had not chosen a setting as of October 2, 2026. It does not cover items already present, Claude-created skills, MCP-delivered skills, MCP servers, or any organization using CMEK, ZDR, or HIPAA configurations, and a pass is explicitly not a guarantee of safety.

For pharma and biotech, the decision rests on three moves. Keep human approval as the gate, particularly because default publishing can let a scan pass stand in for review. Report coverage as reviewed artifacts over total inventory with excluded classes separate. And treat HIPAA, ZDR, and CMEK tenants as unscanned by design, applying provenance, allowlists, pinned versions, sandbox tests, least privilege, egress controls, secret isolation, and runtime monitoring. Because the pages reviewed publish no detection benchmarks, the scanner's marginal protection cannot be quantified, which is a further reason to keep compensating review in place. Facts here reflect Anthropic documentation read on November 10, 2026 and should be reverified before each decision. Teams that want help translating this model into a quality-system procedure can contact IntuitionLabs.