Remote MCP servers choose who they act as, and a workload fleet can be admitted by one wildcard

A Remote MCP server now declares whose identity it uses. User, Agent, and No Identity modes are selected when the server is created and changed from one authentication panel, with managed authorization credentials and an editable remote identity provider setup, so the question of who a server acts as stops being spread across several screens. Admitting workloads gets less repetitive too: where an issuer permits it, a trailing wildcard such as an agent fleet path admits every subject beneath it and resolves the agent they inherit policy from, instead of one admission per workload. Wildcard matching is off unless the issuer allows it, and two new RBAC scopes gate who can manage the trust policy at all.

Features

• Configure server authentication from one panel #6364 - Remote MCP servers gain User, Agent, and No Identity modes, with identity selection during creation, managed authorization credentials, and editable remote identity provider setup. (Author: @qstearns)
• Provider and client setup in one operation #6359 - Remote MCP server identity is configured through a single atomic provider and client setup operation, so a half-configured server is no longer a state you can land in. (Author: @qstearns)
• Admit a workload fleet with a wildcard #6728 - A workload subject can be admitted, and resolve its agent, by a trailing wildcard such as an agent fleet path rather than the whole value, but only under an issuer that permits wildcard matching. The workloadIdentities management API reads an organization's workload identity trust policy, registers and withdraws the external issuers it trusts, and admits and withdraws the subjects those issuers may present, with an admission resolving its issuer at the tier it is written to so an organization-tier admission cannot bind a project-tier issuer. (Author: @aa-wong)
• Scopes for the workload identity trust policy #6751 - The workload:read and workload:write scopes gate managing an organization's workload identity trust policy: its issuers, its admitted subjects, and which agent each one inherits its policy from. Both are admin system-role defaults. (Author: @aa-wong)
• Prepare and inspect identity-chaining registrations #6438 - Management API and SDK operations prepare, inspect, and unlink downstream identity-chaining client registrations with explicit grant evidence and generation checks. Readiness fails closed on missing grant evidence, and uncertain registrations are treated as uncertain rather than assumed good. (Author: @danielkov)
• Advertised grant profiles on identity providers #6662 - Identity provider API and SDK models expose advertised authorization grant profiles. Discovery and refresh retain only fresh, matching-issuer evidence, and partial-discovery diagnostics preserve the upstream HTTP status. (Author: @danielkov)

Bug fixes

• Issuer changes cannot orphan an identity-chaining binding #6663 - Active identity-chaining bindings are protected during issuer lifecycle changes: unsafe issuer deletion and consolidation are blocked, and the dashboard and admin migration review show binding counts with explicit unlinking guidance. (Author: @danielkov)
• A shared remote session client records the right upstream #6773 - The MCP consent page no longer loops on "Connected elsewhere" when one remote session client is shared by remote MCP servers with different upstream URLs. Connecting records the upstream of the server actually being connected. (Author: @qstearns)