server@2.22.0

Minor Changes

• 008a91f: All federated sign-ins now use a per-client redirect URI, /mcp/idp_callback/{clientID}, that binds each authorization response to its issuer (RFC 9700 section 4.4.2). This makes federated sign-in work with identity providers that do not return the RFC 9207 iss authorization response parameter, such as Okta's org authorization server. A provider that advertises iss support, in discovery or through the issuer's authorization_response_iss_parameter_supported setting, must still return a matching iss. Existing federated identity provider apps must register the new redirect URI, which organization-owned remote session clients now report as federated_callback_url. The shared /mcp/idp_callback serves only WorkOS; a misrouted federated callback is rejected without spending the login state. Issuer migration is refused while a client of the source issuer is a user session issuer's trusted sign-in client. Okta identity provider connections now report their remote_session_issuer_id.
• 2baba61: Identity chaining changes are now audited on the remote session client. A binding becoming ready on a client records remote-session-client:enable-identity-chaining, changing the requested scopes while it stays ready on the same client records remote-session-client:update-identity-chaining-scopes, and a ready binding leaving the client (unlinked, moved to another client, or no longer ready) records remote-session-client:disable-identity-chaining with that client's client_id. Each entry carries the binding, the user session issuer, the remote session issuer, the resource, the generation, the binding state, and the requested scopes (plus the previous scopes for a scope change). The entries are written in the same transaction as the binding change, and only a user actor carries an email display name, for these entries and for the client a dynamic registration creates.

Patch Changes

• 4c811b0: The admin command palette lists enterprise organizations first, then pro and pay-as-you-go, then free, then any other account type. The organization list and the staff Admin MCP find_organizations tool accept the same account_tier sort.

• 3ffc9d0: Risk policy details load immediately. The obsolete analysis-progress counts are removed, including risk.getPolicyStatus and the "View Progress" panel.

• 1776c08: Keep a hosted toolset's own MCP server and the gateway members on the same toolset apart. Platform MCP diagnostics, server health charts, and hosted overview metrics exclude member traffic from the canonical server, which also owns the toolset's plugin entries. Role delivery adds the canonical server once, falling back to one addressable alternate only when the canonical server is enabled but has no live endpoint, and keeps entries it already delivered. Adding the canonical server as a gateway member is now rejected.

• 2baba61: The MCP consent page marks a service whose access identity chaining is configured to supply as "Managed by your identity provider", with an optional, de-emphasised "Use a separate sign-in instead" action, and a configured service counts toward enabling "Give access" because the runtime obtains its access on first use; an interactive connection still takes precedence. The page now checks the chained exchange in the background: a card with a usable stored credential renders "Connected through your identity provider" straight away, and otherwise the page runs the exchange with a short timeout and settles the card in place as connected (counted in the "n of m connected" summary, with the credential stored for the first tool call), rejected (a generic message naming the service and a primary "Connect" for a separate sign-in), or unknown (the neutral copy). Provider error details never reach the page, and without script the card keeps the neutral copy and its fallback. A card is marked only when exactly one ready binding serves the upstream through that card's authorization server, never when the bindings are ambiguous or the card's existing grant cannot be routed, and a lookup failure leaves the card unmarked instead of failing the page. On gateway endpoints a card is marked only when identity chaining serves every gateway member that uses its authorization server.

• 56218c5: Explore and widgets can draw a Stacked bar and a Stacked area chart, which show what made up a total rather than how each series moved. A stack needs a Group by; without one it is drawn as the plain bar or area it is and says so. It stacks one measure that adds up, a count or a sum, since its bands are a total. When a breakdown has more series than fit, the smallest are stacked as one Other band so the height is still the real total, and the tooltip gives each bucket's total.

• af578ee: The Dashboards page lists the dashboards Speakeasy ships with the product, marked Speakeasy-built, beside the project's own. One opens read only at /dashboards/builtin/<slug> under the shared filter bar, with every card answering within it, and Duplicate makes a project dashboard from it, with a saved widget per card, that can be laid out and changed like any other. The first is MCP & Tools: what the agents called, how often a call failed, and who was calling.

