What actually shipped
Anthropic added automated security scanning for custom skills to Claude Enterprise, currently in beta. It's documented in the Skills for enterprise guide on Anthropic's own developer platform, under a section called "Skill content scanning." The short version: an Enterprise admin turns the feature on, and from that point, skills members upload or edit in claude.ai or Claude Cowork get automatically checked for malicious behaviour before anyone else in the organisation can run them.
This is a narrower, more specific thing than it might sound like at first. It isn't a general skills antivirus, it doesn't run against your whole existing skill library retroactively, and it doesn't touch skills built through the Claude API. Knowing exactly where the edges are matters more than the headline, because assuming broader coverage than it actually has is worse than assuming none.
How to turn it on
Scanning is an organisation-level setting, not a per-user one. An Enterprise admin turns on Skill and plugin security scanning at claude.ai's Organization settings, under Skills. Anthropic's guidance is unambiguous about the default recommendation: "If scanning is available to your organization, turn it on."
Once it's on, the behaviour applies to skills members subsequently upload or edit in claude.ai or Cowork. That phrasing matters. A skill sitting untouched in your organisation from before you flipped the switch isn't retroactively scanned just because the setting changed; only new uploads and edits pass through the scanner going forward.
What the scanner actually looks for
Anthropic's documentation names three specific categories of malicious behaviour the scan checks for:
- Hidden code execution - a skill doing something other than what its stated purpose suggests when a bundled script actually runs.
- Sending your data to an outside service - the exfiltration pattern this site's own security checklist already flags as the highest-value thing to check by hand: a script or instruction that reads something sensitive and transmits it somewhere external.
- Instructions that tamper with Claude's safeguards - text in a skill written to get Claude to ignore its own guardrails, whether that's a confirmation step, a safety instruction, or a constraint set elsewhere in the session.
That list overlaps closely with the risk indicators Anthropic's own enterprise review checklist tells admins to look for by hand: code execution, instruction manipulation, network access patterns, hardcoded credentials, and filesystem access outside the skill's own directory. The scanner is automating a first pass over the same territory a manual reviewer would otherwise have to work through line by line.
The three outcomes
Anthropic's documentation describes what happens on each side of a scan result:
| Outcome | What happens |
|---|---|
| Fails the scan | Blocked from use |
| Scan hasn't finished | Blocked from use, same as a fail, until it completes |
| Passes with a warning | Stays usable, but sits behind a caution notice |
The caution notice matters as much as the pass itself. A skill that triggers something during review doesn't get silently waved through, it stays usable but visibly flagged, so a member deciding whether to run it sees that the scan found something worth a second look before they commit to it. Anthropic's page doesn't spell out the wording shown for a skill that clears the scan cleanly with nothing flagged; the two outcomes it documents explicitly are the fail/pending block and the pass-with-warning caution notice.
What it doesn't cover
Three real gaps, all stated directly in Anthropic's own documentation rather than inferred:
The Claude API is out of scope entirely. "Scanning doesn't cover the Claude API: skills you upload through the Skills API (/v1/skills), including from the Claude Console, aren't scanned." If you're deploying skills programmatically rather than through claude.ai or Cowork's own interface, this feature does nothing for you. The fallback Anthropic points to is the manual review checklist plus version pinning: pin production skills to a specific version rather than always resolving to latest, so a compromised update to a skill you already trust doesn't silently take effect.
Skills already present before scanning was enabled aren't covered. Turning the setting on is not retroactive. If your organisation already has a library of custom skills, none of them get scanned by flipping this switch; only what members upload or edit afterwards passes through it. An admin who wants existing skills checked has to prompt a re-upload or edit to put them through the scanner, or fall back on manual review for anything already in place.
Certain data handling configurations opt an organisation out entirely. Scanning "doesn't apply... to organizations with certain data handling configurations, such as customer-managed encryption keys (CMEK), zero data retention (ZDR), or HIPAA readiness." If your organisation runs under one of those configurations (common in regulated industries, exactly the kind of organisation that might otherwise want this feature most) the scanning feature simply isn't available to you. That's a real trade-off worth flagging to security teams evaluating either the data handling configuration or the scanning feature, since choosing one currently forecloses the other.
What an automated scanner is likely checking against
Anthropic's enterprise guide pairs the scanning feature with a separate, manual risk tier assessment it asks admins to run on any skill before deployment, and the two clearly cover the same ground from different angles. The manual table names seven risk indicators:
| Risk indicator | What to look for | Concern level |
|---|---|---|
| Code execution | Scripts in the skill directory (*.py, *.sh, *.js) | High |
| Instruction manipulation | Directives to ignore safety rules, hide actions, or alter behaviour conditionally | High |
| MCP server references | Instructions referencing MCP tools (ServerName:tool_name) | High |
| Network access patterns | URLs, API endpoints, fetch, curl, or requests calls | High |
| Hardcoded credentials | API keys, tokens or passwords in skill files or scripts | High |
| Filesystem access scope | Paths outside the skill directory, broad glob patterns, path traversal | Medium |
| Tool invocations | Instructions directing Claude to use bash, file operations or other tools | Medium |
The three malicious-behaviour categories the automated scanner checks for, hidden code execution, external data transmission, safeguard tampering, map onto the top four rows of that table almost directly. That's a reasonable way to think about what's actually being automated here: known, structurally identifiable risk patterns a scanner can check at upload time, the same categories a security-conscious reviewer would look for by hand, just applied consistently and at a scale manual review can't match across every upload.
The manual checklist scanning doesn't replace
Anthropic's own review checklist for deploying any third-party or internal skill has eight steps, and it's worth having alongside the scanning feature rather than instead of it, since some of it inherently needs a human:
- Read all skill directory content:
SKILL.md, referenced markdown files, and any bundled scripts or resources. - Verify script behaviour actually matches the skill's stated purpose, ideally by running it in a sandbox first.
- Check for adversarial instructions telling Claude to ignore safety rules, hide actions, or change behaviour based on specific inputs.
- Check for external URL fetches or network calls in both scripts and instructions.
- Verify no hardcoded credentials anywhere in the skill's files.
- Identify every tool and command the skill instructs Claude to invoke, and consider the combined risk when file-read and network tools appear together.
- Confirm any external URLs the skill references point to the domains you'd expect.
- Look specifically for data exfiltration patterns: instructions that read sensitive data and then write, send or encode it for external transmission, including through Claude's own conversational responses.
Steps like confirming a script's behaviour genuinely matches its stated purpose, or judging whether a combination of tools is risky in context, are exactly the kind of judgement call an automated scanner is poorly positioned to make on its own. That's the practical argument for keeping both: scanning as a consistent first pass across every upload, the checklist as the deeper pass a specific skill earns once it's flagged, widely distributed, or simply important enough to deserve the extra fifteen minutes.
Where this sits relative to plugin marketplaces
The scanning feature's name, "Skill and plugin security scanning," and Anthropic's phrasing elsewhere describe it as available "in Claude, Claude Cowork, and Enterprise plugin marketplaces," per secondary reporting consistent with Anthropic's Help Centre article on the feature. That extends the same scanning logic to plugins distributed through an organisation's internal marketplace, not just skills uploaded directly by individual members. If your organisation runs its own plugin marketplace to distribute skills and MCP servers packaged together, this is the mechanism that would check what gets published there before members can install it, assuming your organisation has scanning turned on.
Why "beta" matters here
Anthropic labels this explicitly as a beta feature, which is worth taking at face value rather than glossing over. A beta security scanner is a genuinely useful additional layer, not a finished, audited control you'd want to be your only line of defence. The framing in Anthropic's own documentation backs this reading up directly: scanning "complements, but doesn't replace" the manual review checklist. Treat a clean scan result the way you'd treat a linter passing on a pull request, evidence that a specific, known category of problem wasn't detected, not proof the code is safe.
This is consistent with the editorial position this site has taken since before this feature existed: read a skill before you run it. Automated scanning changes the economics of that advice for large organisations (a scanner can review every upload at a scale no security team can match by hand) but it doesn't remove the value of the human read, especially for anything with elevated trust or broad distribution inside your org.
What to actually do with this if you run an Enterprise organisation
If scanning is available to you, turn it on. Anthropic says so directly, and there's no real downside: it adds a check, it doesn't remove any existing capability. Beyond that:
- Don't assume it covers your API-deployed skills. If any part of your skill deployment goes through the Skills API rather than claude.ai or Cowork's own upload flow, that path needs the manual checklist and version pinning regardless of whether scanning is on for everything else.
- Re-upload or re-edit anything already in your library that you want scanned. The setting isn't retroactive, so an existing skill catalogue stays unscanned until someone touches it again.
- Check whether your data handling configuration excludes you. If your organisation runs CMEK, ZDR, or is configured for HIPAA readiness, confirm directly whether scanning is actually available before assuming it's protecting you.
- Keep the manual review checklist in place regardless. A caution notice on a skill that passed with a warning is a signal to look closer, not a substitute for having looked at all.
Where to go next
For the full manual pre-install checklist this feature complements rather than replaces, see Agent Skills Security: What to Check Before You Install. For how skills and MCP servers get packaged together for distribution through a marketplace, see Agent Plugins explained. For the basics of how skills load and activate in the first place, see What Are Agent Skills?. Browse security-focused skills already reviewed and linked to their source at getclaudeskills.com/categories/security, or the full catalogue at getclaudeskills.com/skills.
Verified directly against Anthropic's Skills for enterprise documentation at platform.claude.com. The claim that scanning extends to Enterprise plugin marketplaces, and the exact toggle location, are corroborated by Anthropic's Help Centre article on the feature, which this environment could not fetch directly at time of writing; the core scan behaviour, outcomes and exclusions above come from platform.claude.com directly.
