export AZURE_AI_FOUNDRY_API_KEY="your-key"
 And in ~/.openclaw/openclaw.json:
 {
  "models": {
    "providers": {
      "azure-ai-foundry": {
        "baseUrl": "https://your-resource.services.ai.azure.com/anthropic/",
        "apiKey": "env:AZURE_AI_FOUNDRY_API_KEY",
        "headers": {
          "x-api-key": "env:AZURE_AI_FOUNDRY_API_KEY"
        }
      }
    }
  }
}

<!-- greptile_comment -->

<h2>Greptile Overview</h2>

<h3>Greptile Summary</h3>

This PR adds environment-variable based credential resolution for a new `azure-ai-foundry` provider (preferring `AZURE_AI_FOUNDRY_API_KEY` and falling back to `AZURE_OPENAI_API_KEY`), and updates the provider-to-env-var mapping used for automatic detection. It also includes purely formatting/markdown cleanup in the security threat model docs.

The main logic change lives in `src/agents/model-auth.ts`, which is responsible for resolving provider auth from (in order) explicit profile selection, auth-profile store order, environment variables, and config (`models.json`).

<h3>Confidence Score: 3/5</h3>

- Not safe to merge until auth mode detection for env-based OAuth is fixed.
- While the Azure AI Foundry env var support looks straightforward, the PR also introduces a regression/bug in how env-sourced OAuth is detected (string match against the formatted `source` label). This will misreport OAuth as api-key and can break providers that rely on OAuth token handling.
- src/agents/model-auth.ts

<!-- greptile_other_comments_section -->

<sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub>

<!-- /greptile_comment -->