• e022baf: Agents can list, read, save, duplicate and delete a project's Explore widgets through the Speakeasy Platform MCP. list_widgets and get_widget show each widget's query, chart, whether it still works and the dashboards it is on. save_widget, duplicate_widget and delete_widget preview first and commit only on confirmation, naming the version they read, so an edit made in the dashboard meanwhile is never overwritten; a delete reports which dashboards lost the widget. Permissions match the dashboard: any project member can create and duplicate widgets, and a widget can be updated or deleted by its creator or by someone with write access to the project. The tools need Explore switched on for the organization and serve external users only.

• 827cf06: Agents can list, read, create, lay out, filter, duplicate and delete dashboards through the Speakeasy Platform MCP. list_dashboards and get_dashboard read a project's dashboards and the Speakeasy-built ones; save_dashboard, duplicate_dashboard, delete_dashboard, edit_dashboard_layout and save_dashboard_filters preview first, then commit once confirmed against the version last read, with the same permissions, grid rules and audit trail as the Dashboards page. Speakeasy-built dashboards stay read-only: duplicate one to change it.

• 43db572: Hosted MCP server traffic now records the MCP server and endpoint it was served through on tool call and resource read logs, usage events, analytics events, request logs, and the tool call and request duration metrics.

  Legacy hosted requests also attribute unambiguous server identities without changing authorization, and remote tool-call and resource-read usage events include their fronting server identity. Hosted tools-list analytics emits the shared mcp_server_tools_list event alongside the existing mcp_server_count event for compatibility; analytics consumers should select one event rather than sum both.

• 2baba61: Identity chaining no longer sends OpenID Connect scopes (openid, profile, email, offline_access, phone, address) in the ID-JAG token exchange, because Okta rejects them. A client whose scope came from the issuer's discovered scopes_supported now chains with only its resource scopes, or with no scope parameter when none remain, in which case the ID-JAG may carry no scope or only scopes from the configured set. When scopes are requested, the ID-JAG must carry exactly that set: one that omits its scope claim fails with scope_policy_denied and one that carries only some of them fails with insufficient_scope, so an omitted token scope is never recorded as granted on the ID-JAG's behalf. An ID-JAG whose audience is the resource authorization server's issuer is accepted alongside an administrator-confirmed audience. When the resource authorization server's token reports a scope that lacks a requested scope, the server still rejects it and now logs the requested and granted scope names at warning level.

• 2baba61: Platform MCP readiness now judges MCP servers that identity chaining serves the way the MCP runtime does. When a user has no interactive session for such a server, including when no interactive client is attached, get_mcp_readiness reports ready with identity_chaining_active evidence once the user holds a usable chained credential, and otherwise keeps reporting that authorization is needed with identity_chaining_configured evidence instead of upstream_authorization_required or no_valid_authorization. get_my_mcp_connection_status reports the server as active with reason identity_chaining when the user holds a usable chained credential, and otherwise reason identity_chaining_configured with next action use_mcp; an active interactive session the provider rejected still reports reauthorization, since the runtime forwards it rather than chaining. With several interactive clients for the server, identity chaining is consulted before reporting multiple_authorization_clients. A stored chained credential that no longer decrypts counts as unusable. Neither surface requests a token.

• fd1b58c: Hosted MCP requests served through the legacy toolset slug lookup now carry the toolset's canonical MCP server when it has one, so kill switches (evaluated fail-closed, as on the endpoint path) and server-scoped risk policies on prompts/get and resources/read apply to them. Each fallback request is logged with its entry point, toolset, project, request host, canonical-server presence and custom domain state.

