Bringing your own AI provider

By default Sentinel-Q runs on the model endpoint Qorionix operates, and your usage is metered against a daily spend limit we set. You can replace that with your own provider account and your own API key. This article is the whole surface: the four providers you can choose, the fields each one needs, the one provider that is listed and refused, and the several ways this configuration can go wrong in a manner worth understanding before you commit to it.

The page is Settings › AI provider at /settings/ai-provider. Reading it requires ai:provider.read and changing it requires ai:provider.write. Both are granted to the admin role only — including the read. That is deliberate, and the reason is written into the migration that seeds it: a read returns your vendor, your endpoint hostname and the last four characters of your key, and "this company runs its security AI on their own Azure resource in Sweden, and here are the last four characters of the key" is reconnaissance rather than configuration. If you get a 403 here, ask for ai:provider.read; nobody below an administrator has it by default.

The four providers you can configure

These are the exact identifier strings the API stores and returns. The console shows friendlier labels, but if you are calling the API these are the values.

A fifth value, platform, is not a provider — it is the absence of one. Selecting it deletes your configuration row and the sealed credential inside it, and returns you to the Qorionix-managed endpoint. The console calls that button Return to Qorionix's provider. Aliases are accepted on input, so claude reads as anthropic, azure, aoai and foundry all read as azure-openai, and gemini, google, vertex and vertexai all read as google-gemini.

Amazon Bedrock is listed, and refused

Bedrock appears in the provider catalogue with supported: false. It is there so that the refusal names it rather than answering "unsupported provider" and leaving you guessing whether you spelled it wrong.

That is a real reason and not a euphemism for unfinished. A working Bedrock client exists in the platform and is used as a deployment-wide provider; what is refused is the per-tenant form of it, because this table would then hold a pair of long-lived AWS access keys per customer. The refusal is 400, with the error code invalid_configuration.

The API key: how it is stored, and the one thing you cannot get back

The key is sealed with the same envelope encryption the platform uses for privileged credentials, under its own wrapping-key namespace, and the ciphertext columns are marked so that no serialisation path can emit them. Only a four-character tail is kept for display, shown as …abcd.

One deployment-level condition to know about. If the running deployment has no encryption key material configured, storing a provider credential is refused outright rather than falling back to plaintext. You will see 503 with the code no_encryption_key, and the console disables the form and says so: This deployment has no encryption key configured, so a provider credential cannot be stored. Contact your operator. A read model field, can_store_credential, exists precisely so the interface can grey the field out before you paste a secret into it.

If the key material later changes underneath a stored credential — a cell rebuild, a key rotation that lost the old wrapping key — the failure is named rather than generic: the stored credential could not be decrypted with this cell's key material; re-enter the API key.

The validation you will meet, verbatim

These checks run before anything is stored and before any network call is made, so they are fast and they cost nothing. They are quoted because each one names its own fix.

a deployment name is required for Azure OpenAI (the name you gave the
  deployment in the portal, not a model id)

the Azure OpenAI resource endpoint is required, e.g.
  https://<resource>.openai.azure.com

"..." is not an Azure OpenAI endpoint. Expected *.openai.azure.com,
  *.services.ai.azure.com or *.cognitiveservices.azure.com

the endpoint must be an https URL; a plaintext endpoint would carry your
  API key and your security telemetry in the clear

a model id is required

inference geography "..." is not one of eu, us, global

"..." is not a deployment type this platform knows. Expected
  GlobalStandard, DataZoneStandard, Standard, Developer or
  ProvisionedManaged

http://localhost and http://127.0.0.1 are the two exceptions to the HTTPS rule, for a locally hosted gateway. Everything else must be https.

Testing the connection

The Test connection button calls POST /api/v1/ai/provider/verify. It makes one real request to your provider: a sixteen-token completion whose entire prompt is Reply with the single word: ok. It is metered like any other call, which is why it is gated on ai:provider.write rather than read — a read permission must not be able to cause a charge on your account, however small.

A success reports which provider and model answered, and two things worth reading rather than skipping.

• Whether usage was reported. If your provider answered without token counts, the console says so: The provider answered without reporting token usage, so calls on this configuration cannot be metered. Your consumption figures will be incomplete. Everything still works; your cost figures in Qorionix will simply be wrong, and your provider's invoice remains the authority.
• Whether the model can make structured tool calls. This is the important one, and it is covered next.

When your key stops working, nothing takes over

This is the most important behaviour on the page, and the code says so about itself in those words. If your own provider configuration breaks, AI features stop. They do not fall back to the Qorionix-managed provider.

A silent fallback would be the friendlier engineering choice and the wrong product. You chose your provider for a reason — cost, a contract, a data-processing agreement, a jurisdiction — and quietly sending your alert text somewhere else because a key expired would break all four of those without a notification. So the failure is loud and local: the configuration records last_error and last_error_at, the console shows Your AI provider credential is not working, and the deterministic parts of the platform carry on unaffected.

Worth stating plainly what "carry on unaffected" covers, because it is more than people expect. The posture assessment is deterministic checks and never calls a model. The detection library is rules. The evidence bundle and the audit chain are queries over your own data. An expired AI key is a degradation, not an outage.

Who pays, and what the daily cap means

The cap exists in both configurations and means two different things, which the console labels distinctly.

On the Qorionix-managed provider — a spend limit

We are paying, so the cap is a real budget. It defaults to 12 US dollars per day per tenant, and the platform degrades rather than stopping when it approaches it: at 75% the assistant switches to a cheaper model, cuts its output ceiling and limits an investigation to four tool rounds. Past the cap, requests are refused with 429 and a Retry-After pointing at the next UTC day.

On your own provider — a runaway guard

You are paying, so a low cap would be us rationing your own account. It defaults to 250 US dollars per day and exists only to stop a loop billing you thousands overnight. A tenant on its own provider is not model-swapped when it approaches the cap, because swapping the model you chose is not ours to do.

Cost figures for a bring-your-own configuration are labelled honestly in the product: estimated at the provider's published list price; your own invoice is authoritative. We do not see your contract, your committed-use discount or your enterprise agreement, so treat the number as an order of magnitude. What an investigation costs goes into the metering in detail.

The residency consequence, in one paragraph

Choosing a provider chooses a geography, and the platform refuses a configuration whose geography it cannot establish inside the EU or EEA unless somebody named accepts that in writing on the page. That is a long enough subject to have its own article, and you should read it before you configure anything: AI inference, and where it actually runs. The two-sentence version is that the endpoint URL is the evidence — a regional Vertex AI host or OpenAI's European host establishes a place, api.openai.com does not, and direct Anthropic cannot, because Anthropic publishes only global and US inference geographies.

What to do next

1. Read AI inference, and where it actually runs first if data residency matters to you. It will save you configuring something the platform then refuses.
2. Open Settings › AI provider, choose the provider, paste the key, and press Test connection before you leave the page. Read the tool-use line in the result.
3. Set a spend alert in your provider's own console. The 250-dollar guard here is a backstop, not a budget, and your provider is better placed to tell you about a surprise than we are.
4. What an investigation costs — what actually consumes tokens, so the bill is legible.