Organization admins can now create upstream credentials for an MCP server and offer the same one on several servers, instead of configuring each from scratch. When a server offers more than one, every path that connects to it now asks which to use: the consent screen a person sees, an agent key at issue time, an assistant's turns, and an app or workload signing in without a browser. The choice is checked again on every call, so a credential you're blocked from, or one that was turned off, stops working immediately rather than on the next reconnect. More on this in Upstream credentials.

Features

• Create and share upstream credentials across servers — Organization admins can add a personal connection, a service account, a static credential, or a header pass-through as a reusable credential, and offer an existing one on another server instead of recreating it. Rotating a credential's headers keeps secret values that aren't re-entered, and every change is audited. (#8036, @danielkov)
• Pick a credential on the consent screen — When a server offers several upstream credentials, the consent screen now shows the choice instead of defaulting to one, preselecting whatever you approved there last. A server you may not use on reads "No access," and one that still needs setup says so instead of offering a connection that can't work. (#8038, @danielkov)
• Agent keys can be issued with a chosen credential per server — Creating an agent key now lets you name which shared credential it uses on each server that offers more than one, and a rotated key keeps its choices. (#8040, @danielkov)
• Assistants choose their own upstream credentials — Open an assistant's Identity → Upstream credentials to set which credential its turns use on a given server, separately for turns that act for a person and turns that act for nobody. Turns already running keep the credential they started with. (#8043, @danielkov)
• An assistant acting for you now uses your own connection, not its owner's — When a server uses a person's own account, an assistant acting for that person now connects as them. If they haven't connected yet, the assistant sends a private link that works only for them, while signed in, and expires after 15 minutes. (#8044, @danielkov)
• Apps and workloads can select a credential without a browser — A token request can now name the server and credential it wants with upstream_auth_client=<server id>:<credential id>, or fall back to the credential an admin chose for that app. (#8042, @danielkov)
• Grant use of auth clients alongside connect access — The built-in Admin and Member roles, and API key policies, can now grant permission to use upstream auth clients the same way they grant permission to connect to MCP servers. (#8283, @danielkov)
• One settings surface for upstream identity — An MCP server's settings now show a single upstream identity view, listing its credentials where credential enforcement is on, instead of splitting the picture across two panels. (#8371, @danielkov)
• Trust an identity provider for inbound enterprise-managed authorization — Organization admins can trust an identity provider from the Platform MCP, see its audience and whether directory sync is set up, and remove the trust. Rejected ID-JAG exchanges now log their specific reason, and Okta's ID-JAGs, which carry no resource claim, are accepted and routed by their claim instead of being refused. (#8186, @daviddanialy)

Bug fixes

• Okta connections ask for fewer permissions — Speakeasy no longer requests okta.users.read or okta.groups.read when connecting Okta, keeping only the okta.apps.read scope it actually uses. (#8232, @daviddanialy)
• Organization admins can bind shared clients to org-level session issuers — Linking an organization-owned auth client to an MCP server's org-level user session issuer used to fail with no way around it; it now saves, and the change reaches every project that shares the issuer. (#8274, @qstearns)
• Upstream identity stays in step with the legacy provider pages — Removing a client from a server or organization, or deleting a platform client, now retires the upstream credentials those servers offered through it in the same save, instead of leaving them to show stale options. (#8417, @danielkov)
• Tool call history shows which credential actually signed in — A call made through an agent's gateway no longer reads as made on behalf of whoever issued the agent's key when a shared credential served it; it now names the credential that was used. (#8370, @mfbx9da4)
• "All servers" agent keys reach servers added later — An agent key or gateway issued with access to every server used to stay stuck on the servers that existed at issue time; both now pick up servers added afterward, including through an edit. (#8341, @mfbx9da4; #8372, @mfbx9da4)