Gated Capability

Some programs can do more than they show everyone. In AI systems, there are functions that the provider deliberately keeps behind an access barrier. Only those who have been vetted and approved may use them. In English, such a locked-off function is called a “Gated Capability” — that is, a capability with a gate in front of it. The gate is not a technical glitch, but a deliberate decision. The provider itself considers the function capable of causing harm if it falls into the wrong hands.

The gate as a risk brake

A capability can be useful and dangerous at the same time. A model that designs molecular structures helps in pharmaceutical research. The same capability could also assist with dangerous substances. So the provider cannot simply switch the function off, but also does not want to distribute it freely. The solution is the gate: the function exists, but the circle of users remains small and known.

For companies, this is also a liability issue. If misuse occurs, it makes a difference whether anyone had anonymous access or whether it was a named, vetted customer. Regulators now expect exactly this kind of evidence. In the EU, the European Union’s AI Act — the so-called AI Regulation — requires providers to control and document particularly high-risk systems. An access gate is one of the simplest answers to that requirement.

But there is also criticism. It is the provider itself who decides, not an independent body. Researchers complain that they cannot examine models because they lack access. And a gate that only opens for large commercial customers may protect less against misuse than against competition.

How such a gate is built

The most common approach runs through the interface that programs use to talk to the model. This interface recognizes every access request by a personal key, a kind of long password. For each key, it is stored which functions are unlocked. If someone without authorization requests the locked function, a rejection is returned. The capability itself remains in the model — only the door stays shut.

Before activation, there is usually a review. The applicant describes their purpose, verifies their organization, and signs terms of use. Some providers additionally require a conversation or a test phase with a tight limit. Often only part of the capability is unlocked, such as a limited number of requests per day.

It is important to distinguish this from a related technique. A filter within the model rejects certain requests based on content, regardless of who is asking. A gated capability does not reject the content, but the person. That is why the gate only works with models that run on the provider’s own servers. As soon as someone can download the model file itself and run it offline, every gate becomes ineffective.

Gated capabilities in real products

Gated capabilities regularly appear in the news whenever major providers introduce a new model. Typical examples are systems that can realistically recreate voices. This function is often only granted to vetted studios, because it could otherwise be used for phone fraud. Something similar applies to tools that scan program code for security vulnerabilities.

Milder forms of this are also familiar from everyday life. Waitlists for new chatbot features are a mild form of the gate. Sometimes the justification is less about safety than about computing capacity. Those who pay get through faster — economic and safety-policy motives can hardly be distinguished from the outside.

For investors and observers, the term is therefore doubly interesting. It reveals which capabilities a provider itself considers sensitive. And it shows how strongly a company ties its models to its own servers. The more functions lie behind gates, the less freely available the technology is.