← Back to the glossary
Control

Virtual key

A credential issued by the layer to each team or person, in place of the provider's real key. It carries the access profile: allowed models, budget and identity for the trail.

Chave virtual: a chave real fica no cofreA chave real do provedor fica trancada no cofre. Chaves virtuais são emitidas para cada time, carregando seu próprio perfil e limite.COFREchave realTIME · DADOSvk-•••$TIME · DEVvk-•••TIME · BIvk-•••%

Why it matters

A virtual key is the credential the governance layer issues to each team or person, instead of handing over the provider's real key. It matters because the provider's real key is raw power: whoever holds it can use any model, spend without limit, and do so anonymously, since the provider only sees the key, not the person. Distributing that key across teams and code spreads a critical secret and loses, all at once, access control, cost control, and traceability.

The virtual key breaks that coupling. Instead of each person carrying the provider's full power, each one receives their own credential that carries only what that team or person is allowed to do. The real key stays locked in a vault, away from code and hands, used only by the layer — never by the user.

How it works

Each virtual key carries an access profile: which models it can call, what budget is associated with it, and which identity it represents for the audit trail. When a call arrives with a virtual key, the layer reads that profile and applies it — it refuses a model that isn't allowed, accounts for the spend on the right budget, records who made the request. Only after that does the layer use the provider's real key, which the user never sees, to actually execute the call.

The effect is that the credential stops being a secret to protect and becomes a profile to govern. Revoking someone's access is disabling a virtual key, without touching the real key or affecting the others. Changing what a team can do is editing a profile, not redistributing a secret. And because every call carries identity, the audit trail stops being anonymous.

How Horse Labs handles it

At Horse Labs, the caller uses a virtual key — not the provider's key — validated at the gateway layer. That key carries the access profile: allowed models, budget, and identity for the per-user spend trail. Each provider's real key stays in the vault (Vault), delivered to the layer and never exposed to the caller. So access control, cost control, and traceability come from the credential itself, instead of depending on good conduct in using a shared secret.

Nuance

The virtual key only delivers what it promises if the real key is truly out of reach. If the provider can still be called directly, through a path that doesn't go through the layer, the virtual key becomes theater: the disciplined user uses it, and whoever wants to escape goes straight. That's why the virtual key isn't a standalone feature, but the counterpart of the gateway as the single path. One only makes sense with the other — a scoped credential on one side, a mandatory point of passage on the other.