stacklok · danbarr · Jul 9, 2026 · Jul 9, 2026 · Jul 9, 2026
diff --git a/.claude/skills/weekly-product-updates/SKILL.md b/.claude/skills/weekly-product-updates/SKILL.md
@@ -332,7 +332,7 @@ Flexibility is okay -- not every bullet needs the exact same format if the benef
 
 **The Kubernetes Operator** now supports deploying MCP servers with built-in authentication, eliminating the need for users to manage credentials locally:
 
-- **Embedded authorization server** lets you deploy standalone MCP servers where users authenticate directly to your existing identity provider (like Okta or Azure AD), receiving the appropriate access based on your organization's policies.
+- **Embedded authorization server** lets you deploy standalone MCP servers where users authenticate directly to your existing identity provider (like Okta or Entra ID), receiving the appropriate access based on your organization's policies.
 - **AWS STS token exchange** converts OIDC identity tokens into temporary AWS credentials automatically -- users log in to your company IDP and receive the right AWS IAM role without configuring the AWS CLI or storing credentials on their machine.
 ```
 

diff --git a/AGENTS.md b/AGENTS.md
@@ -230,6 +230,7 @@ ALWAYS use these exact terms and capitalizations. When editing documentation, re
 - open source (not "open-source")
 - large language model (LLM)
 - Visual Studio Code ("VS Code" after first use)
+- Microsoft Entra ID ("Entra ID" after first use; avoid "Azure AD" unless you are quoting a literal API, CLI, or field value)
 - Virtual MCP Server (vMCP) - a feature of ToolHive that aggregates multiple MCP servers into a single endpoint; use "Virtual MCP Server (vMCP)" on first use, "vMCP" thereafter
 - Stacklok Enterprise - the commercial, enterprise-licensed distribution of ToolHive, adding turnkey IdP integration, centralized policy enforcement, hardened and signed releases, and SLA-backed support
 - Stacklok Desktop - the enterprise edition of the ToolHive desktop app, with enterprise lockdown policies controlled by the Enterprise Manager (not "Enterprise UI", "Enterprise Studio", or "Stacklok UI")

diff --git a/STYLE-GUIDE.md b/STYLE-GUIDE.md
@@ -412,6 +412,12 @@ servers into a single endpoint. It's written with a lowercase "v" followed by
 "MC" in all caps and a capital "P" (not "VMCP" or "Vmcp"). Use "Virtual MCP
 Server (vMCP)" on first use, "vMCP" thereafter.
 
+**Microsoft Entra ID**: Microsoft's cloud identity and access management
+platform. Microsoft rebranded it from "Azure AD" (Azure Active Directory) in
+2023, so don't use "Azure AD" except when quoting a literal API, CLI, or field
+value that still uses the old name. Use "Microsoft Entra ID" on first reference,
+"Entra ID" thereafter.
+
 **npm**: The registry for JavaScript packages (the "npm registry"), and the
 default package manager for JavaScript. Since it's both the registry _and_ the
 package manager, it may be useful to disambiguate "the npm registry". It's not

diff --git a/docs/toolhive/_partials/_oidc-prerequisites.mdx b/docs/toolhive/_partials/_oidc-prerequisites.mdx
@@ -3,8 +3,7 @@ Before you begin, make sure you have:
 - ToolHive installed and working
 - Basic familiarity with OAuth, OIDC, and JWT concepts
 - An identity provider that supports OpenID Connect (OIDC), such as Google,
-  GitHub, Microsoft Entra ID (Azure AD), Okta, Auth0, or Kubernetes (for service
-  accounts)
+  GitHub, Microsoft Entra ID, Okta, Auth0, or Kubernetes (for service accounts)
 
 If you're connecting to an external identity provider, the only value you need
 from it is the **issuer URL**. ToolHive uses it to fetch the JWKS automatically

diff --git a/docs/toolhive/concepts/auth-framework.mdx b/docs/toolhive/concepts/auth-framework.mdx
@@ -102,9 +102,9 @@ automatically.
 
 ToolHive uses OAuth-based authentication and accepts access tokens issued by any
 OAuth 2.0 or OIDC-compliant identity provider (IdP), such as Google, GitHub,
-Microsoft Entra ID (Azure AD), Okta, Auth0, or Kubernetes service accounts.
-ToolHive supports both self-contained JWT tokens and opaque tokens (validated
-through introspection), and never handles your raw passwords or credentials.
+Microsoft Entra ID, Okta, Auth0, or Kubernetes service accounts. ToolHive
+supports both self-contained JWT tokens and opaque tokens (validated through
+introspection), and never handles your raw passwords or credentials.
 
 ### Why use OAuth-based authentication?
 
@@ -217,7 +217,7 @@ including:
 
 - Google
 - GitHub
-- Microsoft Entra ID (Azure AD)
+- Entra ID
 - Okta
 - Auth0
 - Kubernetes (service account tokens)

diff --git a/docs/toolhive/guides-registry/authentication.mdx b/docs/toolhive/guides-registry/authentication.mdx
@@ -47,7 +47,8 @@ server supports two token formats:
   non-JWT tokens.
 
 This enables enterprise authentication with providers like Keycloak, Auth0,
-Okta, Azure AD, Kubernetes service accounts, or any OAuth-compliant service.
+Okta, Microsoft Entra ID, Kubernetes service accounts, or any OAuth-compliant
+service.
 
 ### Basic OAuth configuration
 
@@ -289,20 +290,20 @@ For Auth0, the `issuerUrl` is your Auth0 domain. The `audience` should match the
 API identifier configured in your Auth0 dashboard.
 
 </TabItem>
-<TabItem value='azure-ad' label='Azure AD'>
+<TabItem value='entra' label='Entra ID'>
 
 ```yaml
 auth:
   mode: oauth
   oauth:
     resourceUrl: https://registry.example.com
     providers:
