Currently, model configuration and model keys are statically defined in the .env file, requiring manual entry for every deployed LLM and storing sensitive information locally. This reduces flexibility and introduces security and usability risks.
This issue proposes migrating to a dynamic solution for model discovery and selection by integrating AzulClaw directly with Azure Foundry and using Entra ID authentication to identify the user's tenant/subscription and enumerate the deployments they are authorized to access.
Goals
- Remove the need to hardcode model names, deployment IDs, endpoints, or secrets in local
.env files.
- Connect AzulClaw to Azure Foundry and automatically discover available deployed models for the authenticated user/subscription.
- Provide a simple UI for selecting which discovered model(s) AzulClaw should use.
- Use enterprise-grade authentication via Microsoft Entra ID (interactive sign-in for desktop; optional enterprise automation flows later).
Why this matters
- Security:
.env-based secrets and endpoints are too easy to leak (commits, logs, backups, screenshots).
- Maintainability: Adding a new model deployment today requires manual edits and documentation. Auto-discovery makes new models “just appear”.
- Enterprise readiness: Aligns with the “business-level security on Azure” positioning of AzulClaw.
Azure / Entra ID requirements
- Add Entra ID authentication so AzulClaw can:
- Identify the signed-in user/tenant
- Enumerate accessible subscriptions (if user has multiple)
- Select a subscription and (optionally) a resource group / Foundry project/workspace
- The app must only display Foundry models/deployments the user is authorized to see.
- Document required Azure roles/permissions for the user/app to:
- List Foundry resources / model deployments
- Invoke selected deployments at runtime
- Tokens must be handled securely:
- Never stored in plaintext
- Prefer OS secure storage (Keychain/Windows Credential Manager/etc.) where applicable
- Clear sign-out flow
UX/UI requirements (azul_desktop)
- Add configuration flow in:
- Initial wizard (first-run onboarding)
- Skills/Settings page (ongoing management)
- UI flow should include:
- “Sign in with Microsoft” (Entra ID)
- Subscription selection (if multiple)
- Foundry workspace/project selection (if applicable)
- Model deployment discovery list
- Model selection + confirmation (single active model initially; allow future multi-model)
- Display useful metadata per model (as available):
- Deployment name
- Model family/version
- Region
- Any relevant capabilities/limits if available
Backend requirements
- Implement a “Model Discovery” service that:
- Uses Entra ID access tokens to query Azure/Foundry
- Fetches and caches the list of deployments
- Exposes a stable internal representation (id, name, type, endpoint reference, region)
- Refactor runtime model invocation to use the selected deployment from the discovered list.
- Ensure graceful failure modes:
- Auth failure / expired token → prompt re-auth
- No subscriptions found / insufficient permissions → actionable error
- No deployments found → guidance to deploy a model in Foundry
Acceptance criteria
- AzulClaw lists models from Azure Foundry dynamically (no manual
.env model entries).
- Users can select/change the model from the UI without editing files.
- Entra ID authentication is required for Foundry discovery.
- No secrets, tokens, or model endpoints are persisted in plaintext.
- Documentation exists for:
- Setup prerequisites
- Required Azure permissions
- Migration from
.env to Foundry/Entra-based discovery
Deliverables
- Backend implementation for Foundry discovery + secure auth integration
- Frontend flows (wizard + settings/skills tab)
- Updated documentation and migration guide
Implementing this will make AzulClaw more secure, more enterprise-aligned, and significantly easier to extend with new models and deployments over time.
Currently, model configuration and model keys are statically defined in the
.envfile, requiring manual entry for every deployed LLM and storing sensitive information locally. This reduces flexibility and introduces security and usability risks.This issue proposes migrating to a dynamic solution for model discovery and selection by integrating AzulClaw directly with Azure Foundry and using Entra ID authentication to identify the user's tenant/subscription and enumerate the deployments they are authorized to access.
Goals
.envfiles.Why this matters
.env-based secrets and endpoints are too easy to leak (commits, logs, backups, screenshots).Azure / Entra ID requirements
UX/UI requirements (azul_desktop)
Backend requirements
Acceptance criteria
.envmodel entries)..envto Foundry/Entra-based discoveryDeliverables
Implementing this will make AzulClaw more secure, more enterprise-aligned, and significantly easier to extend with new models and deployments over time.