Anomity Is Approved in Anthropic's Cyber Verification Program

On Wednesday, June 10, 2026, Anomity was approved in the Anthropic Cyber Verification Program. The program is Anthropic's route for cybersecurity organizations whose legitimate defensive work overlaps with techniques a frontier model is otherwise trained to refuse.

This post is the announcement, and it is also the explainer we went looking for before we applied. What the program is, what it changes and what it deliberately does not, where to apply from depending on how you access Claude, and why a verification granted by a model provider is one layer of AI governance rather than the whole of it.

Why a frontier model blocks defensive security work

Claude Opus and Sonnet models ship with real-time cyber safeguards enabled. Anthropic describes them as designed to automatically detect and block requests that may indicate prohibited or high-risk cybersecurity usage, judged against the Usage Policy. They act on the request as it arrives, not on a post-hoc review of an account.

The reason a defensive security company runs into them at all is that, at the level of the tokens in a prompt, a great deal of defensive work is indistinguishable from offensive work. Reconstructing the payload hidden inside a malicious agent skill, working out whether a reported flaw is actually exploitable before we publish a severity, writing the detection rule that catches a credential stealer: each of those requires reasoning carefully and specifically about how an attack functions. That is exactly the reasoning an attacker would want, expressed in exactly the same words.

This is the oldest problem in security tooling, arriving in a new place. A debugger, a packet capture, a fuzzer and a disassembler are all dual-use, and the industry resolved that a long time ago by attaching the judgement to the operator rather than to the tool. What is new is that the tool now evaluates the request itself, in real time, and has to make that judgement without knowing who is asking. The Cyber Verification Program is the mechanism that supplies the missing half: it tells the model provider who the operator is.

The two categories the safeguards separate

The distinction that matters most is that the safeguards are not one undifferentiated wall. They block two different things for two different reasons, and only one of them is negotiable.

It is worth being precise about this, because the program is easy to describe wrongly. Verification is not a permission slip that switches the safety training off. It moves one boundary, the one between dual-use and default-blocked, for one organization. The boundary between permitted and prohibited does not move for anybody, and an approved organization that submits a prohibited-use request gets the same block as an unverified one.

How the Cyber Verification Program works

The mechanics are refreshingly ordinary, which is the point. Per Anthropic's documentation:

• It is free and application-based. There is no cost and no commercial tier attached to it.
• It is organization-scoped. One approval covers the organization, rather than each engineer applying individually.
• It applies to the Opus and Sonnet model families, which is where the real-time cyber safeguards run.
• Anthropic aims to send an email notification with the review decision within two business days.
• Organizations using Zero Data Retention are ineligible, which is a constraint worth checking before you apply rather than after.

Where you apply depends on where you run Claude

This is the detail most likely to catch a security team out, because the answer is not the same for every deployment route.

Those last two rows matter more than a table row usually does. Plenty of enterprises route model access through Bedrock or Vertex precisely because it keeps traffic inside an existing cloud contract, an existing network boundary and an existing billing relationship. If that is your route, verification is not currently an option and the default safeguards apply to your security team's work. That is worth knowing before you design a defensive workflow on top of a path you cannot verify, not after your first blocked investigation.

Appeals, and when a block is not a false positive

Anthropic documents an appeal path for blocks a verified organization believes to be wrong. The steps are to confirm that the organization ID on the blocked request matches the one on the approval confirmation, confirm that the activity really is high-risk dual use rather than prohibited use, and then submit the appeal form.

The middle step is the one worth internalising. A block landing on a verified organization is not automatically a bug in the classifier. It can just as easily mean the request crossed from dual use into prohibited use, in which case verification never applied to it and no appeal will change that. Teams that treat every block as a false positive learn the boundary slowly and noisily. Teams that read the block as information about which side of the line the request fell on learn it quickly.

What the verification covers for us

Anomity publishes security research, and the research is where dual-use analysis actually shows up in our work. The advisory library runs to 77 published advisories on real vulnerabilities in agent and MCP infrastructure, from MCP STDIO command execution to prompt injection that reaches a shell in CrewAI to npm worms that plant Claude Code hooks. Writing any of those honestly means answering the question a defender actually cares about, which is whether the flaw is reachable and what an attacker does with it once it is.

It shows up again in the Skill Risk Index, where we scan and publish security verdicts on 20,427 public AI agent skills. The scanning pipeline itself is deliberately narrow: untrusted skill code is analysed statically inside a sandbox and never executed, and the adjudication of candidate findings runs on a locally hosted model rather than a frontier one, so the corpus never leaves the machine. The frontier-model work sits around that pipeline, in the harder judgement calls: is this pattern a genuine attack signal or a documented installer, does this finding hold up against the skill's real source, what would this payload actually do. That is the analysis the verification covers, and it is the same analysis behind our work on malicious agent skills and hidden payloads and the playbook for vetting skills before you approve them.

