Claude scans third-party skills and plugins, and the Compliance API reaches Claude Code

Two enterprise changes landed in Claude within a week of each other, and together they define where Anthropic thinks the governance boundary for agentic tooling sits. On August 6, Claude for Enterprise plans gained a beta feature that automatically scans third-party skills and plugins for malicious content when they are uploaded or edited. On August 12, the Compliance API was extended to cover Cowork and Claude Code across desktop, web, mobile and the CLI, also in beta for Enterprise. If you author skills, MCP servers or plugins that enterprise customers install, both of these now sit between you and your users.

What the scan is, and what it is not

A third-party skill is executable instructions with access to tool calls. That makes it a supply-chain artifact in the same sense as an npm package, and Anthropic is treating it as one: the scan is a preventive gate at upload or edit time. It is not a runtime sandbox. The runtime side is a different feature, inference hooks, which shipped on August 5: a signed WebSocket that sends every prompt and every tool-call response to the customer's own DLP server for an allow or deny verdict before the model sees it, with a published webhook schema (Netskope, Palo Alto, Proofpoint, Zscaler or your own server), shadow mode, role-based exclusions and percentage rollout. Hooks add latency and a single point of control on the critical path; the scan adds neither, because it runs once per artifact.

Together the two form a layered stack: static check at install, dynamic check at inference. Neither replaces the other. A skill that passes the scan can still be talked into doing something stupid at runtime, and a hook that blocks a bad tool call does not stop a malicious skill from being installed in the first place. I covered the tool-calling surface these guard in Claude Code and MCP.

Static scanning catches the skill that is malicious on day one; it does nothing about the skill that becomes malicious on day forty.

Shipping a skill that passes

Anthropic has not published the detection criteria, so what follows is what I do to keep my own artifacts clean, not a spec.

• No obfuscated or encoded payloads. Base64 blobs, minified one-liners and downloaded-at-runtime scripts are the first thing any malicious-content scanner flags, whatever the intent.
• Declare every tool you call. A skill that shells out, touches the filesystem or reaches the network should say so in plain text in its description. Hidden capabilities look like exfiltration.
• No credential handling in the skill body. Reference secrets by name from the environment; never embed or request them.
• Pin and hash your dependencies. If the skill pulls an MCP server or a package, pin the version and publish the checksum.
• Version in lockstep. A silent edit re-triggers the scan and can pause distribution; treat every edit as a release with a changelog.

The same discipline is what you want anyway for sandboxed coding agents, so nothing here is wasted.

The Compliance API on agentic surfaces

Extending the Compliance API from chat to Claude Code and Cowork matters because those are the surfaces where the model does things rather than says things. Regulated customers deploying coding agents need an audit trail of which agent ran which tool with which permissions, and until August 12 that trail stopped at the chat window. The August 11 Claude Code release added owner-level marketplace controls for an entire GitHub organisation, which is the other half: control who can install what, then log what it did.

What governance still misses

The gap is the middle of the lifecycle. The scan checks the artifact at upload; hooks check calls at inference; the Compliance API records what happened. None of them re-scan a skill whose remote dependency changed after install, none of them reason about several benign skills that together do something harmful, and none of them see inside a self-hosted MCP server. All three features are beta and Enterprise-only, and the scanner's criteria are undocumented, so "it passed" tells you it passed today's rules. If you are the customer, keep red-teaming your own skill catalogue. If you are the author, assume that what the scanner wants will change without notice, and write skills that would pass a human reviewer, because that is the only stable target.