• b481b2d: The Okta setup checklist now says that the AI agent's linked app is the app people use to sign in to Speakeasy. After the agent is registered and linked, you record the agent ID, then a new Add the agent's public key step has you use Set up Okta sign-in, paste the public key it shows in the agent's Credentials and click Activate, before activating or editing the linked app, because Okta rejects changes to the linked app until the agent has a public key. The step notes that rotating or publishing a new key means pasting it in Okta again, and that setup needs customer-managed encryption keys and a Google Cloud KMS key. The activate step then adds the Authorization Code and Refresh Token grant types and the sign-in redirect URI. It also says that people who sign in through Okta must already exist in Speakeasy through directory sync (SCIM).

  The checklist's first Cross App Access connection step now says, in the same words as the dashboard's notice, that each vendor must also enable enterprise-managed authorization in its own admin console and trust your Okta issuer, with Linear as the example. Many vendors require an Enterprise or SSO plan, and Speakeasy cannot do this step for you.

• b481b2d: The Platform MCP get_xaa_readiness tool now also reports the organization's Okta sign-in setup in okta_sign_in: whether the AI agent's linked app is registered as the sign-in client and ready, the active public key (JWK, public members only) to paste in the agent's Credentials in Okta and Activate, the sign-in redirect URI, which organization sign-in issuers trust it or still trust a previous agent's client, the next sign-in step, and the first Okta setup checklist step not yet confirmed (skipping steps Speakeasy cannot observe once its side is done). Several clients claiming the agent ID report a distinct resolve_duplicate_sign_in_clients step instead of picking one. It stays read-only and organization-admin only; setting up sign-in still happens in the dashboard because it needs a signing key choice and a confirmed trust change.

  Recording an AI agent ID that is the connection's own service app client ID is now rejected.

• db650a3: Migrate prompt injection scanning to a cascade that sends Jev candidates at or above 50% probability to Sonnet 5.5 for confirmation using up to five conversation messages. Role-play and "act as" requests count as content requests unless they also try to override the agent. When Sonnet 5.5's safety classifier refuses a candidate, Opus 4.8 confirms it instead.

• daf0a70: Editing a Shadow MCP policy no longer fails with "cannot change the sources or action of a shadow mcp policy with a disposition". A block_all policy — the default, and what every policy the dashboard creates stores — can once again turn its Shadow MCP detector off or move off the Deny action, exactly as the policies that predate the disposition field always could; the server now retires the policy's allowed-server grants along with the posture instead of leaving them behind. An allow_all policy still cannot, because its blocked-server list would have nothing left to enforce, but the editor now pins its detector and action up front with the reason, and the remaining server-side rejections say which part of the edit was refused and what to do instead. The Platform MCP update_risk_policy tool follows the same rule: a block_all policy's patch may turn off shadow_mcp or move off the Deny action and retires the policy's allowed-server grants with it, while an allow_all policy's patch is refused with the same explanation.

• 520d773: Shadow MCP admission no longer depends on hidden rollout flags: the project's enabled block policy is always enforced for user-supplied MCP servers, and an organization administrator's own write is recorded as the approval. When an administrator puts a server added by URL into a plugin, or widens a plugin's audience, from the Platform MCP or the dashboard, the server is recorded in Shadow MCP as approved for exactly the people who receive it, and the Platform MCP result reports that standing with a link to its page. The platform-mcp-shadow-audience-enforcement and platform-mcp-direct-remote-distribution-disabled feature flags are removed.

• 41d53fc: Resolve a toolset's MCP server to an enabled server before a disabled canonical wrapper, so the advertised hosted URL and minted session tokens target a server that serves.

  Keep the playground connection, session mint, and session management on the selected server's endpoint and issuer without reviving disabled canonical routes. Show explicit loading and failure states instead of reporting missing authentication or starting chat after connection errors.

• 2baba61: The Platform MCP get_xaa_readiness tool now reports an MCP server's identity chaining bindings (state, remediation, the configured scopes, the scopes actually requested after dropping OpenID Connect scopes, and whether chaining serves it, judged the way the runtime selects a direct or tunneled upstream) and the federated sign-in callback URL to register in the identity provider, including for clients with a recorded callback origin when no outbound origin is pinned. Every live binding for the upstream is listed. Preparing identity chaining checks organization administration before any other grant validation when it would change an organization-owned client's grants.