Friday, 14 August 2026

The article title and heading no longer include “(preview).” No other change is shown.

The page title and heading no longer include “(preview).” No other change is shown, and the diff does not explicitly announce general availability or a product launch.

The documentation now consistently uses “Microsoft Entra ID Auth SDK (sidecar)” and expands “SPA” to “single-page application.” The described authentication flows and responsibilities are otherwise unchanged in the supplied diff.

The local-development article now consistently uses “Microsoft Entra ID Auth SDK (sidecar)” instead of “Microsoft Entra Auth SDK,” including its title, description, intent, link text, and container description.

The documentation now states that replica sets require connectivity between all virtual networks hosting them. They are deployed in one Active Directory site and rely on a fully meshed virtual network topology for directory replication.

The article now explains that agent user accounts are evaluated by user-based membership rules and can join dynamic user groups. By default, they are not distinguished from other user identities; rules can explicitly exclude or include them, including accounts tied to a specific agent identity blueprint.

The tutorial now explains that `{enterprise}` in the GitHub.com SCIM tenant URL is the enterprise slug (account name).

The documentation updates the C# sample’s imports, endpoint structure, downstream API call, and model declarations to provide valid create-agent-identity code.

The documentation adds Microsoft Graph and Microsoft.Identity.Web imports, changes sample calls from Applications to Users, and clarifies that configured scopes must match the Graph resources used. Examples use User.Read and User.ReadBasic.All.

The documentation updates its C# examples, including distinct method names for UPN and object ID calls, a revised controller constructor signature, and clearer user-data method names.

The documentation now identifies app-only tokens as using client credentials, expands on-behalf-of to OBO, and consistently uses the `agent-identity-client-id` placeholder in request examples.

The Amazon Bedrock integration guide now consistently uses “Microsoft Entra ID Auth SDK (sidecar)” in its description, explanations, container reference, and links. No behavior or availability change is described.

The documentation adds an OpenID Connect using directive and renames two C# sample variables: `applications` to `applicationsForUser` and `me` to `meByOid`.

The Agent ID Microsoft Graph documentation now labels sample variables as `usersAppOnly` and `usersOnBehalfOfUser`, clarifying the scenarios they represent.

The documentation replaces “Entra ID Auth SDK” with “Microsoft Entra ID Auth SDK” in two descriptions. The endpoint formats and behavior are unchanged.

The user delegation section now spells out “on-behalf-of (OBO)” on first use. No feature behavior or requirements changed in the supplied diff.

The code sample now uses `<your-tenant-id>` instead of `<your-tenant>` for the `TenantId` value.

The documentation now spells out “on-behalf-of (OBO)” on first use in the token scenario guidance. The referenced method is unchanged.

The `TenantId` example value changed from `<my-test-tenant>` to `<your-tenant-id>` for clearer documentation.

The third-party agents documentation now labels the sidecar setup link “Configure Microsoft Entra ID Auth SDK for agent identities” instead of “Configure Entra ID Auth SDK.”

The documentation now consistently uses `<your-tenant-id>` instead of `<my-test-tenant>` or `<your-test-tenant>` in PowerShell, OAuth URLs, and JSON examples.

The page description was shortened by removing the phrase “Key concepts.” The documented OAuth 2.0 protocols and token exchange patterns remain unchanged.

The autonomous agent authentication and authorization flow documentation now adds `using Microsoft.Identity.Web;` to a C# setup sample.

The interactive agent authentication and authorization documentation now includes `using Microsoft.AspNetCore.Authentication.JwtBearer;` in its C# setup samples.

The error-code documentation now separates quota, blueprint, blueprint principal, agent identity, and agent identity creation errors, with clearer descriptions and table headings.

The documentation replaces inconsistent tenant placeholders with `<your-tenant-id>` and standardizes `<agent-blueprint-clientid>` to `<agent-blueprint-client-id>` in code samples.

