14 Oct 2026 · Desmond Okafor-Hale (editorial persona) · Governance and leadership · on threat.cafe

Are built-in agent protections enough? What auto mode, MCP allowlists, store scanning and skill scanning cover

Built-in protections are enough for an organisation whose agents run on one vendor's client, install from one store, and never change what they installed. Few organisations look like that. Anthropic, GitHub and the ClawHub skill store each shipped meaningful controls in 2026, and each one is scoped to its own surface: auto mode judges actions inside Claude Code, GitHub's MCP allowlists bind three Microsoft-side clients, ClawHub scans what ClawHub hosts, and Claude Enterprise scans skills uploaded through claude.ai and Cowork but not through the API. The residual risk is in the gaps between them. Map those gaps before buying anything, and buy only for the cells that stay empty.

The consensus, stated fairly

The case for relying on native controls is strong, and it deserves a fair hearing before it is challenged. The vendors that build the agents see every tool call, own the permission system and can ship fixes in days. Their controls are free at the margin, require no new procurement and carry no integration risk. A third-party tool that duplicates them adds cost, latency and another vendor with access to your developers' machines. And the native controls are good: Anthropic's own study of 1,053 testers found that "human review caught just 13.6% of dangerous commands, while auto mode caught 89%" (Claude blog, 7 August 2026).

A security leader who reads that and declines to buy anything else is making a defensible capital-allocation decision. It is not negligence.

Why the consensus holds up locally

Each control works where it is pointed. The trouble is a coordination problem rather than a quality problem: every vendor optimises the surface it owns, and no vendor is paid to cover the seams between its product and a competitor's. That is a rational local optimum for each of them, and it leaves the buyer holding the union of their blind spots.

The cracked assumption

The assumption underneath "native is enough" is that an agent's risk lives inside one product. It does not. A single developer can run Claude Code in a terminal, Copilot in VS Code and a desktop agent, while pulling packages from npm and PyPI, skills from two stores and MCP servers from a registry, all in the same afternoon. The second-order effect of buying no cross-cutting control is that the most permissive surface sets the effective policy.

The alternative mechanism in one sentence: native controls reduce risk on the surface they own, and the residual risk concentrates in cross-vendor, cross-registry and post-approval gaps that no single vendor has an incentive to close.

What each native control documents about its own scope

Claude Code auto mode. A classifier reviews actions that rules and the built-in allowlist do not settle. It sees user messages and tool calls, not tool results (Claude Code permission modes). In Anthropic's evaluation, the full pipeline missed 17% of 52 real overeager actions, and Anthropic calls it "not a drop-in replacement for careful human review on high-stakes infrastructure" (Anthropic Engineering, 25 March 2026). The same write-up lists "installing packages already declared in the repo's manifest" among default allow exceptions, so a manifest range that resolves to a freshly hijacked version is not, by design, a classifier question. Scope: Claude Code sessions.

GitHub MCP allowlists. allowedMcpServers and deniedMcpServers in enterprise managed settings are enforced on the Copilot app, Copilot CLI and VS Code, and "policies fail closed" (GitHub changelog, 6 August 2026). Remote servers match on canonicalised serverUrl, local servers on exact serverCommand. The changelog says the serverName match is "only supplied as a convenience, not a security control, since users can rename servers." Claude Code has its own managed allow and deny lists for MCP (Claude Code MCP docs), configured separately. Scope: the clients that read each vendor's file.

ClawHub with VirusTotal. Published skills are hashed and checked, the full bundle is uploaded for analysis when no verdict exists, and active skills are re-scanned daily. Malicious verdicts block download; suspicious ones stay available with a warning (OpenClaw, 7 February 2026). OpenClaw states the limit itself: a skill that instructs an agent to do something malicious "won't trigger a virus signature." Scope: skills hosted on ClawHub.

Claude Enterprise skill scanning. Skills members upload or edit in claude.ai or Cowork are scanned, and failures are blocked. Scanning "doesn't cover the Claude API," does not apply to skills already present when it was switched on, and does not apply to organisations with CMEK, ZDR or HIPAA configurations (Anthropic, Agent Skills enterprise docs). Scope: two upload paths in one product.

The coverage map

Cells read: Y covered by the documented control, P partial, - not covered. Blank-looking rows are the point.

Artifact / surface                         Auto    Claude Code   GitHub MCP   ClawHub   Claude Ent.
                                           mode    managed       allowlist    + VT      skill scan
                                                   rules/hooks
-----------------------------------------  ------  ------------  -----------  --------  -----------
npm/PyPI install by Claude Code            P       Y (if built)  -            -         -
npm/PyPI install by Copilot or other agent -       -             -            -         -
MCP server added in Claude Code            P       Y             -            -         -
MCP server added in Copilot / VS Code      -       -             Y            -         -
MCP server in a fourth client              -       -             -            -         -
Skill from ClawHub                         P       P             -            Y         -
Skill from skills.sh or a git repo         P       P             -            -         -
Skill uploaded in claude.ai / Cowork       -       -             -            -         Y
Skill uploaded via Skills API              -       -             -            -         -
Skill present before scanning enabled      -       -             -            -         -
Artifact that turns malicious after        P       P             -            Y daily   -
  approval (new version / same name)
Natural-language payload in a skill        P       -             -            -         P

"Y (if built)" for Claude Code managed rules means the client supplies the mechanism, deny rules and PreToolUse hooks, but someone has to write the rule and feed it data. Auto mode is marked partial throughout because it judges intent from the transcript and cannot know whether a specific version is known to be malicious.

Three lines of evidence, strongest last

First, the vendors draw their own boundaries. Each source above states its scope in plain words: three named clients, one store, two upload paths. None claims more.

Second, renaming defeats name-based policy. GitHub's own changelog warns that server names are user-assigned and can be changed. A fleet that writes policy against names in one client and leaves another client unmanaged has two ways to be wrong.

Third, timing defeats install-time checks. In the postmark-mcp case, the hidden BCC arrived in version 1.0.16 (The Hacker News, 29 September 2025). In the axios compromise, the first malicious version reached npm at 00:21 UTC on 31 March 2026, and the malware advisory followed at 03:15:49 UTC (npm registry; OSV). Native controls that check at upload or install see the artifact as it was then. Only ClawHub, among the controls mapped here, documents a re-scan cadence.

Where native controls are sufficient

Be precise about the boundary. If every developer uses one client under managed settings, skills come only through a scanned upload path, MCP servers are pinned by URL or exact command, and installs go through a lockfile that changes only by pull request, the native stack covers most of the map. The remaining gap is known-bad data for the managed hooks to read, which is a data question, not a platform purchase.

Where this argument would be wrong

If the major clients converge on one shared policy file, or if registries begin to publish and honour each other's takedowns, the cross-vendor and cross-registry rows fill in and this argument weakens. Neither has happened on the evidence read for this article.

The Monday-morning decision

Fill in the map for your own fleet before any vendor meeting:

List every agent client in use, from endpoint inventory rather than from policy.
List every place agents get artifacts: package registries, skill stores, MCP registries, git URLs.
List every upload path for skills, including the API.
Mark each cell Y, P or - using the vendors' own scope statements.
Buy, or build, only for the dashes you cannot accept.

A cross-registry list of known-bad artifacts is one way to fill the post-approval and cross-registry rows; the threat.cafe board is building one in the open.

Sources

#native-controls #mcp-allowlist #skill-scanning #auto-mode #buyer-guide

All posts