Skip to main content
Altrum calls model providers with your organization’s own accounts. You pay your providers as you do today. Altrum stores the credentials so your applications never need them: an application holds only an Altrum virtual key.

​
Supported providers

​
Add a credential

Owners and admins open AI Gateway, then Provider credentials, and choose Add credential. Name it, choose the provider and fill in what that provider needs. Under Models, list the models it may serve, or leave it empty for every model. The list shows each credential as In use, Off, or Needs attention with the provider’s reason when the provider refused it.
  • A credential is encrypted when it is stored, and never shown again. The list shows only its last characters.
  • Altrum never writes a credential into a log.
  • To replace a credential, store the new one and remove the old one. Removing asks you to confirm: requests stop using it straight away, and keys that reach that provider only through it fail until you add another.
  • A stored credential can be renamed, switched off, limited to some models and, for Azure and Bedrock, given new model aliases, but its secret cannot be edited.
  • You can store several credentials for one provider, for example for different accounts or regions. Requests to that provider use all of them.
  • The models a credential lists are the models anyone in your organization can reach through it. Each key can narrow them further. See Models and routing.

​
What Altrum refuses to store

Altrum calls a provider from the Altrum network, so it refuses a credential that would reach anything else:
  • An address that is not public: an Azure endpoint must be an https address that anyone on the internet could reach. An address inside a private network, or one that points back at Altrum, is refused.
  • A reference to somewhere else instead of the value itself, such as the name of an environment variable.
  • A credential that relies on the machine Altrum runs on to sign in. A Bedrock credential needs its own API key or access key, a Vertex credential its own service account key, and an Azure credential its own API key or app registration. Altrum never signs in as itself on your behalf.
  • For Vertex, anything other than a service account key.
Each refusal names the field, as the AI Gateway calls it, and what to send instead. For example:

​
Callers’ own credentials

Some teams want an application to send its own provider credential with each request. This is off by default. An owner or admin can switch on Callers may send their own provider key under AI Gateway, Settings, Access. The request sends the header x-alt-direct-key: true, its provider credential in Authorization: Bearer, x-api-key or x-goog-api-key, and its Altrum virtual key in x-alt-vk. A request that sends its own credential must also carry an Altrum virtual key, so Altrum knows which organization it belongs to, and is refused if the organization has not switched this on: A credential sent this way is used for that request only, never stored and never logged. Guardrails, rate limits and logging still apply. Its cost is counted against budgets, but your provider bills the caller’s account.