-      - name: azure-ad
+      - name: entra
         issuerUrl: https://login.microsoftonline.com/YOUR_TENANT_ID/v2.0
         audience: api://YOUR_CLIENT_ID
 ```
 
-For Azure AD, the `issuerUrl` includes your tenant ID, and the `audience`
+For Entra ID, the `issuerUrl` includes your tenant ID, and the `audience`
 typically uses the `api://` scheme with your application's client ID.
 
 </TabItem>

diff --git a/docs/toolhive/guides-registry/deploy-operator.mdx b/docs/toolhive/guides-registry/deploy-operator.mdx
@@ -617,8 +617,8 @@ anonymous mode in production.**
 :::
 
 For detailed information about authentication configuration, including
-provider-specific examples for Keycloak, Auth0, Azure AD, and Okta, see the
-[Authentication configuration](./authentication.mdx) guide.
+provider-specific examples for Keycloak, Auth0, Microsoft Entra ID, and Okta,
+see the [Authentication configuration](./authentication.mdx) guide.
 
 ## Customize the Registry server pod
 

diff --git a/docs/toolhive/guides-vmcp/embedded-auth-server-vmcp.mdx b/docs/toolhive/guides-vmcp/embedded-auth-server-vmcp.mdx
@@ -266,9 +266,9 @@ for the full pattern and trust-model caveats.
 By default the embedded auth server keys users on the upstream ID token's `sub`
 claim. Some identity providers rotate `sub` per application, so the same user
 appears as a different principal across apps; the stable identifier lives in
-another claim (Entra/Azure AD uses `oid`, some Okta custom auth servers expose a
-custom `uid` claim). Set `subjectClaim` on an upstream's `oidcConfig` to pin
-ToolHive to the stable claim:
+another claim (Microsoft Entra ID uses `oid`, some Okta custom auth servers
+expose a custom `uid` claim). Set `subjectClaim` on an upstream's `oidcConfig`
+to pin ToolHive to the stable claim:
 
 ```yaml
 upstreamProviders: