BUILDING Parts of this page describe what is not built yet, and each says so.
AI providers
A provider is an AI service your organisation brings, such as Anthropic, OpenAI or a server of your own that speaks the OpenAI protocol. Setting one up has two parts, and they are kept apart on purpose: the key, which is a secret, and the connection, which is not.
Two parts: the key and the connection
| Part | What it holds | Where it lives | Who changes it |
|---|---|---|---|
| The key | The secret your provider gave you, kept under a name you choose. | RunningLake's control plane, sealed, for now. | An owner or an admin, in the console, with a confirmation from the last five minutes. An API token cannot. |
| The connection | The kind of provider, the name of the key it signs in with, its address and region, and the models it offers with your price for each. | A file kept with the project's configuration, providerconnections/<name>.yaml. |
A change set that an owner or an admin approves. |
A connection never holds a key. It names one, and a file that carries something shaped like a key is refused.
The store that holds a key runs on RunningLake's QA control plane only, until a key-management provider exists. A control plane that has not been given a sealing key cannot hold one, and the console says so where a key would be added.
Adding a key
Where the store runs, in AI settings, Providers, choose Add a provider. You choose the kind, name the connection and its address, and enter the key in the one field that takes it. The key is sealed when it arrives and is not in any address, log or response. Nothing in the product shows it again, but the process that calls your provider can open it. RunningLake holds it only until your cloud's own secret store can, and says so on the page; revoking it at your provider is the only real way to stop its use. An organisation on a trial or in HIPAA mode cannot add one here; in HIPAA mode because a prompt sent with a key held by RunningLake would pass through RunningLake. A key can be stored today for Anthropic, OpenAI and servers that speak the OpenAI protocol. A key for Gemini or Azure OpenAI is not offered yet, and the kinds that sign in through your cloud's own identity have no key to store. The table of kinds below lists every kind a connection file can name, including those whose keys cannot be stored yet.
Testing, replacing and removing a key
- Test opens the stored key and sends it to your provider in a request that asks for the provider's list of models, and tells you how it ended in a word. It never shows what the provider said. ok means the provider answered and accepted the key; it does not prove the key can run a model. For a server that is not the provider's own host, an ok is followed by one more request that carries no key. If the server answers that as it answered the first, the answer says: The server did not ask for the key: it answered a request that carried none as it answered the one that did. So ok here means a server answered, not that the key is right. A server of your own may meter or throttle the request. A person presses it; nothing tests a key on its own. It is limited, per key and per organisation, in how often it can be pressed.
- Replace adds the new key beside the old one, so a changeover has no gap. A key holds two at most. Test the new one, then retire the old: retiring empties that one key, keeps the credential and the other key, and cannot be undone. Retiring the newer of the two is the way back from a replacement that turned out wrong. The only key a credential holds cannot be retired; that is removal.
- Remove empties every key under the name. Emptied is a logical change, not an erasure, so revoke the key at your provider to stop its use. It is refused while any connection, in any project of the organisation, still names the key, and says which.
Each of these is written to the organisation's audit record with who did it and which key (its keyed fingerprint, never any part of it).
Declaring the connection
The last step of Add a provider builds the connection from the key you just saved and the models you list, and opens the Changes page with it filled in. Nothing is planned or saved until you plan it there. The fields:
| Field | What it says |
|---|---|
provider | The kind: anthropic, openai, openai_compatible, google_gemini, azure_openai, bedrock or vertex. |
credential | The name of the stored key. A kind that signs in with your cloud's own identity (Bedrock, Vertex) names none. |
origin | The address, https://host. Needed for an OpenAI-compatible server and Azure; the other kinds are reached at their own address. |
region | The provider's region, as the provider spells it. |
models | One to fifty models, each with an id and, if you want calls priced, priceMicroCents for input, output, cacheRead and cacheWrite. |
A price is what a million units cost, in micro-cents (a millionth of a cent) and as a whole number: one dollar for a million tokens is 100000000. A price left out is unset, which is not free. The console takes dollars and converts them exactly.
Every change to a connection waits for an owner or an admin to approve it, in any environment, because a connection decides where a key may be sent. An agent can read connections and cannot propose one. When the change is planned, the control plane checks that the key you name is for the same kind of provider and the same address, and that the address can be called. The field-by-field reference is on ProviderConnection.
Reading it from the command line
rl model providers lists the connections a project declares: the provider, the name of the key, the
address, the region and how many models each offers. rl model provider <name> prints one connection
with its models and what each costs, in dollars for a million units; a dash is a price left unset. -project and
-env name where to read, and -o json prints the response as one JSON document.
The commands print a key's name and never a key, and none of their flags can carry one. They do not print the state of a key (stored, tested, replaced): a command-line credential is not given that, which is why a token left in a pipeline cannot read what a person at the console may. They exit 0 when the connections were printed, 1 when the control plane refused the read, and 2 when nothing was read. The rest of the command line is on The rl command line.
What this page leaves out
It describes setting a provider up and reading it where the key store runs, which is QA. Where it does not run, which is every production control plane, there is no key to add, and this page describes nothing to do there. It does not describe a model call going through a connection, because none does yet, nor keyless access through your cloud's own identity, nor routes that choose a connection for a task.