Azure OpenAI, Signed In With Microsoft
Until now, connecting Azure OpenAI to AICoven meant pasting an API key, an endpoint and a deployment name, typed exactly as Azure spells it. That works, unless your organisation has switched key authentication off on its Azure AI resources, which the security-conscious ones do. Then there is no key to paste, and the form could never succeed. Azure connections can now use Microsoft Entra ID instead.
Available in AICoven 3.1.0, out next week.
Two ways to sign in
The Azure OpenAI form now starts with Authentication: API Key or Microsoft Entra ID. It's chosen per connection, so a key-based resource and an Entra-only one can sit side by side. The API-key path is unchanged.
With Entra, there is no key at all. AICoven shows a Microsoft code, which you can Copy, and a link to Open Microsoft Sign In. Sign in with an account that can use the resource, enter the code, and AICoven finishes the connection. The Application (client) ID comes pre-filled with AICoven's own app registration, which has no client secret. If your administrator would rather you use your organisation's own registration, that field takes it instead.
Let AICoven find the deployment
The part of Azure setup I like least is hunting through the portal for the exact deployment name. With Entra selected, the form offers Find my Azure deployments. Enter your Tenant ID, choose Sign in with Microsoft, and AICoven reads what your account can see: pick a Subscription, then a Resource, then a Deployment, each shown with the model behind it. Every list follows all of Azure's pages, and an error partway through shows as an error, not a shorter list pretending to be complete.
Use Deployment fills in the endpoint and deployment, then asks you to sign in a second time. That is not indecision. Microsoft treats "read my Azure resources" and "call this model" as separate permissions, so AICoven asks for each one on its own, and finding your deployments never quietly grants access to call them.
Discovery only reads. It doesn't retrieve resource keys, change anything in Azure, register applications or assign roles, and it doesn't keep the management sign-in once you've chosen a deployment.
To type it yourself, leave discovery off. The form says what it needs: "Enter the Azure resource, deployment, tenant ID, and public-client app ID, then sign in with Microsoft."
Where the sign-in lives
AICoven's API does the exchange with Microsoft, and the resulting tokens are stored encrypted as that connection's credential, the same place an API key would go. They are refreshed when a request needs them, which is why a connection keeps working for agents and automations when the app isn't open. Your messages still go through AICoven's API on their way to Azure, as they do for every cloud provider. When Microsoft stops accepting the sign-in, the error in chat points you to reconnect in Provider Keys, and Sign In Again reconnects the same connection rather than making you start over.
One connection, one deployment
Each Azure connection holds one deployment. That's deliberate, and Vertex and Bedrock work the same way: one enterprise credential, one model you chose. If you use three deployments, you add three connections. Slightly tedious, entirely predictable.
Cost estimates, if you tell us one thing
Azure bills a deployment by its type, and neither the endpoint nor the response says which type it is. So there is now an optional Deployment type: Not set, Global Standard, Data Zone (US) or Data Zone (EU). The form is plain about the trade: "Deployment type is optional. It lets AICoven estimate costs for this connection; Regional and Provisioned deployments have no estimate, so costs show as unknown."
Unknown is the honest answer there. A number that looked right and wasn't would be worse than no number.
What I can't promise
- Not every tenant will let you in. Some organisations require an administrator to approve any app before people can sign in to it. If yours does, sign-in stops at Microsoft, and there is nothing AICoven can do from this side; your administrator can approve it or give you their own app ID. You also need permission to read your subscriptions and resources for discovery to find anything.
- Azure AI Foundry project endpoints aren't supported. Resource endpoints are.
- Sign-ins that don't finish. A sign-in you cancel, let expire or decline at Microsoft leaves nothing half-connected; you can start again from the same form.
If something does go sideways, the API-key path is still one picker away.
Related posts
One Coven per Client: Keeping Accounts, Subscriptions and Repos Apart
My agent opened feature branches in repos that had nothing to do with the feature. With several clients, that's one mistake in three places: whose AI account pays, whose apps get touched, and whose repos get written to. Here's how one coven per client keeps them apart.
Read →A Quieter AICoven, and a Shelf for the Work
The app has been redone around eight plain jobs, and each coven now has an Asset Library: the files, datasets, and images your agents and you make, reviewed, approved, and sent where they need to go.
Read →
About the Author
I'm Andreea, the creator of AICoven. I build local-first tools for developers who care about architecture, privacy, and prompt economics.
See more of my work at papillonmakes.tech →