Follow us on or RSSto be up
to date with the latest changes.

// October 7, 2026v1.38.0

Platform

Platform

MCP Gateway

Agent Sessions show who an assistant acted as and who it acted for

An assistant session in Agent Sessions used to show only the assistant's name. Now the name links to the agent identity the session ran as, and a muted "for" next to it names and links to the person it acted on behalf of, in the session list, the session header, and the Details popover. Session owners on every other row are clickable too. Building custom tools gets a naming cleanup: the functions SDK now publishes under Speakeasy names, with every existing import, environment variable, and config file still working as a deprecated alias. More on this in Agent Sessions and Add tools with TypeScript.

Features

  • See who an assistant session ran as and acted for — The assistant name in an agent session links to the agent identity it ran as (or to the assistant itself when it has no agent identity), and the member it acted on behalf of is named and linked right next to it, in the session list, the session header, and the Details popover. Non-assistant session owners are now clickable too. (#7232, @danielkov)
  • Build functions with the Speakeasy-named SDK — The functions SDK now publishes as @speakeasy-api/functions, with its Functions class and fromFunctions/withFunctions MCP helpers. Every existing import, config file, deploy file, build output, environment variable, and CLI profile path keeps working as a deprecated alias, so no existing project needs to change. (#7235, @adaam2)
Sagar Batchu
Sagar Batchu
View on GitHub
// October 7, 2026v1.37.4

Platform

MCP Gateway

The CLI is now speakeasy, with built-in commands for building functions

The command-line tool is now called speakeasy. Install it with brew install speakeasy-api/tap/cli or npm i -g @speakeasy-api/cli; the old gram binary keeps working as a deprecated alias, so nothing breaks today. The functions SDK's build and deploy steps move into the CLI too: speakeasy functions init|build|dev|push|stage replace the standalone gf tool and the create-function scaffolder, which now print a notice pointing at the new commands. More on this in CLI overview and gram stage function.

Features

  • Install and run the CLI as speakeasy — The CLI's command name, help text, and install instructions now say speakeasy. Running it as gram still works and prints a one-line deprecation notice; profiles stay in ~/.gram/profile.json, so there's nothing to re-authenticate. https://ai.speakeasy.com/cli.sh and /cli.ps1 now redirect to the install scripts on every platform host. (#7130, @adaam2; #7187, @adaam2)
  • Build and deploy functions with speakeasy functions — speakeasy functions init scaffolds a project from a built-in template (--template functions or --template mcp), build compiles it, dev runs its dev script, and push builds, stages, and deploys it using your speakeasy auth profile. The old gf build/gf push commands keep working but print a notice pointing at the replacements, and speakeasy push now deploys to the API URL from your profile instead of always targeting https://app.getgram.ai. (#7130, @adaam2)
Sagar Batchu
Sagar Batchu
View on GitHub
// October 7, 2026v1.37.3

Platform

Identity

Assistants get their own agent identity, with dedicated permissions to match

An assistant's tool calls and audit trail used to be attributed to whoever set it up or talked to it. In organizations with agent identity credentials enabled, a new assistant now gets its own dedicated agent, so its activity shows up under its own name, with its own policy, and can be suspended or transferred independently of any person. Existing assistants keep working exactly as before until an admin explicitly upgrades them. Assistant access also moves onto its own assistant:read/assistant:write permissions instead of riding along with project:*, and the Team Access tab can now explain, for any member, exactly why they can or can't reach a given MCP server. More on this in Agent identity and Roles and permissions.

Features

  • Give an assistant its own agent identity — An assistant's Identity tab can set it up with a new agent you name or an existing agent of the project you own or can authorize, starting with access to every MCP server and skill in the assistant's project. The agent can be renamed, transferred, or narrowed like any other agent, and deleting the assistant withdraws its trigger workload identities while leaving the agent in place. The upgrade endpoint and the Platform MCP upgrade tool accept the same choice. (#7107, @danielkov; #7079, @danielkov)
  • Assistant access gets its own permissions — Dedicated assistant:read and assistant:write scopes replace the old reliance on project:*, which no longer opens assistants on its own. Grants can cover every assistant, every assistant in selected projects, or a single assistant, and agent policies can hold them too. Admins keep full access and members keep read access by default. (#4899, @danielkov)
  • See exactly why a member can or can't reach a server — The MCP server Team Access tab gains a Check access section: pick a member to see whether they can connect to, view, and manage the server, and which rule decides it, including the directory role mapping behind a role for organization admins. (#7095, @bflad)
  • A blocked server no longer blocks every server — Fixed a bug where blocking one MCP server for an agent-backed assistant turn removed access to every MCP server on that turn instead of just the blocked one. (#7202, @danielkov)
Sagar Batchu
Sagar Batchu
View on GitHub
// October 7, 2026v1.37.2

Platform

Platform

Organizations move to their own platform host automatically, with no second sign-in

Some organizations now have a recorded home among the platform's hosts, such as ai.speakeasy.com instead of app.getgram.ai. When that applies, signing in, opening an old bookmark, or clicking an emailed link now lands you on your organization's own host automatically, with the browser carrying your session across in one hop instead of asking you to sign in again. Everything that points at a server, an agent gateway, or an install page, including gateway install pages and agent network allowlists, keeps working through the move. More on the allowlist side in Device agent.

Features

  • Your organization's links all lead to its own host — Invitations, setup and access-request emails, trial and billing emails, weekly usage summaries, and custom-domain health alerts now build their links from the organization's recorded host instead of the shared site URL, so an org's emails and its dashboard always agree. The block page link and risk policy links a hook denial returns follow the same rule. (#7084, @adaam2; #7128, @adaam2)
  • Moving hosts no longer asks you to sign in again — When your organization lives on a different platform host from the one you're using, the dashboard and the login page now hand your session over to that host through a one-time code and open the same page there, instead of bouncing you to a second login. (#7131, @adaam2; #7146, @adaam2)
  • Agent network allowlists list every platform host — Device-agent "Remote network access" and the Cowork allowed-domains step now list every platform host for the environment, so an allowlist set up before an org moved hosts keeps working after it moves. (#7127, @adaam2)

Bug fixes

  • A redirect loop guard no longer traps you on the old host — Going back to the old platform host in the same tab now moves you to your organization's host again; the guard against redirect loops lasts 15 seconds instead of the life of the tab. (#7176, @adaam2)
  • A gateway's install page no longer says "Server Not Found" — Gateways with private network access enabled now render their public install page, and a gateway on a custom domain opens its install page on the host you're signed in to, with the custom-domain URL in the instructions. (#7148, @daviddanialy)
  • Opening a shared MCP install page while signed in now opens it — Previously it landed you on your organization's home page instead. (#7167, @simplesagar)
  • A retried checkout now replays the same success and cancel URLs — Stripe Checkout now records its return URLs on every intent, including ones created on the shared site host, so a retried checkout still works after an organization's host changes. (#7126, @adaam2)
Sagar Batchu
Sagar Batchu
View on GitHub
// October 7, 2026v1.37.1

Platform

Platform

Explore gets a Dashboards tab for laying out shared widgets

Explore's Widgets tab now has a companion Dashboards tab: lay saved widgets out on a shared 12-column grid that everyone in the project sees the same way. Any member can create a dashboard and add the project's saved widgets to it (the same widget can be placed more than once, and editing it updates every placement); its creator or anyone with project write access can drag and resize cards. A dashboard can be renamed, duplicated with its own independent copies of its widgets, and deleted. Widgets also gained a Cards view, the dashboard's own date presets, and a shared filter bar that every widget on a page answers within.

Features

  • Lay saved widgets out on a dashboard — Create a dashboard from the project's saved widgets, drag and resize its cards on a 12-column grid, and share it with everyone in the project. Duplicating a dashboard copies its widgets too, so the copy is fully independent, and every change autosaves as it lands. (#7175, @subomi; #7173, @subomi)
  • A shared filter bar and time range for everything on a page — Widgets and Explore now share the dashboard's date presets (15 minutes to 90 days), and a page's date range and filters apply to every widget placed on it: the page's range replaces each widget's own window, page filters are ANDed with each widget's own filters, and dragging across a time chart narrows the page. (#7122, @subomi; #7121, @subomi)
  • A Cards view for the Widgets tab — Toggle between List and Cards to see every saved widget drawn as a card, answering its own question, with the same actions as its row. Each card runs its query only once it scrolls into view. (#7133, @subomi)
  • See where a widget is used before you change it — The Widgets tab gets a Dashboards column counting the dashboards a widget is on and naming them on hover; saving edits to a widget on a dashboard, or deleting it, now says which dashboards that reaches. (#7177, @subomi; #7174, @subomi)
Sagar Batchu
Sagar Batchu
View on GitHub
// October 7, 2026v1.37.0

Platform

Security and Policy

MCP Gateway

Risk Events get full payload reveals, Okta setup gets simpler, and Platform MCP gains admin tools

Clicking a Risk Events row now opens a detail drawer for every finding kind, including the call path and, with the right permission, the full scanned tool-call payload. Okta admins can paste the Admin Console URL directly, and the setup walkthrough matches Okta's current console. The gateway now speaks MCP protocol revision 2026-07-28 on every hosted and gateway surface, and the Platform MCP picks up a round of admin tools for creating projects, plugins, and MCP servers without leaving the chat. The rest of this release is smaller fixes across sign-in, plugins, and billing. More on this in Risk Events, Okta, and Platform MCP.

Features

  • Investigate any finding from one drawer — Clicking a Risk Events row opens a detail drawer for every finding kind, including MCP findings, showing the call path from client to gateway to server. With the chat:read permission, the drawer can reveal the full scanned tool-call payload with each finding highlighted in place; every reveal is audited. (#7071, @vishalg0wda)
  • Paste your Okta Admin Console URL directly — The Okta connection form now accepts a pasted Admin Console address instead of requiring the bare organization URL, and the setup instructions and Cross App Access checklist match Okta's current console, including each server's issuer. (#7149, @daviddanialy)
  • The gateway now speaks MCP protocol revision 2026-07-28 — Hosted MCP servers, gateways, agent gateways, and platform toolsets now serve the 2026-07-28 protocol revision alongside earlier ones. A client that declares it gets that revision's behavior (server/discover, spec-mandated HTTP statuses, no session IDs); clients on an earlier revision see no change. (#7184, @bflad; #7155, @bflad)
  • Claude Tag conversations show who's really talking — Agent Sessions now attributes a Claude Tag session's participants through the Slack directory independently of session ownership, shows their session rollup, and displays parent and subagent relationships and Slack channels. (#7103, @chase-crumbaugh)
  • One shared authorization server for user session issuers — A user session issuer in shared mode now serves a single OAuth authorization server for every MCP server it covers, with clients naming the server they want and each access token bound to that one server. (Organization admins managing remote identity providers.) (#7140, @bflad)
  • Platform MCP can create and rename projects and plugins — An agent can now make an empty project from a display name, and create or rename a plugin, so setting up an MCP server no longer has to stop to send an admin to the dashboard. (Organization admins, via Platform MCP.) (#7115, @simplesagar; #7114, @simplesagar)
  • Platform MCP can turn your deployed functions into an MCP server — create_mcp_from_functions creates a server and tool list from a project's already-deployed function tools, through the same path the dashboard uses. (Organization admins, via Platform MCP.) (#7118, @simplesagar)
  • Plugins stay current automatically, and admins can force a republish — A new skill version, a skill rename or archive, and MCP server or sign-in changes now republish the plugins that carry them promptly instead of within the hour. republish_plugin lets an admin catch a stale plugin up on demand, and get_plugin now shows the status of the latest publish attempt. (Organization admins, via Platform MCP.) (#7111, @simplesagar; #7112, @simplesagar; #7113, @simplesagar)
  • Platform MCP can pause and resume a data export route — Turn one data export route off and on without touching its destination; data produced while paused is dropped, not delivered later. (Organization admins, via Platform MCP.) (#7117, @simplesagar)
  • Platform MCP sets up sign-in automatically for more MCP servers — Providers that support Client ID Metadata Documents but not dynamic client registration are now classified and connected automatically instead of being sent to manual setup, and inspection now supports MCP 2026-07-28-only servers. (Organization admins, via Platform MCP.) (#7156, @simplesagar; #7096, @bflad)

Bug fixes

  • A project's marketplace name no longer changes under you — Renaming the organization, changing the project slug, or deleting the organization's oldest project no longer renames an already-published plugin marketplace, which would otherwise break every config that references it by name. (#7138, @mfbx9da4)
  • Sign-in to some remote MCP servers no longer fails on a trailing slash — The RFC 8707 resource indicator is now sent exactly as the server is registered, trailing slash included, so providers that match it exactly against their published metadata no longer reject sign-in. (#7153, @simplesagar)
  • The MCP connect page shows the right name and logo — A card whose own identity provider entry has no name or logo now borrows the catalog's, instead of showing an internal identifier with no logo. (#7092, @daviddanialy)
  • PII findings on JSON content point at the right text — Matches found in JSON tool-call content now point at the matched text in the original content instead of an internal rewrite. (#7070, @vishalg0wda)
  • Billing's spend caps load even with a disabled inference key — The billing page's spend caps no longer 500 for an organization with a disabled platform key; usage for a disabled key is now read through the provisioning key instead of the key's own rejected credentials. (#7093, @bradcypert)
  • Tool rankings link straight into Tool Logs — Clicking a tool under an MCP server's Top tools rankings now opens Tool Logs already filtered to that server and tool, keeping the active time range, instead of requiring the filters to be rebuilt by hand. (#7168, @simplesagar)
  • The tunneled MCP setup no longer shows a CLI command that never existed — The tunneled setup snippets drop the CLI tab, which told people to run a tunnel run command the CLI never had; Kubernetes and Docker remain. (#7230, @adaam2)
  • The Dashboard/Headless switch animation no longer glitches — Switching between Dashboard and Headless no longer leaves stray starfield streaks or an empty strip beside the scrollbar, and the two cards now lay out within the visible viewport. (#7030, @alx-xo)
  • Vercel Connect and Conductor are recognized automatically — Both are now admitted to the Client ID Metadata Document catalog, so Vercel Connect's per-connector clients authenticate automatically and Conductor's desktop app is detected for Shadow AI scanning. (#7152, @bflad; #7150, @bflad)
Sagar Batchu
Sagar Batchu
View on GitHub
// October 3, 2026v1.36.2

Platform

MCP Gateway

Install an MCP server into ChatGPT Desktop, and open an install link shared from anywhere

ChatGPT Desktop is now one of the clients an MCP server's install page sets up, with the Developer mode and custom connector steps written out and the right authentication step for the server in question. An install page shared into a document, a wiki, or a chat also opens instead of returning 403, so the link you send someone works where they click it. More on installing a server into a client in gram install.

Features

  • ChatGPT Desktop on the install page and in the CLI — The hosted install page gains a ChatGPT Desktop card and an Add to Client entry, with a modal covering the Developer mode and custom connector steps. The authentication step follows the server: OAuth for an OAuth-gated server, a token for a private one, an explanation for a public server that expects user-provided headers ChatGPT cannot send, and nothing for a plain public server. gram install chatgpt-desktop prints the MCP URL and the same steps, and rejects a non-HTTPS URL. (#5320, @speakeasyforgebot)

Bug fixes

  • An install page opened from another site no longer returns 403 — A browser GET to /mcp/{slug} that accepts HTML keeps safe-method semantics in the Origin check, so an install link shared anywhere renders the page. Cross-site SSE GETs are still rejected. (#7076, @ThomasRooney)
Speakeasy Team
Speakeasy Team
View on GitHub
// October 3, 2026v1.36.1

Platform

Security and Policy

Identity

Every identity has a Findings page listing that person's risk findings

Clicking a person and reading their violations no longer means a trip to Risk Events with a substring filter. Each identity has a Findings page under Security that lists every risk finding for that person, newest first, filterable by category or rule, with a row expanding to the flagged message. Counts on the Security tab link into it pre-filtered, and matching now covers every identifier the identity reports rather than only the first. More on this in Identities and Risk events.

Features

  • A Findings page on every identity — The Security section of an identity gains a Findings page listing the person's risk findings newest first, filtered by category or rule, with each row expanding to the flagged message. Clicking a category or rule on the Security tab opens Findings already filtered, and the Open in Risk Events link filters on every identifier the identity reports. Viewing the page needs org:admin; the session link and the flagged message need chat:read on that session, and a match locked without it now says which permission is missing, in Risk Events and the Watchdog drawer too. (#6639, @AshGodfrey)
Speakeasy Team
Speakeasy Team
View on GitHub
// October 3, 2026v1.36.0

Platform

MCP Gateway

Platform

Search tool calls and the people behind them from Platform MCP, and review skill suggestions there too

An agent connected to the Platform MCP can now run the investigation an administrator would otherwise do by hand in the dashboard: search a project's tool calls across every MCP server, find the people behind them by partial identity, and read one person's call volume, failures, and most-failing tools, all with masked identities and no tool inputs or outputs. The same connection reviews proposed skill improvements end to end, including a guided workflow that walks the queue, and puts a newly pushed tool onto an existing MCP server. Per-endpoint MCP access tokens are also bound to the host that minted them, so a token minted elsewhere is refused with the usual challenge. More on this in Platform MCP and Improving skills with agent feedback.

Features

  • Search a project's tool calls from Platform MCP — search_tool_calls lists one project's tool calls across every MCP server over up to 30 days, narrowed by tool name text, error text, outcome, configured server, person reference, and custom attribute filters, with opaque cursors and masked identities. list_attribute_keys reports the custom @-prefixed and filterable system keys present in the window. System attributes carrying tool content, an HTTP header, or a person's identity are refused as filters and withheld from key discovery, and paging holds the window fixed at the interval the first page read. (#6853, @simplesagar)
  • Find a person and read their metrics without their raw identity — search_users finds the people observed in one project's telemetry by partial identity over up to 30 days, returning masked identities, categorical activity evidence, last-seen times, and short-lived project-scoped references. get_user_metrics_summary takes one of those references and returns the person's call volume, failures, the servers their tools name, and their most-failing tools. Both are organization-admin reads, metered on the sensitive diagnostics budget, and audited as attribution reads. (#6856, @simplesagar)
  • Put a newly pushed tool onto an existing MCP server — list_project_tools reports the tools a project produces and the function or API document each came from, get_mcp reports the tool list a hosted server exposes, and add_tools_to_mcp and remove_tools_from_mcp change that list one tool at a time under confirmation, an expected version, and an idempotency key. The change is computed inside the transaction that reads the current list, so a concurrent edit can no longer silently drop tools, and the result names the plugins the change republishes. (#6896, @simplesagar)
  • Approve or dismiss a proposed skill improvement from Platform MCP — approve_skill_suggestion and dismiss_skill_suggestion carry out the same review the dashboard offers. Approving records the reviewed changes, or a corrected SKILL.md, as the skill's new version and closes the suggestion; changes proposed after the review are never taken. (#7097, @simplesagar)
  • A guided workflow for working through the suggestion queue — The Platform MCP plugin ships a review-skill-suggestions workflow skill that walks an administrator through a project's suggested skill improvements: reading the queue and the evidence behind each change, deciding per change, then approving, correcting, or dismissing it with explicit confirmation, and checking the skill's new version. (#7099, @simplesagar)
  • Triage a large suggestion queue before reading any diff — list_skill_suggestions accepts omit_diffs to return each proposed change's ID, rationale, and evidence counts without its diff, so an agent can rank a long queue first. Diffs are still returned by default. (#7098, @simplesagar)
  • Per-endpoint MCP access tokens are bound to the host that minted them — A token whose iss names another host, whether the server URL, an extra platform host, or a custom domain, is refused with the usual 401 challenge, so the client refreshes or reauthorizes on the host it is actually using, and the rejection is counted with an issuer_mismatch reason. Dashboard-minted tokens, tokens without iss, private network ingress, and internal callers keep their current behavior. (#7080, @adaam2)
  • Registered callback URLs no longer move when a server URL changes — GRAM_OUTBOUND_CALLBACK_URL fixes the redirect origin for existing remote session clients, and GRAM_REGISTRATION_CALLBACK_URL records a new origin on organization-owned clients created from now on. Remote session clients report their callback_url, and the dashboard shows the redirect URI a new client will register instead of deriving it from the server URL. (#6984, @adaam2)
  • The remaining stored callback URLs are pinned too — The MCP login identity provider callbacks, including the federated callback sent to customer providers, the Platform MCP callback, and the assistant MCP auth client identity and redirect URI all follow the outbound callback origin rather than the server URL. A federated login's callback uses its trusted client's recorded origin where it has one. With the default configuration nothing changes. (#7082, @adaam2)

Bug fixes

  • Agent sessions are named again — Sessions captured through hook ingest kept the truncated first prompt they were seeded with, and archived inference conversations all read the same stand-in title. Both paths now schedule title generation, which recognizes those stand-in titles and replaces them while leaving manually chosen names and channel labels alone. Titles are generated over a bounded slice of the transcript, so a session with multi-kilobyte turns no longer times out before it is named. (#6797, @speakeasyforgebot)
  • Inference transcripts without a session id continue one conversation — A transcript delivered with no session id now continues the conversation that already holds its history instead of starting a new one on every request. Products that omit the session id previously produced one chat per inference call with the full transcript copied into each, multiplying stored messages, risk scans, and model calls by the length of the conversation. (#7086, @dennnis-ez)
  • Slack previews of platform links show the logo — The preview now uses the opaque sticker logo, which Slack can decode and which stays visible in dark mode, in place of a broken image. (#7072, @simplesagar)
  • Project favorites survive a bounce to the login page — The session-expiry cleanup snapshots theme and favorites after auth confirms there is no session, instead of deleting them because the document was never classified. (#7073, @simplesagar)
Speakeasy Team
Speakeasy Team
View on GitHub
// October 2, 2026v1.35.2

Platform

Security and Policy

Reveal the evidence behind a finding from an MCP tool call, and risk policies apply only to their audience

A finding raised by an MCP tool call can now be opened to see the content that triggered it, the same as a finding raised in a chat. Reveal used to fail outright on those findings, so an investigation that started in Risk Events or the Watchdog drawer stalled at a masked value with nothing behind it. Risk policies scoped to an MCP server also stop over-reaching: a policy aimed at named users, roles, or agents no longer fires for every other caller of a matching tool. More on this in Risk events and Guardrails.

Features

  • Evidence behind an MCP tool-call finding can be revealed — Reveal a masked match on a finding that came from a tool call and see the content that matched, under the same chat:read check and the same audit entry as a chat finding. Findings recorded before this change read "Evidence not stored" rather than failing with an error. (#6946, @vishalg0wda)

Bug fixes

  • An MCP-scoped risk policy applies only to its audience — A policy targeted at specific users, roles, or agents no longer applies to other callers of a matching MCP tool, so a narrow policy stops producing findings for people it was never aimed at. (#7035, @vishalg0wda)
  • Prompt-based guardrails keep judging when provider credit runs low — The prompt-injection and prompt-policy judges are capped at 8192 completion tokens, so a model provider no longer refuses them outright when the remaining credit on a key sits below the model's full output ceiling. A credit refusal or a truncated completion now reports itself as such instead of a generic error. (#6999, @bradcypert)
Speakeasy Team
Speakeasy Team
View on GitHub
// October 2, 2026v1.35.1

Platform

Identity

MCP Gateway

Remote MCP servers get their upstream tokens from your identity provider, so users stop connecting each one by hand

Where a remote or tunneled MCP server is bound to your identity provider for enterprise-managed authorization, its upstream token now comes from the signed-in user's provider rather than from a connection the user has to establish server by server. The platform exchanges the user's retained ID token for an identity assertion, redeems it at the server's authorization server, and reuses the result until shortly before it expires. Readiness reflects what those exchanges actually observe, so a server that looks confirmed but refuses real traffic says so. Organization administrators with an Okta connection also get MCP servers suggested from their synced Okta applications, rolling out behind the okta-connections flag. More on connecting providers and registering their clients in Remote identity providers.

Features

  • Upstream tokens obtained from the signed-in user's identity provider — A remote or tunneled server with a ready identity chaining binding obtains its downstream access token by exchanging the user's retained ID token at the server's authorization server, so users are not asked to connect those servers one at a time. An interactive connection still takes precedence, and a server without a binding keeps its existing sign-in behavior. (#6902, @bflad)
  • Readiness reflects what exchanges observe — A confirmed server reads Verified once an exchange succeeds, returns to Not confirmed when the provider rejects the target, and reads Not working when scopes, the agent app's authentication, or the server's own authorization server refuses. A confirmation whose issuer URL does not match the server's authorization server now reads Not working until the mismatch is corrected, including existing confirmations. Result changes are recorded in the audit log, and confirming again clears an earlier result. (#6926, @daviddanialy)
  • MCP servers suggested from your synced Okta applications — Organization administrators with an Okta connection can list the MCP servers their synced Okta applications point to, then dismiss or restore each suggestion. A suggestion flags an app instance whose sign-on mode cannot support Cross App Access and marks a server the organization already runs. Rolling out behind the okta-connections flag. (#7003, @daviddanialy)
  • Add a suggested server straight from the Okta Applications tab — Suggested catalog servers appear on the Okta Applications tab with add, dismiss, and restore actions, so a server observed in the directory becomes a configured one without leaving the page. (#7038, @daviddanialy)
  • Identity providers get their own tab — The IDP and SSO page now opens on an Identity providers tab in place of Enterprise Managed Auth, matching the order of the work: a provider such as Okta is connected first, and enterprise-managed authorization is one use of that connection. The Okta page's Setup tab keeps only the connection itself. (#7032, @daviddanialy)
  • Pick client scopes from a multi-select — Choosing scopes for a manually configured identity provider client lists the scopes the server and the provider advertise, and a scope that is not listed can still be typed in and added. (#7068, @daviddanialy)
Speakeasy Team
Speakeasy Team
View on GitHub
// October 2, 2026v1.35.0

Platform

Identity

Platform

The Access Hub is an organization-wide page, and trusted platforms and allowed machines are editable

Workload trust belongs to the organization, so the Access Hub now lives at the organization level, in the organization sidebar under Secure, for anyone holding workload:read or workload:write. Old project URLs redirect there. A trusted platform and each machine allowed under it can also be edited in place instead of being removed and re-registered, with every edit recorded in the audit log alongside the state before and after. Note the breaking change below if you call the saved-query API. More on how roles map to scopes in Roles and permissions.

Breaking changes

  • The explore saved-query service is removed — explore.listQueries, createQuery, updateQuery, and deleteQuery are gone; Explore saves through the new widgets service instead. The query:* audit actions and the audit_log.query_event_v1 webhook event are retired rather than removed: nothing emits them any more, but audit entries already written keep their labels and existing webhook subscriptions stay valid. (#7060, @subomi)

Features

  • The Access Hub is one organization-wide page — The Hub is at /<org>/access-hub, listed in the organization sidebar under Secure for anyone holding workload:read or workload:write, and old project URLs, including a trusted platform's page, redirect there keeping the issuer, query, and hash. The workloadIdentities API no longer needs a project when called from a dashboard session, which reads and writes the organization tier; API-key callers still name a project. (#7010, @aa-wong)
  • Edit a machine's allowed access in place — Each machine on a platform's page has an Edit action that opens the access form prefilled, so its label, tags, and assigned agent can be changed without removing and re-allowing it. The subject and its match kind stay fixed once access is allowed, reassigning the agent also applies to the same subject's access at the other tier, and each edit is recorded in the audit log with the machine's state before and after. (#7007, @aa-wong)
  • Edit a trusted platform in place — A platform's page has an Edit action that opens the registration form prefilled, where its name, description, tags, and JWKS URI can be changed. The issuer URL and the wildcard admission setting stay fixed once a platform is registered, and each edit is audited with the platform's state before and after. (#7005, @aa-wong)
  • The Access Hub reads more plainly — The page opens with a one-line summary of what it is for, each platform card shows only its name, description or issuer URL, and tags, and on a platform's page the issuer and keys URLs sit on labeled lines of their own. (#7004, @aa-wong)
  • Tailscale private access works on any plan once enabled — An organization enabled for Tailscale private access keeps it on any plan, instead of the dashboard warning that private access is no longer available after a move off Enterprise. (#7014, @TristanSpeakEasy)
  • List a project's chats from Platform MCP — A metadata-only list_chats tool lists one project's chats over a bounded window with masked participants, whether risk was present, timestamps, message counts, and opaque cursors. It never returns titles, message content, or raw identities, so an agent can find the conversation worth investigating without reading it. (#6857, @simplesagar)
  • Explore's saved questions become widgets — A widget keeps a question together with the chart that draws it, and the chart is checked against the question on save and again on read, so an impossible pairing fails visibly instead of rendering an empty frame. Any member can list, get, save, update, and duplicate a widget, and duplicating is how a widget is shared, giving the caller their own copy. Deleting someone else's widget needs project write access, and every change is audited. (#7058, @subomi)
  • Role plugins are prepared automatically for new organizations — A new organization gets a plugin created or reused for each application role, ready to configure for distribution rather than assembled by hand. An auto-created plugin is empty and non-default, exposes its origin, and never replaces an existing plugin's name, contents, or audiences. (#7041, @alx-xo)

Bug fixes

  • Plugin assignments follow a deleted role out — Deleting an organization or global role, including a directory-synced one, removes its plugin assignments, while assignments for other roles and organizations are left alone. (#7043, @alx-xo)
  • The catalog install's Guardrails step loses a redundant button — Switching the recommended policy off and adding the server already installs it without a guardrail, so the Skip for now button is gone. (#7012, @dennnis-ez)
  • Long toolset slugs resolve again — A stored slug longer than 40 characters is now accepted on lookup instead of being rejected as invalid. (#7066, @simplesagar)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 30, 2026v1.34.0

Platform

Identity

MCP Gateway

Platform MCP can add more than five servers per project, and workload trust moves into one Access Hub

Adding MCP servers through the Platform MCP no longer stops at five per project, so an assistant migrating a large client's servers can finish in one pass. Workload identity management also gets a dedicated home: the Access Hub replaces the Workload Identities page with a card grid of trusted platforms and their allowed machines, where a wildcard admission's reach is stated where it's written instead of asked about up front.

Features

  • Platform MCP keeps adding servers past five per project — Registering MCP servers through the Platform MCP no longer stops at five per project, including projects where some servers were later deleted. (#6964, @qstearns)
  • The Access Hub replaces the Workload Identities page — Trusted platforms and their allowed machines now live in a card grid with side-pane forms, full-width search, and typed confirmation for destructive actions. Registering a platform no longer asks whether wildcard admission is allowed; the admit form infers a rule's match kind from a trailing * and states which subjects it would admit and which agent they'd inherit at the point it's written. Platforms and machines can also carry a description and tags, shown on their cards and included in search. (#6948, #6820, @aa-wong)
  • Rotate the Observability plugin's ingest credential from the dashboard — Organization admins can mint a replacement hooks-scoped key from the Plugins page, shown once in plaintext, and choose whether the previous key is revoked immediately or kept valid for a 7-day grace window. Installed plugin copies and consumer MCP keys are left untouched. (#6831, @bradcypert)
  • A Ranked chart type joins Explore — Whole-window results can now draw as horizontal bars, one per group and ranked largest first, the same style already used on MCP & Tools. (#6961, @subomi)
  • Managing an agent's upstream connections no longer needs a second login — Agent connection management now reuses the authentication already established by the OAuth consent flow, including on custom MCP domains, instead of requiring a separate dashboard session. (#6944, @danielkov)
  • Guardrails scoped to specific MCP servers (rolling out) — Risk policies can target individual MCP servers, built-in Platform MCP toolsets, and tools, with flag and block actions, and findings now show the server, tool, and outcome instead of an untitled session. The MCP server filter is live now on Risk Events; the rest is rolling out behind the gram-mcp-scoped-policies flag. (#6935, #6937, #6923, #6938, #6947, @vishalg0wda)
  • Platform MCP ranks a project's skills by impact — get_skill_insights ranks skills by activations, sampled efficacy, session cost, and estimated time saved, or compares one skill's versions against each other. (#6858, @simplesagar)
  • Copy device agent org values straight from setup — The Device Agent Setup tab gains an Organization values card with copy buttons for org_slug and org_token, and the token button now reads "Re-generate token" once a token exists, minting an additional token rather than rotating the deployed one. (#6966, @svadrutk)
  • A remote identity provider's scope override is easier to find before it bites — The provider's Overview and Settings tabs now show the scope override directly, and a warning with a link to the provider's settings appears everywhere a client's scopes are edited, since the override makes those edits inert. Platform admins can additionally see and migrate clients still running in legacy callback compatibility mode. (#6813, @qstearns)

Bug fixes

  • The identity provider picker works at any catalog size — Remote MCP server settings no longer show an attached identity provider as missing once the platform catalog grows large: the picker now searches on the server, loads more on demand, and lists each tier (project, organization, platform) with its own "more" row. (#6969, #6974, @qstearns)
  • Blocked private network cleanup tells you what to do next — When Tailscale rejects a saved OAuth client, cleanup now shows "Cleanup blocked" with next steps instead of staying on "Cleaning up" indefinitely, and keeps retrying through longer outages. (#6959, @TristanSpeakEasy)
  • Risk Events stop going empty when every policy is disabled — Findings from disabled (but not deleted) policies now keep showing, marked inactive, so turning a policy off no longer hides its history. (#6924, @vishalg0wda)
  • Sessions minted from the dashboard are labeled "Dashboard" — The connections list now shows a name for sessions Inspect mints to call an issuer-gated remote MCP, instead of a blank client name. (#6985, @simplesagar)
  • Logins, billing, and Slack links stay on the platform host you're using — Platform MCP, the install page, the Stripe billing portal, Polar checkout, and Slack unfurls now all return to the platform host a request arrived on, such as ai.speakeasy.com, instead of falling back to the default. (#6838, #6842, @adaam2)
  • The "Request access" link lands you somewhere you're already signed in — MCP server and Platform MCP access-denied errors now point the "Request access" link at the platform host the request came in on. (#6979, @adaam2)
  • Device agent fleet config saves again after admin-only release controls are set — Organization admins can save their fleet configuration again once a Speakeasy admin has set the update channel or blocked versions, instead of hitting a permissions error. (#6982, @adaam2)
  • Unproxied remote MCP servers save without a connectivity check — Servers that clients connect to directly can now be saved without first passing a reachability check, since those servers are often unreachable from our infrastructure. (#6963, @qstearns)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 29, 2026v1.33.0

Platform

Identity

A direct grant can override an inherited role block, and the command palette's actions run in one keystroke

Administrators can now block an MCP server for a role, including a directory-synced one, and still give individual members of that role access to it by name, without restructuring role membership. The command palette also gets faster to use: reversible actions apply on the first Enter with an Undo in the toast, and directory-mapped roles are now visible everywhere the dashboard lists who holds what. More on this in Identity provider setup and User sessions.

Features

  • A direct grant now outranks an inherited role block — A grant made directly to a person for a specific resource outranks a block they inherit from a role or from everyone, so an admin can block a server for a whole role and still hand access to one member by name. The MCP server access page shows who keeps access through their own rules before a role or everyone is removed from a server. (#6887, @bflad)
  • The command palette's reversible actions run in one keystroke — Enabling or disabling a server from the ⌘K palette now applies on the first Enter, with an Undo in the toast that restores exactly the visibility the server had. Actions render under their own heading, separated from navigation matches, and only irreversible actions such as publishing the plugin marketplace still ask twice. (#6882, @simplesagar)
  • Choose when a Slack assistant replies — Set a trigger to reply only when @-mentioned, to join a thread after an @-mention and keep replying there until it steps out, or to any message in its channels. An assistant following a thread catches up on what it missed when an @-mention brings it back, and it never replies to its own messages. (#6847, @danielkov)
  • A remote MCP server's User Identity client is easier to read and change — A connected client now reads as "Connected" with how many people are signed in and its scopes, with an Advanced link to the client. Clearing it offers an existing client, Auto-Configure, or Manual credentials, and Auto-Configure can choose between CIMD and DCR when a provider supports both. remoteSessions.count reports how many distinct people hold a live session through the client. (#6906, @qstearns)
  • Directory-mapped roles show up everywhere roles do — Members who get a role through a directory group or attribute mapping already had its permissions; now the Team page, Roles & Permissions, role filters, and plugin reach all show them too, marked as coming from the directory since they can't be removed there directly. (#6904, @qstearns)
  • AI integration credentials are checked before they're saved — Saving a new or changed API key now probes the provider first, so a key missing the entitlement its provider requires is never stored and never starts polling that was always going to fail. See AI Integrations. (#6611, @speakeasyforgebot)
  • Migrate existing client MCP servers into the platform from any agent client — The Platform MCP add-existing-mcp-servers workflow now works from any agent client, reports local servers unchanged, and can optionally move migrated servers onto the organization's private Tailscale network. (#6894, @TristanSpeakEasy)
  • Tunneled MCP servers carry a verifiable caller identity — Signed caller assertions now use the tunneled server's saved resource identifier as their audience, shown on the server's settings alongside the organization ID the assertions carry. (#6723, @ThomasRooney)
  • Platform MCP gains six tools for risk, usage, skills, and access — list_risk_findings, list_risk_findings_by_chat, and get_risk_rule_breakdown read the same data as Risk Events; get_tool_usage_summary breaks tool calls down by what they reached; mark_risk_findings_false_positive and unmark_risk_findings_false_positive dismiss or restore Watchdog findings; and list_skill_distributions and undistribute_skill manage which plugins carry which skills. The project's managed assistant can also list and inspect its own plugins and look up organization members by name. (#6850, #6852, #6855, #6861, #6854, #6851, @simplesagar)

Bug fixes

  • Remote MCP servers verify on protocol version 2026-07-28 — The verification probe now asks a server to describe itself with server/discover and falls back to the initialize handshake, so servers that only implement 2026-07-28 are recognized as MCP servers instead of being rejected. (#6871, #6872, @bflad)
  • MCP clients are prompted to reconnect instead of retrying a dead upstream session — When an issuer-gated server's upstream connection can no longer refresh, clients now get a 401 that explains the upstream needs reauthorization instead of a silently repeated rejection. (#6876, @bflad)
  • The MCP scope picker keeps focus after you narrow a server — Unchecking every tool on a server's scope now normalizes to "every tool on this server" instead of being rejected, and the picker no longer jumps to the first server in the list after you deselect one with many tools. (#6878, @dennnis-ez)
  • Okta setup checklist follows the order the Okta console expects — The public-key steps now run save-key-URL-first, then switch client authentication, with required API scopes and admin roles listed one per line. (#6877, @daviddanialy)
  • Meta MCP connections clean up reliably — Member calls and consent verification now use the official MCP SDK client, preserving tool result precision and cleaning up legacy sessions even after a failed connection. (#6870, @bflad)
  • Remote MCP readiness checks stop retrying a failure five times over — A failed readiness check now logs why and checks once instead of retrying its connection repeatedly. (#6890, @simplesagar)
  • Removing yourself from a risk policy's audience fails safely — Self-removal from a policy's audience now fails closed instead of risking a table-wide grant lock, while administrator-requested audience changes still go through. (#6888, @svadrutk)
  • New organizations keep working through a control-plane outage — Hook enforcement now fails open by default for newly created organizations; existing organizations keep whatever fail-open or fail-closed setting they already chose. (#6913, @mfbx9da4)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 28, 2026v1.32.0

Platform

MCP Gateway

See observed traffic before switching an MCP server to private-only access

Switching an MCP server or gateway between public and private access used to mean guessing whether every client had already moved off the old route. The Network access panel now shows observed public and private traffic for a server or gateway, so you can check which route clients still use before switching to private only, or back to public. More on this in Tailscale private access.

Features

  • See which route your MCP traffic actually uses — The Network access panel attributes request duration to the public or private surface alongside the existing MCP URL, so you can confirm a route is unused before switching a server or gateway to private only, or back to public. (#6827, @TristanSpeakEasy)

Bug fixes

  • Platform MCP usage metrics attribute to the right server — query_mcp_metrics now counts calls proxied to a remote, tunneled, or gateway-member server instead of reporting zero activity beside nonzero latency, and get_project_overview folds the names calling apps used for a server onto that server's own ID. (#6841, @simplesagar)
  • Platform MCP tool results stay compatible as schemas grow — Tools advertise output schemas that accept properties they don't name, so an agent that connected before a result gained a new field keeps working instead of rejecting it. Listing and inspecting MCP servers that sit in a plugin no longer fails the client's schema check. (#6839, @simplesagar)
  • The Inspect "Connect" button stops opening a missing route — Connect is now offered only for issuer-gated servers on a hosted address; other servers point at authentication settings instead. (#6845, @simplesagar)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 27, 2026v1.31.3

Platform

Security and Policy

Risk policies can target chosen MCP servers, gateways, and tools

A risk policy no longer has to apply everywhere. The scope step gains a mode switch between Everywhere and Selected MCP servers, with a two-pane picker for the servers and their tools and a tool rule you can set per server. Policies written this way are restricted to tool traffic, which is what makes narrow targeting safe: an Inspect matrix replaces the old per-category rows, and in MCP mode the User and Assistant categories are unavailable rather than silently ignored. Organization admins can also turn the device agent's Shadow AI scan off from the fleet configuration, for fleets where that scan is not wanted.

Features

  • Scope a risk policy to selected servers and tools — The scope step offers Everywhere or Selected MCP servers, with a two-pane picker carrying an All MCP servers row, per-server tool lists, and a tool-rule popover over MCP annotation hints. An Inspect matrix covering User, Tool requests, Tool responses, and Assistant replaces the per-category scope rows, with CEL editing kept for Everywhere. In MCP mode, User and Assistant are unavailable, Tool responses is noted as applying once response scanning ships, and Block policies carry a latency note. See Guardrails for how scope, detection, and action fit together. (#6785, @vishalg0wda)
  • Turn off the device agent's Shadow AI scan — Organization admins can disable the device agent's Shadow AI scan from the fleet configuration, covered in Shadow AI. (#6703, @AshGodfrey)

Bug fixes

  • Scoped policies save without a tool list per server — Creating or updating a risk policy scoped to selected MCP servers no longer fails with a "length of body.tools must be greater or equal than 1" error when a server follows the policy tool rule. (#6824, @vishalg0wda)
  • Hook sessions stay with the project that opened the chat — Hook ingest pins a session to the project that first created its chat, so a later request carrying a different project header cannot stamp messages onto that chat. Chat list counts and last-message times ignore those sibling-project rows. (#5239, @speakeasyforgebot)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 27, 2026v1.31.2

Platform

Identity

Directory groups grant roles on their own, and Slack accounts resolve to the people behind them

Roles stop being a manual list. An organization admin can map a directory group, or a directory attribute value such as department_name=Sales, to a role, and every member who matches picks that role up on top of whatever was assigned to them directly. Groups can be pulled in and mapped before any directory event delivers them, and role member counts include people who hold a role only through a mapping. Slack arrives as a work identity in the same release: connect one or more workspaces under Identity, sync and browse the directories, and map Slack members to the people already in your organization, so an account posting in Slack and a person in the platform are one record rather than two. More on this in Roles and Permissions and IDP and SSO.

Features

  • Map directory groups and attributes to roles #6821 - Organization admins map a directory group, or a directory attribute value in key=value form, to a role, and matching members receive it alongside their direct assignments. syncDirectoryGroups pulls groups from the organization's linked directories so they can be mapped before an event delivers them, with webhook events remaining the source of truth: the listing never restores a group an event deleted and never overwrites a newer row. Setting and removing a mapping are audited under the directory_role_mapping subject, and role member counts include members who hold the role only through a mapping. (Author: @adaam2)
  • Connect Slack workspaces under Identity #6715 - Organization admins connect workspaces through Slack OAuth from a Slack workspaces tab and disconnect them from the list. Connecting a listed workspace again reauthorizes it in place, so there is no separate reconnect step. Credentials stay encrypted, workspace changes are audited, and the tab requires an organization admin browser session: API keys and support sessions are refused. (Author: @ThomasRooney)
  • Sync and browse Slack directories #6719 - Directories sync after a connection or on an admin's request, with workspace sync history, member counts, and a searchable read-only directory across workspaces. Complete snapshots preserve identity mappings and retained membership. (Author: @ThomasRooney)
  • Map Slack members to people #6726 - An inline picker lets organization admins map Slack memberships to existing personnel, reassign or remove mappings, and review directory changes without granting new permissions. A sync maps members whose email matches exactly one person. (Author: @ThomasRooney)
  • Work identities on a person's Accounts and devices page #6732 - Mapped Slack workspace accounts appear under Work identities. Employees can read their own mappings and contact an administrator for corrections, while organization admins review an active person's exact membership. (Author: @ThomasRooney)
  • Identity setup is one task with three steps #6793 - The setup board carries a single "Set up identity provider" task covering domain verification, single sign-on, and directory sync, replacing the separate "Verify your domain" task and the legacy connect and directory-sync tasks. (Author: @adaam2)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 27, 2026v1.31.1

Platform

Identity

MCP Gateway

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. More on this in Remote MCP servers and Agent identity.

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)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 27, 2026v1.31.0

Platform

MCP Gateway

The latest models reach the pickers, and published plugins work on OpenCode 2 again

Claude Opus 5.5, Claude Fable 5.1, the GPT-6 family, Gemini 3.8 Flash, Grok 4.7, and the rest of the current OpenRouter lineup are selectable in the playground, chat, and assistant model pickers. OpenCode 2 is no longer a dead end for published plugins: both the plugin loader and the observability plugin are generated to load on OpenCode 2 as well as OpenCode 1, so MCP servers and skills register again and hook events and enforcement resume. The product can also be served on extra first-party hosts, so a deployment reachable at a second domain behaves like the primary one through login, consent, and telemetry. More on this in Model Provider Keys and OpenCode.

Features

  • The latest OpenRouter models in every picker #6840 - Claude Opus 5.5, Claude Fable 5.1, GPT-6 Astra, GPT-6 Sol, GPT-6 Luna, Gemini 3.8 Flash, DeepSeek V4.1 Flash, Grok 4.7, Qwen3.8 Max, Qwen3.8 Flash, GLM-5.3, and Kimi join the playground, chat, and assistant model pickers. (Author: @simplesagar)
  • Serve the product on extra first-party hosts #6795 - Hosts listed in GRAM_PLATFORM_HOSTS serve the full product alongside the server URL's own host. A login started on such a host calls back and lands on that same host, and the dashboard reports telemetry for the extra host to the production projects. (Author: @adaam2)
  • The command palette ranks by intent #6688 - The command palette ranks results by what you appear to be trying to do rather than by substring match, deciding which candidate you mean, which action to take on Enter, and whether the intent is settled enough to act on. It uses the organization's existing model key with no new configuration; an organization without a resolvable key keeps the previous behavior and makes no outbound call. (Author: @simplesagar)

Bug fixes

  • Published plugins load on OpenCode 2 #6791 - OpenCode plugin loaders are generated to work on OpenCode 2 as well as OpenCode 1, so published plugins register their MCP servers and skills again. (Author: @bradcypert)
  • Hook events and enforcement resume on OpenCode 2 #6794 - The generated OpenCode observability plugin loads on OpenCode 2 as well as OpenCode 1. (Author: @bradcypert)
  • Upstream login returns to the host it started on #6819 - Connecting an upstream service from the MCP consent page on an extra platform host returns to that host after the upstream login, instead of failing with an "authn challenge state does not match this MCP server" error. (Author: @adaam2)
  • Transcripts open faster on Agent Sessions #6207 - chat.load reads token and cost metrics from session summaries, skips Claude OTEL scans for non-Claude chats, and runs the remaining enrichment in parallel. (Author: @speakeasyforgebot)
  • Tailscale identity headers accepted #6768 - Tailscale identities whose names begin with RFC 2047 Q-encoded characters, and empty optional profile-picture headers, are accepted. (Author: @bflad)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 24, 2026v1.30.0

Platform

Security and Policy

A detected AI tool now opens onto the people running it

Shadow AI told you an unsanctioned tool was in the building. It now tells you who has it. Opening a row on the Harnesses, Assistants, or Local Models tab expands the tool into the enrolled users it was detected for, each with their devices, signals, versions, and first and last sightings, and each linking through to their identity page. Linked alias emails fold to one person, so a colleague with three addresses is one row rather than three. This is the identity page's Shadow AI table turned around: instead of starting from a person and seeing their tools, you start from a tool and see its people, which is the direction an access decision usually runs. More on this in Shadow AI and Identities.

Features

  • Shadow AI tools expand onto their users #6735 - A new access.listAIDetectionUsers read takes a detection target and returns the tool's inventory row plus one row per enrolled user it was found for, with device count, signals, versions, and first and last seen. Linked alias emails fold to the canonical identity through the same fold the inventory's user count already uses. The Harnesses, Assistants, and Local Models tabs each gain a nested route showing that list, every user links to their identity page, and access decisions move to the row's context menu and a button on the tool page. A target with no detections in the organization reads as not found. Available to organization admins, the same audience as the Shadow AI inventory itself. (Author: @subomi)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 23, 2026v1.29.3

Platform

Identity

Agent key creation survives agents with many servers, and delegated credentials recheck authority before they refresh

Creating an API key for an agent that fronts a lot of MCP servers no longer times out: permission discovery for every server the agent can reach happens in one request instead of one per server. Delegated credentials also stop trusting a stale picture of who authorized them. Authorization is rechecked live before a refresh, a rotated credential is quarantined rather than replayed when identity verification is unavailable, and a federated retry is refused outright when the trusted issuer URL has changed, even if the issuer and client ids look the same. More on this in Agent identity.

Bug fixes

  • Agent key dialogs stop timing out on large agents #6742 - Delegable API key permissions load for all of an agent's MCP servers in one request instead of one per server, so the create API key dialog no longer fails with lock timeouts on agents with many servers. (Author: @adaam2)
  • Delegated refreshes recheck authority first #6696 - Live authorization is rechecked before a delegated credential refresh, claim cleanup is scoped to its own issuer, and a rotated credential is quarantined rather than replayed when identity verification is unavailable. Terminal configuration secrets are cleared, while retryable provider dependency failures are preserved. (Author: @danielkov)
  • Federated retries refused when the issuer URL moves #6697 - A federated delegation retry is rejected when the trusted issuer URL has changed, even if the issuer and client ids are unchanged. Private endpoint authority is revalidated before consent actions consume retry state or access credentials, and consent state is preserved when authority has been revoked or repointed. (Author: @danielkov)
  • Agent creation races project deletion no longer #6695 - Project-bound agent creation is serialized with project deletion. A project with no visible agents shows the agent creation empty state, and settings headings line up with the controls they describe. (Author: @danielkov)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 23, 2026v1.29.2

Platform

Platform

Agents act as themselves: scoped keys, their own upstream accounts, and their own name in audit and usage

An agent is now a principal in its own right rather than something borrowing a person's identity. Agent API keys carry explicit permissions, and two new agent-runtime-safe grants let a key poll its plugins and send hook events without being able to reach anything else. Events an agent reports are attributed to the agent itself: a self-reported email or a cached session identity never re-attributes them to a person. Agents can own upstream accounts directly, with session and grant-generation checks enforced through OAuth and tool execution, and their delegated access is scoped to a selected MCP server while live policy exclusions still apply. More on this in Agent identity and API keys.

Features

  • Agent keys carry explicit, narrow permissions #6405 - Agent API keys can poll agent.getPlugins when the agent holds the new org:device_agent_sync grant, and send hook events when it holds org:hooks_ingest. Both scopes are agent-runtime-safe and registered in delegated-policy version 2. The plugins response includes the agent's principal, and plugins resolve for the agent, its roles, and the organization wildcard. Hook events are attributed to the agent itself, agent sessions are stored without requiring an email, and the OTEL and LiteLLM ingestion endpoints continue to reject agent keys. (Author: @bradcypert)
  • Agents own their upstream accounts #6382 - Owned upstream accounts attach to agents with exact session and grant-generation checks enforced throughout OAuth and tool execution. (Author: @danielkov)
  • Delegated access scoped to one server #6379 - Agent delegation is scoped to a selected MCP server while live policy exclusions are preserved, and creating or rotating an agent key requires explicit permissions. (Author: @danielkov)
  • Agent identity survives into sessions and usage views #6365 - Agent MCP credentials are scoped to live delegable access, agent-owned upstream account bindings are supported, and the agent's identity is preserved in sessions and usage views rather than collapsing into the person who created the key. (Author: @danielkov)
  • Durable delegation credentials #6584 - Encrypted OIDC delegation credentials are retained with lazy renewal, bounded consent retry, and sanitized organization-admin status. (Author: @danielkov)

Rolling out

  • Workload assertion grant at the MCP token endpoint #6622 - A workload with no client registration exchanges its platform-issued identity token for a session scoped to one named MCP server, available to organizations on the agent authorization rollout. The grant resolves the token's issuer to a trusted workload issuer, verifies it against that issuer's published keys, requires exactly one audience naming the endpoint, refuses a replayed token, admits the subject through the tenant's workload admissions, and requires a live assigned agent. The session has no client and no refresh token and lasts 15 minutes. Every verification or admission failure answers the same invalid_grant; outages answer 503 and rate limits 429, both with Retry-After. (Author: @aa-wong)
  • Workload identifiers must use https #6515 - A workload assertion naming a plain-http issuer is untrusted, and an issuer row with a plain-http jwks_uri is refused before any key set is fetched. Assertions whose JOSE typ header marks them as a WIMSE Workload Identity Token or an RFC 9068 access token are rejected outright, since those credentials must never be exchanged as bearer grants. (Author: @aa-wong)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 23, 2026v1.29.1

Platform

Security and Policy

Watchdog alerts are readable from Platform MCP, and the risk model can be compared before it enforces

Watchdog no longer requires a trip to the dashboard: a read-only Platform MCP tool serves rule-level alerts, the affected users and client surfaces, and fully redacted sampled evidence, so an agent can pull the same picture an admin would. The risk engine flag also becomes a mode rather than a switch, adding a shadow setting where the fine-tuned risk model scans the same traffic alongside the existing engines without ever denying a request on its own, so its verdicts can be compared before anything changes. Anthropic inference hooks now return a verdict inside the provider's default five second window instead of being cut off mid-evaluation. More on this in Watchdog and Platform MCP.

Features

  • Watchdog alerts in Platform MCP #6557 - A read-only list_watchdog_findings tool surfaces rule-level Watchdog alerts, the affected users and client surfaces, and fully redacted sampled evidence. (Author: @svadrutk)
  • Compare the risk model before it enforces #6636 - The gram-risk-llm-analyzer flag now selects a risk engine mode per organization. off keeps the gitleaks, Presidio, prompt-injection, and destructive-tool engines; shadow keeps those engines enforcing while the fine-tuned risk model scans the same traffic so its verdicts can be compared, never denying a request on its own; llm swaps the engines for the model as before. Organizations on the existing boolean flag keep today's behavior until the flag is switched to multivariate. (Author: @dennnis-ez)
  • Shadow verdicts kept for comparison, never enforced #6637 - Organizations running shadow mode keep the risk model's verdicts in the findings store, marked so they can be compared with the legacy engines' findings per message. Shadow findings are never enforced and never appear in Risk Events, the Dismissed listing, the overview, signals, the Watchdog, reveal, or OpenTelemetry data exports. (Author: @dennnis-ez)

Bug fixes

  • Inference verdicts return inside the provider timeout #6610 - Feature flags resolve once per delivery rather than once per scanned input, inputs are scanned concurrently, and a long transcript that still cannot be fully evaluated in time is denied with a retry message while the evaluated messages are checkpointed, so the retry scans only the remainder. (Author: @danielkov)
  • Hooks session state is scoped to the project that owns it #6668 - Session MCP inventory snapshots, their inventory-read status, and the session agent variant are cached per project, and only a sender authenticated to that project can write them, so a hooks key from one project can no longer change what the shadow-MCP guard reads for the same session id in another project. MCP inventory reported by unauthenticated Claude hooks is no longer recorded, and the first project to attribute a session claims its cached identity atomically, so another project's OTEL export cannot redirect a session's unauthenticated hooks. Sessions already in progress at deploy lose their cached inventory snapshot until their next inventory report. (Author: @bradcypert)
  • Large attachments stop forcing fail-open scans #6641 - Realtime risk enforcement truncates scan inputs at a 50 KiB default instead of 1 MiB, adjustable through a feature flag, which cuts the timeout-driven fail-open scans that large prompt attachments were causing. (Author: @vishalg0wda)
  • Client registration failures say which kind they were #6360 - Automatic OAuth client registration failures are classified as unreachable or refused, with bounded diagnostics recorded for dynamic client registration and Client ID Metadata Document callbacks. (Author: @qstearns)
  • Plugin publishes no longer wait on the hourly sweep #6596 - A plugin package publish triggered by someone who is not a member of the project's organization publishes right away under an existing organization member instead of failing and waiting for the hourly sweep. A publish that cannot find any member is recorded once rather than retried. (Author: @danielkov)
Speakeasy Team
Speakeasy Team
View on GitHub
// September 23, 2026v1.29.0

Platform

Identity

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. More on this in Remote identity providers.

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)
  • Domain verification before single sign-on setup #6718 - WorkOS refuses to start an SSO connection until a domain is verified, so the IdP and SSO page gains a Domain verification card that opens the WorkOS Admin Portal, then lists every verified domain once verification completes. Until a domain is verified the Single Sign-On and Directory Sync cards are dimmed with their Configure buttons disabled and a warning explaining why, and the setup board adds a "Verify your domain" task that the identity provider task depends on. Organizations with an active SSO connection are treated as verified and are not blocked. (Author: @adaam2)
  • 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)
Speakeasy Team
Speakeasy Team
View on GitHub