On April 30, OpenAI restricted access to its “Cyber” capability. What made it notable was that OpenAI had spent the prior weeks criticizing Anthropic for limiting access to “Mythos,” arguing that gating these capabilities held back legitimate defenders. Six weeks later the same company drew the same line for the same reasons it had just called wrong.
Then on June 10, cybersecurity researchers started complaining publicly about the guardrails on Anthropic’s “Fable” model, saying the safety filters were blocking the exact work they were hired to do. A week before that, on June 3, Anthropic published a map of a full year of AI-enabled cyber threats it had observed in the wild: real campaigns, actual tooling, and more volume than I expected.
Both things are true at once. The labs have genuine data showing their models being used for offensive cyber operations, and the labs also happen to control a capability gate that is, conveniently, a competitive lever. For anyone building products on top of these models, the distinction between “responsible” and “strategic” matters less than the fact that the gate exists at all and that someone else holds the key.
I’ve spent my career building on infrastructure I didn’t own. This is a familiar problem wearing an unfamiliar face.
Capability Policy Is Now a Dependency
When I think about dependencies, I think about the things that can break my roadmap without my permission. A library can deprecate an API. A cloud provider can change pricing. A vendor can get acquired. We plan around all of those because we’ve been burned by all of those.
Model capability policy belongs on that list now, and most teams haven’t added it yet. A vendor’s decision about what their model is allowed to do is no longer a fixed property of the product you bought. It’s a moving policy that can shift between two deploys, with no SLA, no deprecation window, and not even the courtesy of a migration guide.
At Vestmark we run security analysis through LLMs as part of how we reason about our own posture across a platform that touches roughly $2 trillion in assets. If a vendor decided tomorrow that a category of security-adjacent reasoning was now “Cyber” and gated, that’s not a feature request I can file. That’s a capability that worked on Monday and returns a refusal on Tuesday, inside a product my customers depend on.
The OpenAI reversal is the part that should make every CTO uneasy. This was a 180 in six weeks by a company that had publicly argued the opposite position, with no slow drift toward caution to soften it. Whatever policy your vendor has today is just where they happen to have landed this quarter, and there’s no reason to assume it will hold.
Why This Is Different From Normal Vendor Risk
We have decades of muscle memory for vendor lock-in. The usual answer is abstraction: don’t call the vendor SDK directly, put an interface in front of it, keep the switching cost low. That advice still holds.
But capability gating breaks one assumption we rely on. With most vendor changes, the capability still exists somewhere; you’re negotiating price, terms, or support. Here the capability can be withdrawn from everyone at once, for reasons that have nothing to do with you, justified by threat data you can’t audit and competitive pressure you can’t see.
The Fable complaints from security researchers show the failure mode clearly. These are legitimate defenders doing legitimate work, and the guardrail can’t tell them apart from an attacker because the guardrail operates on the capability, not on the user. When the gate is that blunt, “we’ll grant you an exception” is not a strategy you can build a product schedule around.
This is the upstream version of a problem I usually talk about in the other direction. I spend a lot of time on governance: making sure the AI systems we build behave inside controls we set. Capability gating is the same governance pointed the other way, at us, with our roadmap on the receiving end.
Design For The Gate Moving
I keep coming back to a point I made in “Skills, Not Models”: the durable thing you build is the skill, the workflow, the integration, the evaluation harness. The model underneath is interchangeable, and you should treat it that way on purpose. Capability gating turns that from a nice principle into a survival requirement.
Concretely, here’s what we’re doing and what I’d push any team building on frontier models to do.
Put a hard abstraction between your code and any single lab. We route LLM calls through an internal layer rather than calling a vendor SDK from business logic. We use RubyLLM specifically because swapping the provider behind a feature is a config change, not a refactor. If that sounds like over-engineering for a single-vendor setup, that’s exactly the trap; the abstraction is cheap to build before you need it and expensive to retrofit the morning a capability disappears.
Run more than one lab in production, not just in a doc. A multi-model strategy only protects you if both paths are actually exercised. We keep at least two providers warm for our higher-risk workflows, with evals that run against both, so a gate on one provider degrades a feature instead of taking it down. If you’ve never actually failed over to the second provider, you don’t have a fallback; you have a slide that says you do.
Treat capability policy as a tracked vendor risk. We now log which workflows depend on which provider-specific behaviors, and we flag the ones that sit near a gate-able category: security, code execution, anything the labs describe as dual-use. That register is what tells me, in an afternoon, what breaks if a given lab tightens a given policy.
Read the threat data, because the gates are partly earned. Anthropic’s year-in-review of AI-enabled threats is real, and I won’t pretend the labs are inventing the risk to build a moat. Some of these capabilities are genuinely dangerous, and I’d rather build on a vendor that takes that seriously than one that doesn’t. Designing around the gate and respecting the reason for the gate are not in conflict.
What To Do This Week
Pull up the AI features on your roadmap for the next two quarters. For each one, write down which single vendor capability it depends on, and ask one question: if that capability got reclassified and gated next month, the way OpenAI reclassified Cyber, what happens to this feature and to the customers using it?
If the honest answer for any revenue-bearing feature is “it stops working and we have no fallback,” you’ve found your most urgent piece of vendor risk. The labs have shown you, twice in six weeks, that they will move the gate when it suits them. Build as though they will do it again, because the next reclassification won’t come with a warning.