The article now consistently refers to the sidecar integration as the Microsoft Entra ID Auth SDK instead of the Microsoft Entra Auth SDK. The integration guidance is otherwise unchanged.

The page updates image accessibility text, refines wording about agent identities, and standardizes the name “Microsoft Entra ID Auth SDK (sidecar)” for third-party agent integrations.

The documentation now refers to the “Microsoft Entra ID Auth SDK (sidecar)” instead of the “Microsoft Entra SDK auth sidecar.” The token-validation guidance is otherwise unchanged.

The Agent ID token claims documentation no longer includes one `tid` claim table row.

The documentation now expands MCP, A2A, and OBO on first use to improve clarity and retrievability.

The key concepts page now labels the link “Microsoft Entra Agent ID OAuth protocols” instead of “oauth protocols.”

The document title was normalized by removing an extra space after the metadata colon. No substantive guidance or product behavior changed.

The page no longer includes a TODO questioning support for enumerated scopes versus `allAllowed`/`none`. The diff provides no evidence of a product or feature change.

The documentation now spells out “on-behalf-of” before introducing the OBO acronym in the OAuth 2.0 authentication description.

The documentation now uses `<your-tenant-id>` instead of `<my-test-tenant>` in the token endpoint and `TenantId` code examples.

The page’s `ms.topic` metadata was changed from `how-to #Required; leave this attribute/value as-is` to `how-to`. The topic classification remains unchanged.

The delete-agent-identity article no longer contains a TODO asking engineering to confirm whether cascade cleanup removes associated agent user accounts.

The best-practices documentation now uses the full “Microsoft Entra Agent ID” and “Microsoft Entra ID” names in two recommendations. The guidance itself is unchanged.

The n8n integration page now consistently calls the pattern “Microsoft Entra ID Auth SDK (sidecar)” instead of “Microsoft Entra Auth SDK.”

The page’s bullet describing platforms and services that create agents retains the same wording and examples, including Copilot Studio, AWS Bedrock, and n8n. No substantive content change is shown.

The documentation now recommends creating agent identities from an agent identity blueprint instead of using standard app registrations or service principals. It also adds .NET usage guidance and lists required roles and permission.

The documentation updates its C# examples, separating app-only, on-behalf-of-user, and user-identification scenarios. Samples now configure agent identity options and pass the credential to the Blob client correctly.

The guide updates “Entra” to “Microsoft Entra” in the diagram alt text, setup heading, and TENANT_ID descriptions. No technical procedure or feature change is shown.

The agent identity architecture planning page now links to the correct interactive agent authentication article instead of the previous broken path.

The documentation now explains that agents should use an agent identity blueprint and the `#Microsoft.Graph.AgentIdentity` object, rather than standard app-registration APIs. It also lists supported creation channels, roles, permissions, and .NET usage.

The Agent ID documentation now refers to the linked SDK as the “Microsoft Entra ID Auth SDK” instead of “Entra ID Auth SDK.”

The documentation replaces “Device disablement” with “Attacker-added device” and explains that the Entra device object is disabled, new token issuance is blocked, existing device-bound refresh tokens are revoked, and user sessions are revoked.

The documentation now describes a Device disablement response for users flagged by Microsoft threat intelligence as having an attacker-added device. The device is disabled, and the user is prompted to sign in from a trusted device.

The documentation now expands its guidance that administrators must verify users meet existing access package policy requirements before assigning them; otherwise, assignment may fail.

The documentation removes an inaccurate statement implying that direct assignment to an access package requires approval. It now states only that assigned users must meet the policy’s eligibility requirements.

The access package assignments page no longer includes a note stating that assignment managers cannot bypass required approval settings or directly assign identities without approval.

The entitlement management delegation documentation removes a note about access package assignment managers being unable to bypass approval requirements when directly assigning identities.

The guidance now includes an approximate domain-count example and reiterates that capacity depends on domain length within the 25 KB (25,000-character) policy limit.