Issuers move between project and organization scope, and MCP servers pick an issuer that already exists

An issuer no longer has to stay where it was first created. Organization administrators can move a user session issuer between project and organization scope, or consolidate one issuer into another, after reviewing an impact and conflict preflight. The migration carries clients, sessions, consents, CIMD allowlists, remote-session credentials, and attached resources across, and audits the retirement of the source. Creating an MCP server can now select an existing organization or project issuer rather than making another one, and an authorization server can be served on a separate authentication host that carries no MCP traffic. Weekly billing emails also summarize the metered products.

Features

• Move and consolidate user session issuers #6536 - Organization administrators can move an issuer between project and organization scope, or consolidate one into another, after an impact and conflict preflight. Clients, sessions, consents, CIMD allowlists, remote-session credentials, and attached resources are preserved, and the source retirement is audited. Access tokens bound to the source issuer are rejected by repointed servers until the client refreshes, which succeeds against the migrated session. Client registration, session minting, refresh rotation, consent, and remote-login callbacks lock and recheck the issuer they write under, so a write that raced a migration or delete is rejected instead of landing on a retired issuer. (Author: @bflad)
• MCP servers select an existing issuer #6529 - An MCP server can select an existing organization or project owned user session issuer during creation or from its authentication settings. Interactive creation prefers a sole organization issuer and requires a choice when several exist, with project-specific issuer creation kept as an explicit fallback. Organization-owned issuer settings stay read-only from project pages. (Author: @bflad)
• Serve authorization on a separate host #6515 - An authorization server can be served on an alternate authentication host that carries no MCP traffic, configured with GRAM_AUTHENTICATION_HOST_URL and opted into per user session issuer. Opted-in servers announce the authentication host as their issuer in authorization server metadata, protected resource metadata, authorization responses, and minted tokens, while the resource stays on the MCP host. The token endpoint also checks grant_type before authenticating the client, so an unsupported grant gets unsupported_grant_type even without valid client credentials. (Author: @aa-wong)
• Weekly billing emails summarize metered products #6607 - The weekly email summarizes agent session storage, risk scanning, and MCP gateway egress from product meters, shows estimated spend only for pay-as-you-go organizations, and compares usage across completed billing-cycle days. (Author: @disintegrator)

Rolling out

• Cross App Access readiness per MCP server #6583 - An oktaResourceConnections API reports per-server Cross App Access readiness derived from the upstream authorization server's advertised grants, the recorded AI agent, and the Okta resource connections the administrator confirmed. (Author: @daviddanialy)
• Okta connection and readiness page in organization settings #6587 - Okta setup splits into separate checklist steps ending with a first Cross App Access connection, with linked app steps ticked automatically from the applications sync and a linked app that is inactive or unassigned flagged. The Okta page folds into the Identity page as concern tabs with a vendor-neutral provider picker, the applications snapshot is gated on a clean verification, and a degraded connection is explained inline. (Author: @daviddanialy)

Bug fixes

• Platform signing credential usable for identity provider connections #6635 - Platform GCP credentials that impersonate a service account in Speakeasy's own project record the own-project exemption on create and update. Creating, updating, and deleting platform credentials requires a fresh platform admin session, and a new setting pins which service account the signing credential may impersonate, checked when a key is provisioned or rotated and on every client assertion signed with a managed key. (Author: @daviddanialy)