Claude Security and Where Scan-Time Vetting Ends

Anthropic shipped Claude Security, a security offering currently in public beta that scans codebases and uses model reasoning to find complex, multi-component vulnerabilities that pattern-matching tools often miss. It is a genuinely strong build-time tool, and this piece is not a critique of it. It is a map of where its job ends and a different job begins. We drew the same line for the NVIDIA SkillSpector agent skill scanner: scan-time vetting is necessary and complementary, and it does not, by design, answer the runtime questions.

The distinction is simple. Scan-time tools inspect code and artifacts before they run and tell you whether they contain a known-shaped problem. Runtime governance answers three different questions: which agents, MCP servers, skills, plugins, and CLIs are actually installed and running on which endpoints right now; what a given agent is allowed to do when it makes a tool call; and what it actually did. Claude Security answers the first kind of question well. It does not try to answer the second, and neither does any scanner. Facts first; we close on the layer that makes those facts verifiable everywhere.

What Claude Security does at scan time

Claude Security scans a codebase and uses reasoning rather than signature matching to find complex vulnerabilities such as memory corruption, injection, authentication bypasses, and logic errors - the multi-component bugs that span several files and that pattern-based scanners tend to walk past. Every finding runs through adversarial verification, where the model challenges its own result to cut false positives before a human ever sees it. It proposes targeted patches that preserve the surrounding code style, and every patch requires human review before it lands. Findings route to Slack and Jira through webhooks, export to CSV and Markdown for audits, and dismissals are tracked persistently so the same finding does not resurface run after run. Anthropic runs it on its own codebase.

It ships two ways: as a Claude Code plugin in public beta, and through Claude Enterprise, where an admin console enables scheduled and directory-scoped scans. That is a mature build-time posture: it fits CI-shaped workflows, produces an audit export, and remembers what was already triaged. For finding vulnerabilities in code before that code ships, it is exactly the kind of tool a security team should want. It belongs in the same category as SkillSpector: both inspect artifacts before deployment, and both are complementary to - not a substitute for - what happens once the artifact is live on a machine.

The questions a scanner cannot answer

A scan tells you whether the code you pointed it at contains a problem. It does not tell you whether that code is running, where, or under what permissions. Those are the runtime questions, and they are the ones that decide blast radius. Three in particular:

• Which AI artifacts are actually installed and running right now, and on which endpoints. A scan of a repository says nothing about the skills, MCP servers, plugins, and CLIs a developer added to their laptop last week. This is the inventory problem behind vetting and approving agent skills and the agent skills security primer.
• What a given agent is allowed to do when it makes a tool call. A clean scan does not constrain a live agent; the permission the agent resolves at the moment of a call is a separate control, and getting it right is the subject of least privilege for agent skills.
• What the agent actually did. Scan results are about potential; an audit trail is about fact. Which tool calls ran, on which endpoint, and whether each was allowed or denied is a record no scanner produces.

None of this is a gap in Claude Security. It is simply a different job. A skill can pass every scan and still be over-permissioned once installed, and malicious skills that hide payloads to evade static review, as documented in the USENIX 2026 work on hidden payloads, are the sharp version of the same point. Scan-time and runtime are two layers, and a serious program needs both.

The scanner is itself an AI artifact

There is a second point, less obvious and more instructive, that shows exactly why runtime inventory matters. In its plugin form, Claude Security is a Claude Code plugin. It runs with the code access a code scanner needs, and it is installed onto developer machines across a fleet. In other words, the security tool is itself one of the AI artifacts a security team has to account for.

That is not a criticism - it is the nature of the model. Any capable agent tool is a plugin or CLI with real access, and autonomous security agents are agents too. The governance questions are the same ones you would ask of any plugin: who has it installed, at what version, and scoped to which directories. A plugin that can read an entire codebase, running on an unknown set of laptops at unknown versions, is exactly the kind of thing an inventory exists to make visible. What a single plugin install actually adds is covered in the Claude Code features attack surface and the Claude Code harness attack surface, and the broader discipline sits inside securing AI coding agents and CLIs.

Scan-time vs runtime, side by side

How Anomity governs the runtime layer

Anomity is the runtime and fleet-inventory layer that sits underneath scan-time vetting. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint across Windows, macOS, and Linux and discovers and inventories eight AI artifact types: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. A code scanner deployed as a plugin is one of those artifacts, so you can see who has it, at what version, and scoped to which directories - the same way you see every other plugin. The sensor sends metadata only, never source or prompts, and secrets are redacted on the endpoint before anything leaves it. Where an agent exposes a hook, such as the Claude Code PreToolUse hook, Anomity returns an allow, deny, or log decision before the tool call runs. Every change and every decision becomes a queryable 90-day audit trail routed to your SIEM, Slack, email, or Jira, and the platform is SOC 2 Type II. It complements your network, EDR, DLP, and GRC controls rather than replacing them - and it complements scan-time tools like Claude Security in exactly the same way.

You can't govern what you can't see.

Keep the scanner. Scan-time vetting is necessary work and Claude Security does it well. Just do not mistake a clean scan for a governed fleet: the artifacts still have to be inventoried, the tool calls still have to be constrained, and what actually happened still has to be recorded. See how it works for the deployment shape, where Anomity sits next to your existing stack, and the docs for the detail. To see your agent, MCP, and plugin fleet inventoried and governed at runtime, request early access.