Skip to content

Keys, teams and budgets

What a client may do once it holds a credential. Three things answer that, and the most common confusion is which of them holds the answer you are looking for.

A key names a profile; the profile supplies four gates, cheapest first

A virtual key is an identity and nothing else, a name, some metadata, an expiry, a revocation, and the name of a profile. A profile is what that identity may do. A budget is what the profile’s traffic draws from. Each is edited once for everyone holding it. That is why a key does not carry its own limits.

This is the data plane. Who may change any of it is a different system with a different language and the opposite default, described in Admin access. Authorization says why the two never meet.

The token is shown once, at mint. After that a key can expire, be suspended, be revoked, or be orphaned by a profile somebody deleted. Those are four different failures with four different fixes. There is no rotate verb, and that changes how rotation has to be done. → Mint, rotate and revoke a virtual key

A profile says which models, which capabilities a channel must keep, which model servers, this team’s own CEL access rules, and which detectors inspect it. Profiles are also where the two rule layers live, and they are the reason those layers run in sequence rather than concatenated. → Give a team its own policy

A windowed allowance in tokens, denominated in whichever token type you are paying for. The default gives every key its own bucket, and one flag pools a whole team into one. → Cap what a team spends

A rule with a typo still compiles, and it will deny somebody the first time it runs. Run your CEL against fixtures in CI instead. → Test your rules before they ship

A governance platform can own the rules it wants enforced, writing them into a configuration source it holds alone, with each rule naming the controls it satisfies. It can then read back a signed record of every decision taken under them. → Connect your AI governance platform

Every variable a CEL condition may read, asked of the engine that evaluates it, is in the policy reference. keys[] is not in the configuration reference, and that is not an omission. Keys are replicated state rather than configuration, so they are minted through the API and never declared in a document.