Bring your own Azure AI Foundry

Every Strata organization routes its AI requests through its own Azure AI Foundry. Strata orchestrates against the Foundry deployment in your own Azure tenant — there is no shared Kronisys engine in the path.

The AI engine lives at Organization → AI engine (/admin/ai-engine). Configuring it requires the Manage AI provider key permission (canManageFoundry) — a separate, Owner-reserved capability from general org-settings management. An admin without it who follows a link there sees the section's name, whether your organization's AI is connected, and which permission to ask an owner for.

How Strata uses your Foundry

Strata does not run a shared inference engine for your data. Every organization connects its own Azure AI Foundry, and Strata orchestrates against the deployments in your own Azure tenant. Inference for chat, agents, documents, voice and the API stays in your Foundry — no prompt and no data from those features is sent to a Kronisys-controlled model. The in-product help assistant is the sole exception: Kronisys hosts and pays for it, so you can ask for help before your Foundry is connected. It receives only your question, your earlier messages to it, your first name, and which page you are on — never your Strata conversations, your files, or anything from a connected system.

What that means in practice:

• Every AI request (chat, scheduled agents, voice mode, title generation) is routed to your endpoint.
• The API key you provide is sent over TLS to verify it, then stored encrypted with AES-256-GCM in your organization's row. It is never persisted in plaintext and never displayed back — once saved, the field shows only a masked placeholder.
• Token billing lands on your Azure subscription's Foundry resource.
• There is no fallback. A bad endpoint, a rejected key, or an outage in your Foundry takes down every AI feature for your members at once — Strata never routes around your Foundry, because there is no other engine to route to. The in-product help assistant is the one thing that keeps working, because Kronisys hosts it: you can still ask for help while your Foundry is down or before it is connected.
• You can swap to a different Foundry at any time from the panel. (Operators can clear the configuration on request for onboarding migration scenarios.)

Because inference runs entirely in your own tenant, your team owns Foundry health and key rotation. Make sure both are in hand before your members start using Strata.

Required model deployments

Strata draws its models from a central, Kronisys-curated Model Catalog spanning several providers — OpenAI, Anthropic, xAI, DeepSeek, Mistral AI, Cohere, and Microsoft — all served through Azure AI Foundry. Your organization enables the subset it wants from that catalog under Organization → Models → Model Catalog (click Manage models). The enabled set is what the verify probe checks.

When you run your own Foundry, every model your organization has enabled must be deployed in that Foundry, and each Foundry deployment name must match the name Strata expects for that model exactly. Because the catalog is curated centrally by Kronisys, the required deployment names ship with the catalog rather than being something you choose — confirm the exact names for your enabled models with Kronisys support before you deploy.

Models route by provider, but both routes share one API key:

• OpenAI, xAI, DeepSeek, Mistral, Cohere, and Microsoft models go through the OpenAI-compatible /openai/v1 route.
• Anthropic (Claude) models go through /anthropic.

Note

If your members use voice mode, your Foundry must also host the realtime, transcription, and speech (text-to-speech) deployments your organization has enabled. The Knowledge Base likewise needs the text-embedding deployments. Deploy those alongside your chat models — those features fail at runtime if their deployments are missing.

If an enabled model is not deployed in your Foundry, the verify probe reports it as missing. That does not block connecting: the configuration is saved as soon as the endpoint is reachable and the key is accepted, and the result under the form says how many enabled models still need a deployment, with a link to Models.

Connecting your Foundry

The steps below deploy each model by hand in the Azure portal. If you would rather not do that, Strata can provision the required deployments into your Foundry for you — see Autonomous Foundry deployment.

1. In a separate tab, deploy every required model into your Azure AI Foundry resource (Azure portal → AI Foundry → your resource → Deployments).
2. Note your Foundry endpoint — the base URL of the resource, for example https://your-resource.services.ai.azure.com.
3. Note one API key for the resource (works for both /openai/v1 and /anthropic routes).
4. In Strata, open Organization → AI engine.
5. Click Connect your own Foundry… (or Change AI engine… if you are swapping).
6. Paste the endpoint into Foundry endpoint and the key into API key.
7. Click Verify & save.
8. Confirm the step-up dialog by typing your organization's name, then confirm.

Strata runs the verification probe synchronously before saving. The probe:

1. Validates the endpoint URL. Must be https:// and resolve to a public Azure AI Foundry host — private or internal addresses are rejected.
2. Calls models.list() against <endpoint>/openai/v1 with your key. Confirms the endpoint is reachable and the key is accepted.
3. For each enabled chat model, sends a 1-token ping to the matching deployment — OpenAI-compatible models through chat.completions.create, Anthropic models through messages.create. For enabled non-chat models (voice, transcription, embeddings), it checks that the deployment appears in the models.list() response.
4. Returns a list of checks (each with label, ok, detail) and a missing array of models that did not respond.

