Migrate secrets management from .env files to Azure Key Vault

[Javierif]

AzulClaw aims to provide business-grade security on Azure. Storing secrets in local .env files (even for development) is a critical security weakness and makes it easier to leak credentials accidentally (git commits, logs, screenshots, backups, etc.).

This issue proposes migrating all sensitive configuration (API keys, client secrets, connection strings, tokens, etc.) to Azure Key Vault, using secure connections and least-privilege access patterns.

Goals

• Remove the need to store secrets in .env files for normal operation.
• Use Azure Key Vault as the source of truth for secrets.
• Ensure secure retrieval (TLS, identity-based auth) and auditable access.
• Keep the developer experience reasonable (local dev story), without compromising security.

Scope / Requirements

Backend

• Identify all secrets currently loaded from .env (Azure OpenAI keys, MCP-related secrets, any third-party integrations, etc.).
• Add a Key Vault provider / client to retrieve secrets at runtime.
• Prefer managed identity where applicable; otherwise support service principal auth (Entra ID) with minimal permissions.
• Implement caching/refresh strategy if needed (avoid fetching secrets on every request).
• Add robust error handling:
  • Clear startup failure if required secrets are missing
  • Non-sensitive logging (never log secret values)

Frontend / Desktop config (if applicable)

• Add configuration fields needed to connect to Key Vault (e.g., vault URI, auth mode) without exposing secrets in the UI.
• Validate configuration and show actionable errors.

Security Requirements

• Least privilege: restrict Key Vault permissions to only the secrets required by AzulClaw.
• Never persist secrets unencrypted on disk.
• Ensure secrets are not included in telemetry/logging.
• Document recommended Key Vault policies / RBAC roles.

Deliverables

• Code changes to support Key Vault-based secrets loading.
• Documentation:
  • How to provision a Key Vault for AzulClaw
  • How to set access (Managed Identity / Entra ID)
  • Migration notes from .env to Key Vault
• Optional: Provide a safe fallback for local dev (e.g., .env allowed only when an explicit ALLOW_INSECURE_LOCAL_SECRETS=true flag is set), clearly documented.

Acceptance Criteria

• AzulClaw can run with secrets sourced from Azure Key Vault.
• No required secret needs to exist in .env in production scenarios.
• Secrets are never logged or written to disk in plaintext.