The gateway refuses AI agents captured by Shadow AI that your organization has blocked, and Pi sessions land in the dashboard under policy

Features

• Blocked AI agents are refused at the gateway #6385 - The gateway matches each caller by its CIMD vendor key, OAuth client id, or the client name it reports at initialize, then applies the organization's decision for that AI agent. Blocking takes effect for callers that present a CIMD client id; anything else stays unreviewed. One vendor registry now backs both the Shadow AI scan catalog and the CIMD admission catalog, so an AI agent captured by Shadow AI and the caller admitted at the gateway are the same record, and a vendor key claimed by one product can no longer take a sibling product down with it. (Author: @subomi)
• Pi sessions captured and governed #6445 - Pi has no hook configuration dialect and no MCP client of its own, so observability ships as a TypeScript extension loaded into the Pi process that forwards lifecycle events to the hooks relay. Prompts, tool calls and their results, per-turn tokens and cost, and session start and end land in the dashboard under the pi source, and a policy deny blocks the prompt or tool call inside Pi. The relay reads the MCP config third-party Pi extensions share, reports the servers a workspace can reach as an inventory snapshot with credentials redacted, and attributes tool calls to the matching server so Pi traffic is visible to Shadow MCP instead of appearing as unattributed local tools. The package downloads per platform from the plugins page, and speakeasy-hooks install --provider=pi renders the same extension locally. (Author: @speakeasyforgebot)
• Valid members connect without a separate dashboard login #6450 - MCP server and Platform MCP logins reconcile organization memberships from WorkOS before checking access, the same way dashboard login does. Membership additions from WorkOS also drop the cached organization list immediately. (Author: @daviddanialy)
• Assistants authenticate with a stable client identity #5594 - Assistants can authenticate to CIMD-capable MCP OAuth servers with a Client ID Metadata Document instead of registering a new client dynamically. The one-client-per-assistant dynamic registration path stays the default and the fallback where CIMD is unsupported. (Author: @speakeasyforgebot)
• ID-JAG bearer grants for enterprise authorization #6496 - User session token endpoints configured with a trusted remote session issuer accept ID-JAG JWT bearer grants. A successful exchange issues a short-lived, resource-bound access token with no refresh token, and authorization server metadata advertises the grant only where the issuer is configured to accept it. (Author: @bflad)
• Signed client assertions for remote OAuth #6346 - Remote session clients support private_key_jwt authentication for token exchanges and refreshes, selecting an attached organization JSON Web Key Set and choosing whether assertions use the issuer URL or the token endpoint URL as their audience. (Author: @bflad)
• ChatGPT Classic reported as running, not just installed #6451 - The scan target carries the app's process name alongside its bundle id, so a device agent tells an open app apart from one that is merely present. Classic stays distinguishable from the current ChatGPT app, which ships under a different bundle id. (Author: @subomi)
• Issuers reachable only through a tunnel #5534 - A remote session issuer can be bound to a tunneled MCP server, routing the whole back channel through the tunnel when the authorization server is unreachable from the public internet: code exchange, token refresh, revocation, dynamic client registration, the issuer's JWK Set, and the userinfo and introspection calls that name a session's owner. Replacing a client registration the identity provider no longer recognizes rides the same binding, so a private provider's clients recover on their own. Tunnel bindings and tunneled dynamic client registration are platform-admin only. (Author: @qstearns)