If the endpoint or the key fails its check, the configuration is not saved. The reason appears under the field that failed, which is marked with a red ×; the other field is left alone, and editing the failed field clears its reason. A refusal that is about neither field (too many verifications in a minute, for example) appears above the buttons. While the check runs, both fields and both buttons are locked.

Once the endpoint and the key pass, the configuration is committed and the model-status cache is busted. The page does not reload: the status card updates in place with the new endpoint, today's date and how many enabled models are deployed, and Done closes the form. The server that saved the change uses it for the very next AI request; Strata's other servers pick it up within five minutes.

Alert

Connecting or changing the Foundry re-points every chat and every scheduled agent at once, with no fallback. Because the blast radius is org-wide, Strata requires a step-up confirmation (typing the organization name) before it saves, and the change is audit-logged.

Health monitoring

After your Foundry is connected, Strata caches the per-model deployment status for 15 minutes (FOUNDRY_MODEL_STATUS_TTL). Three paths re-check:

• The AI engine page — when you open Organization → AI engine, its status card reads, for example, "9 of 12 enabled models are deployed here", with a link to Models. If Strata can no longer use the stored connection (the key no longer decrypts, or the host is no longer allowed), or your Foundry does not answer, the card's title says so — "Strata can't use your Azure AI Foundry" or "Strata can't reach your Azure AI Foundry" — and the Models line gives the reason in red. The check runs when you open the page, never on page load elsewhere, and uses the same 15-minute cache.
• The chat and Agents page check — once per browser session, the first time an admin who holds Manage AI provider key opens chat or the Agents page, Strata checks your enabled models (cached) and shows a sticky AI Foundry — action needed toast naming any that aren't deployed, or saying your Foundry can't be reached.
• Enabling a model — before a model is switched on in the Model Catalog, Strata checks, fresh, that it is deployed in your Foundry. If it is not, the model stays off and the catalog says why.

Strata does not poll your Foundry on an interval. If your Foundry goes down between probes, users will see live 401, 404, or 5xx errors from chat — the same way they would from any external dependency outage.

Changing the endpoint or key

Click Change AI engine… on the AI engine page. The stored key is never displayed — the status card shows it only as masked dots (••••••••…), and the form's key field starts empty — so you must paste the key again to save any change. This is by design — there is no key-export path. Cancel closes the form and discards what you typed.

The type-to-confirm dialog repeats what the change does before you confirm it: every chat and scheduled agent moves to the endpoint and key you entered, a wrong one takes down every AI feature for every member at once, and there is no shared fallback.

The re-verify probe runs again before the change is committed. A failed re-verify keeps the old configuration in place.

Deployment names

If your Foundry names the voice (realtime), transcription or embedding deployment differently from the setup guide, enter that name under Deployment names on the AI engine page and click Save deployment names. A blank field uses the standard name.

• The names save on their own: no API key and no typed confirmation. Renaming a deployment affects voice mode and knowledge search, not every AI request, so it does not need the step-up that changing the endpoint or key does.
• Every change is recorded in the audit log as org.foundry.deployments_updated, with each name before and after.
• A name can be up to 120 characters. A longer name, or one with a tab, line break or other control character, is refused on its own row instead of being shortened, and the other names still save.
• The section appears once your organization's own Foundry is connected. The organization that operates Strata runs on the platform Foundry, whose deployment names are set by the deployment itself.
• Leaving the page with an unsaved name asks before discarding it.

What you cannot do from the UI

• Disconnect your Foundry from the UI. The panel offers swap-to-another-Foundry only — there is no shared Kronisys engine to fall back to. Contact Kronisys support (support@kronisys.com) if you need the configuration cleared for a migration.
• Decrypt or export the stored key. Lost the key? Rotate it in Azure, then paste the new value in the panel.
• Probe arbitrary models. Only the models your organization has enabled are probed. Enable a model first in the Model Catalog (Models → Manage models) to verify it.

During onboarding and after

Step 6 of the organization onboarding wizard is AI Engine, and connecting your own Foundry there is required — you finish onboarding with your Foundry in place before any member uses Strata. That is the cleanest cutover.

Afterward, you use the same panel to swap the endpoint or rotate the key. Because any change re-points every active member at once, pick a low-activity window and have the new Foundry warm before you switch.

What can go wrong

See Organization for the Model Catalog, where you enable the models that the verify probe checks, and Usage for how spend on your own Foundry reconciles to your Azure bill.

Related

• Organization
• Models — the Model Catalog and how members pick a model
• Autonomous Foundry deployment — let Strata provision the deployments for you
• Usage
• Onboarding your organization