What it does not cover is worth stating too. It is scoped to our research organization. It changes nothing about the product's data handling, which remains metadata only, never source and never prompts, with secret values redacted on the endpoint before anything leaves the machine, strict tenant isolation, and SOC 2 Type II attestation behind all of it.

Provider-side verification is one layer, not the layer

The Cyber Verification Program is a good piece of design, and it is worth saying why rather than just saying so. It puts a control where the provider genuinely has leverage, which is the account, the organization and the individual request. It keeps a hard floor under everyone. It attaches identity to a judgement that cannot be made from the text of a prompt alone. And it is fast and free, which means it does not quietly select for large organizations with procurement teams.

But look at the shape of what it governs. It governs what one organization may ask one provider's models, through the routes that provider controls. Now list what is running on a single developer laptop in your fleet on any given Tuesday: a coding agent with a permission configuration nobody has read, four MCP servers pulled from a public registry, a handful of skills and plugins loaded into the agent at runtime, browser extensions with page access, an Ollama or LM Studio runtime serving a model with no safeguards at all, and API keys for two other providers sitting in a plaintext config file.

Not one of those is visible to, or governable by, a verification granted by Anthropic. That is not a criticism of the program; it is the boundary of what any provider-side control can reach. Anthropic can gate Claude. It cannot gate the model you self-host, the MCP server you installed, the skill you pulled this morning, or the browser tab where someone is using a different provider entirely. We have made this argument before about scan-time vetting versus runtime governance and about the security agents teams deploy for defense, and it holds here too: a control at one chokepoint is a real control, and it is still one chokepoint.

The shadow-AI failure mode nobody plans for

There is a second-order effect here that deserves more attention than it gets, and it is the reason we think this program is a governance story rather than a compliance footnote.

When a control blocks legitimate work and the organization has not told anyone that a legitimate exemption path exists, people route around the control. A security engineer stopped mid-investigation does not stop investigating. They open something else: a local model runtime on their own laptop, a personal account on another provider, a browser tab that your DLP has never seen. The safeguard held perfectly. The work simply moved to a surface with no safeguard on it at all, no logging, and no retention policy, taking the malicious sample with it.

This is the same dynamic that turns a well-meaning AI acceptable use policy into a driver of shadow AI when it is written as a wall of prohibitions with no sanctioned path through it. It is the same dynamic behind what employees actually paste into consumer AI tools. The mechanism does not care whether the blocked person is in marketing or in the SOC.

The practical response is short:

• Apply, if your organization does dual-use defensive work on Claude. It is free, it takes two business days, and an approval sitting unused costs nothing.
• Tell your engineers the exemption exists. An approval nobody in the SOC knows about produces exactly the same routing-around behaviour as no approval at all.
• Check which route your Claude access runs on. If it is Bedrock or Vertex, verification is not currently available and your team should know that in advance rather than discovering it at 2am.
• Inventory the local model runtimes, because that is where blocked work tends to land, and a self-hosted model has no safeguards, no classifier and no audit trail.
• Watch the browser, because the other place blocked work lands is a personal account on a provider your controls have never heard of.

Where this leaves us

We are glad to be verified, and we think the program is the right shape: identity-scoped, fast, free, with a floor that does not move. It is also a useful illustration of the argument this company exists to make. Anthropic put a control exactly where it has visibility, and that control is genuinely effective inside its boundary. The moment you step outside that boundary, onto the endpoint where the agents, MCP servers, skills, extensions, hooks and self-hosted runtimes actually live, nobody has visibility unless somebody deliberately built it. It is not our only relationship with Anthropic either: Anomity is also part of Claude for Startups, which buys a different thing entirely - earlier sight of what ships, on a product that keeps adding artifacts we have to be able to see.

That is the layer Anomity covers. An unprivileged Endpoint Sensor inventories every AI artifact on Windows, macOS and Linux endpoints, a Browser Sensor covers the AI people use in a tab including the accounts they sign in with, and cloud discovery surfaces the AI applications holding OAuth grants against Google Workspace and GitHub. Policy is enforced at the agent hook, before a tool call runs, and every decision lands in a queryable 90-day audit trail. You can't govern what you can't see, and provider-side verification, however well built, only sees its own side. That inventory is now queryable from an assistant too: our read-only connector is listed as the Anomity MCP server in the Claude directory.