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 panel lives at Admin → AI Engine. Configuring it requires the Manage AI provider key permission (canManageFoundry) — a separate, Owner-reserved capability from general org-settings management.

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 stays in your Foundry — no prompt, no data, and no PHI is ever sent to a Kronisys-controlled model.

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 settings → Models → Model Catalog (click Open the catalog). 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 and saving the configuration is blocked.

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 Admin → AI Engine.
5. Click Connect your own Foundry… (or Change AI engine configuration… 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 any check fails, the configuration is not saved. The UI shows a red X on the failing field and the toast carries the failure detail. Editing either field after a failed verify clears the X.

If every check passes, the configuration is committed, the model-status cache is busted, and Strata routes the very next AI request to your Foundry.

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). Two paths re-check:

• The org chat view check — runs against your enabled models, cached. Drives the sticky warning toast (shown to admins only) that appears when a model is missing.
• The Org Settings re-check — runs every time you enable a model in the Model Catalog modal, always fresh. If you enable a model that is not deployed, a sticky error toast tells you to deploy it before members rely on it: "<model> is not deployed in your Azure AI Foundry. Deploy it there before members rely on it — until then it will fail at runtime."

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 configuration… under the AI Engine panel. The stored key is never displayed — the connected-status view shows it only as masked dots (••••••••…), and the edit field starts empty — so you must paste the key again to save any change. This is by design — there is no key-export path.

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

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 → Model Catalog → Open the catalog) 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 settings 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 settings
• Models — the Model Catalog and how members pick a model
• Autonomous Foundry deployment — let Strata provision the deployments for you
• Usage
• Onboarding your organization