Choosing the runner AI provider

A CloudRadial AutomationAI runner calls an AI provider for its AI activities. By default that is the bundled private Azure AI Foundry, but you can point it at four other providers instead. This article explains the options, the settings each one needs, and how to switch an existing runner without redeploying it. It is for the technician operating a runner.

In this article:

• The five providers
• Foundry, the default
• The AI-provider Key Vault secrets
• Switching an existing runner
• Egress and endpoint overrides

The Five Providers

Set the ai-provider secret to one of these values:

The two Foundry options keep AI traffic inside your own Azure environment and store no key at all, because the runner authenticates as itself. The three key-based providers call the vendor over the public internet.

Foundry, the Default

By default the runners call the bundled private Azure AI Foundry account, authenticated by the runner’s managed identity. The Foundry account is reachable only through a private endpoint, so all AI traffic stays inside the runner’s virtual network with no internet egress, and there is no API key to manage. This is the recommended posture for most installs.

foundry-claude works the same way — same private networking, same managed-identity sign-in — and differs only in the model family it targets. Use it when you want Claude models but do not want AI traffic leaving your Azure environment.

The AI-Provider Key Vault Secrets

All of the AI-provider configuration lives as plain secrets in the shared runner Key Vault. Each key-based provider has its own set of secrets and never reuses another provider’s endpoint or credentials:

An -endpoint secret is optional. Leave it empty and the runner uses the vendor’s documented default; set it to route through your own gateway or proxy instead. To edit these secrets you need the Key Vault Secrets Officer role on the vault and network access to its private endpoint. Because the vault is private, the installer can offer to allow your machine’s IP on the vault firewall at the end of a deploy; otherwise edit the secrets from a host on the runner virtual network or a peered network.

Switching an Existing Runner

Use these steps to move an already-deployed runner from one provider to another without redeploying it.

1. Seed the new provider’s key and model secrets first, so the runner never selects a provider it has no credentials for.
2. Set the ai-provider secret to the new value.
3. Stop the runner’s Function Apps, wait at least five minutes, then start them again.

The runner reads ai-provider from Key Vault on each run rather than caching it at startup, so the provider switch itself takes effect on the next run. The key and model secrets are a different matter: those are read as Key Vault references when the process starts and are cached for its lifetime. No redeploy is needed, and the runner’s identity, secret, and networking are untouched. The runner’s README.md includes the exact PowerShell commands for setting each secret and restarting the apps.

Egress and Endpoint Overrides

Important -> If your runner egress is locked down, allow the provider’s host before you switch, or the runners will fail to reach it: api.openai.com for OpenAI, api.anthropic.com for Anthropic, openrouter.ai for OpenRouter. If you set an -endpoint override, allow that host instead. See Runner network and egress requirements.

If a runner cannot read its endpoint override at the moment it needs it, it fails the call rather than falling back to the vendor’s public endpoint, so a transient fault can never send your prompt somewhere you did not choose.

With the provider chosen, you are ready to register the runner. Next: Registering and managing runners.

If you are still having trouble, we’re here to help! Submit a ticket here for assistance, and don’t forget to check our status page to ensure there are no outages in your area.