Changelog

Risk policies can target chosen MCP servers, gateways, and tools instead of everything

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 #6785 - 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. Inline validation requires All MCP servers or at least one selection. (Author: @vishalg0wda)
• Turn off the device agent's Shadow AI scan #6703 - Organization admins can disable the device agent's Shadow AI scan from the fleet configuration. (Author: @AshGodfrey)

Bug fixes

• Scoped policies save without a tool list per server #6824 - 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. (Author: @vishalg0wda)
• Hook sessions stay with the project that opened the chat #5239 - 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. (Author: @speakeasyforgebot)

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.

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)

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.

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)

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.

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)

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.

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)

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.

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)

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.

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)

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.

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)

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

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

Features

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

Workload sessions are labeled on the MCP Sessions page, and Platform MCP brings existing servers under management

A session opened by a workload no longer looks like a person's. The MCP Sessions page marks those rows as workloads, names the issuer they came from, shows the agent they act through, and lists every admission currently letting them in. The revoke dialog spells out which controls actually stop a workload, ordered from narrowest to widest, so nobody mistakes ending one session for cutting off access. Platform MCP setup gains an optional step for bringing the remote MCP servers already configured in Claude Code under management, and remote MCP URLs report structured probe outcomes instead of a single pass or fail.

Features

• Workload sessions named and explained #6503 - userSessions.list returns a workload object for workload: subjects carrying the workload issuer's name and URL, the external subject, the assigned agent and its state, and every project or organization tier admission currently letting the workload in. The dashboard marks these rows as workloads rather than people. The revoke dialog lists the controls that can stop a workload, narrowest to widest, and shows which ones stop it from reconnecting: revoking a workload session ends only that session, and the workload can exchange a new token and reconnect. (Author: @aa-wong)
• Bring existing Claude Code MCP servers under management #6518 - Platform MCP setup gains an optional second step for adopting remote MCP servers already configured in Claude Code. The workflow verifies the agent's connection, asks for informed discovery consent or a sanitized manual inventory, and prefers catalogue entries matched by endpoint or confirmed provider and name before falling back to custom URLs. It confirms the destination and the selected servers, then reports each registration separately. Authentication stays on the platform, with no local credentials migrated. (Author: @alx-xo)
• Structured probe outcomes for remote MCP URLs #6357 - A new probeURL endpoint distinguishes availability, authentication, invalid-response, and unreachable outcomes, so a URL that needs credentials reads differently from one that cannot be reached. The deprecated verifyURL endpoint stays for compatibility. (Author: @qstearns)

Spend by product for pay-as-you-go organizations, and inference scans that stop redoing work

Pay-as-you-go organizations get a spend breakdown across agent session storage, per-scanner risk scanning, and MCP gateway egress, priced at current list rates with daily, weekly, monthly, and cumulative views over billing-cycle or custom date ranges. These are usage estimates rather than invoices, and organizations on other plans see the ordinary usage explorer without the spend section. Anthropic inference hooks also stop rescanning transcript history they already cleared: only accepted content is skipped on later deliveries, while denied or interrupted scans are retried and corrected transcripts can recover.

Features

• Spend by metered product #6600 - A stacked billing chart breaks spend down across agent session storage, per-scanner risk scanning, and MCP egress using exact server-calculated estimates at current pay-as-you-go list prices, with daily, weekly, monthly, cumulative, product, and date-range controls. Inference, credits, discounts, taxes, and billing adjustments are excluded, and these ordinary-usage estimates are not invoices. Spend estimates are restricted to pay-as-you-go organizations through server-owned availability: other plans return unsupported_plan with an empty product list, and the dashboard hides the spend section while keeping the usage explorer. (Author: @disintegrator)
• Spend visualization for every account type #6602 - Billing visualization covers organizations without a Stripe subscription, reusing the same exact storage, per-scanner risk, and MCP egress estimates with product selection, billing-cycle and custom ranges, grouping, and cumulative views. Amounts display rounded to two decimals while the arithmetic stays exact, a nonzero amount that rounds to zero gets a sub-cent marker instead of reading as zero, and the last successful estimate is preserved while ranges change or a new range fails to load. Storage, risk scanning, and MCP keep consistent theme-aware colors across spend and usage graphs. (Author: @disintegrator)

Bug fixes

• Inference scans keep what they already cleared #6573 - Anthropic inference hooks distinguish archived transcript attempts from successfully evaluated history, so only accepted content is skipped on later deliveries while denied or interrupted assistant and tool scans are retried and corrected transcripts can recover. Concurrent deliveries use optimistic checkpoint updates without holding database connections during scans, and a repeated transcript longer than 512 messages no longer appends duplicate archive rows. Unknown or ambiguous history is conservatively rescanned within the existing request deadline. (Author: @danielkov)
• Checkout prices and trial conversion stay aligned #6580 - Checkout includes all pay-as-you-go metered prices, billing setup stays resumable, and trial conversion applies only after a confirmed completion. Delayed completion and subscription deletion no longer lose inference-key conversion or post-checkout cleanup, existing Checkout sessions are preserved, and setup actions show only to eligible users. (Author: @disintegrator)

Rolling out

• Okta tenant connections #6545 - An identityProviderConnections management API for connecting an organization's Okta tenant, behind the okta-connections flag and unavailable until GRAM_IDENTITY_PROVIDER_SIGNING_CREDENTIAL_ID is set. (Author: @daviddanialy)
• Okta applications reconciled on a schedule #6553 - Each verified Okta connection's applications and assignments reconcile into a snapshot on a schedule, with syncApplications and listApplications on the same gated API. (Author: @daviddanialy)

Claude Code and Codex tokens and cost reappear on usage, cost, and identity pages

Usage exported to the native OTLP ingest endpoint now reaches every usage surface, not just the event feed. Devices that switched to that endpoint had been showing tool calls with zero tokens and zero cost; those sessions are attributed to users and counted on the usage, cost, and identity pages again. Two dashboard surfaces also stop misreporting: a tool usage timeline whose buckets are all empty says so instead of drawing a labelled blank chart, and the log detail sheet no longer holds the previous record on screen while the next one is highlighted, which could show one call's arguments under another call's heading.

Features

• Native OTLP exports counted on every usage surface #6525 - Exports accepted on /otel/v1/logs and /otel/v1/metrics now run the hooks telemetry writers, so Claude Code and Codex usage sent to the native ingest endpoint is attributed to users and counted on the usage, cost, tokens under management, and identity pages. Those exports previously reached only the event feed, leaving affected devices with tool calls but no tokens and no cost. (Author: @daviddanialy)
• Pick the exact issuer and client for trusted identity provider login #6505 - Organization administrators can configure which remote session issuer and client pair backs trusted identity provider login. The API validates tenant scope, required upstream scopes, and token endpoint authentication, audits effective link changes, and stops a linked client from being invalidated or deleted. (Author: @bflad)

Bug fixes

• Empty timelines and log payloads tell the truth #6532 - A tool usage timeline whose every bucket is empty shows the no-data state rather than a labelled but blank chart, and the log detail sheet stops holding the previous record's payload on screen while the next one is highlighted. (Author: @adaam2)
• Caller cancellations no longer read as enforcement degradation #6531 - An enforcement lane failure caused by the caller canceling is not counted as degradation. Deadline and other lane failures still degrade. (Author: @vishalg0wda)

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

The MCP gateway now recognizes which AI agent is calling it and enforces the decision your organization already made about that agent in Shadow AI. A caller is matched by its CIMD vendor key, its OAuth client id, or the client name it reports at initialize, so a blocked AI agent is refused at the gateway rather than discovered later in a report. Pi joins the agents the platform observes: prompts, tool calls and results, per-turn tokens and cost, and session start and end all appear under the pi source, and a policy deny stops the prompt or tool call inside Pi instead of flagging it after the fact. A login fix also clears a long-standing snag where a valid member had to sign in to the dashboard before an MCP connection would accept them.

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)

The MCP catalog on the MCP page, editable gateway instructions, and a usage explorer backed by exact meter readings

The MCP catalog is now a tab on the MCP page next to MCP Servers, Sources, and Deployments, and catalog entries show up in the command palette as you type, in their own group so a server you could add is never mistaken for one the project already runs. Gateway instructions, the guidance every connected client receives, are editable from the gateway's settings. The billing explorer reads exact daily meter totals for stored-message tokens, MCP ingress and egress bytes, and risk-scanning volume, separate from invoice estimates. Remote sessions also become more self-healing: expired dynamic client registrations are re-registered in place, idle credentials are re-checked on a keepalive sweep, and drifted issuer metadata is refreshed as soon as an upstream answer reveals it.

Features

• MCP catalog on the MCP page and in the command palette #6411 - The catalog lives at /mcp/catalog as a tab beside MCP Servers, Sources, and Deployments, with the same add-from-catalog flow. The old /catalog, /sources/add-from-catalog, and /mcp/add/catalog routes redirect there, and "From the catalog" on the Add MCP server page still leads to it. Typing in the command palette surfaces catalog entries in an "MCP Catalog" group kept separate from "MCP Servers". (Author: @simplesagar)
• Usage explorer backed by exact meter readings #6370 - The billing explorer reports stored-message tokens, MCP ingress and egress bytes, and risk-scanning volume from the additive usage.getMeterUsage API, which returns exact integer daily totals and bounded facet breakdowns for UTC-midnight windows up to three calendar months, ordinary usage only. Totals, daily averages, chart axes, and breakdowns use compact KTok, MTok, and BTok or binary KiB, MiB, and GiB units with full values on hover, project breakdowns show slugs where available, and contract-position and invoice estimates stay independent. Self-hosted API deployments must configure the dedicated CLICKHOUSE_READ_* connection with a SELECT-only reader before rolling this out; meter reporting never falls back to the writer connection. Existing readings are not backfilled. (Author: @disintegrator)
• Editable gateway instructions #6410 - The gateway settings tab gains an Instructions section pre-filled with the built-in drill-down guidance. Custom text replaces those defaults, saving it blank restores them, and the metaMcp update endpoint accepts the same instructions field. Connected clients pick up the new text after reconnecting. (Author: @daviddanialy)
• Expired dynamic client registrations recover on their own #6341 - Remote session clients record the expiry the identity provider reported at registration. When a provider stops recognizing a client, the platform confirms it against the token endpoint and re-registers the client in place before the next login, revoking sessions bound to the old client. Organization admins can also rotate a client on demand from its settings page. (Author: @bflad)
• Idle remote sessions re-checked on a keepalive sweep #6348 - A grant with no refresh token or refresh expiry is re-verified once its last verdict, or its connection when it has none, is older than the re-check interval, so a revoked credential reads rejected or inactive without anyone opening the consent page. The sweep is paced per issuer host, skips tunneled members whose tunnel is down, and reports under the keepalive trigger on gram.remote_session.validation. --remote-session-recheck-interval (GRAM_REMOTE_SESSION_RECHECK_INTERVAL) defaults to 24h; zero or negative disables it. A partial index on the re-check population keeps the claim query off a sequential scan (#6418). (Author: @daviddanialy)
• Identity from verified JWT access tokens #6288 - When neither the exchange nor userinfo names an identity, an RFC 9068 JWT access token signed by the issuer's published keys supplies the subject, email, and scopes. JWKS consumers now honor an explicit key_ops, keeping a key only when it names verify. (Author: @daviddanialy)
• Issuer metadata refreshed when upstream endpoints drift #6337 - A token endpoint answering 404 or 410 on refresh or code exchange, or an ID token signed under a key the issuer's published set lacks, triggers a metadata refresh outside the daily cadence, at most once per issuer every ten minutes. The same applies when a stored userinfo or introspection endpoint answers 404 or 410 without an OAuth error body (#6419). A 404 or 410 carrying an OAuth error body is the endpoint answering, not drift, and an issuer whose last refresh failed definitively waits for the hourly retry. The gram.remote_session_issuer.metadata_refresh metric carries the trigger reason. (Author: @daviddanialy)

Shadow MCP approvals now bound distribution, trusted issuer links for enterprise authorization, and a fail-open fix in realtime enforcement

A Shadow MCP approval granted for one audience can no longer be used to distribute the same direct-remote MCP server to a wider one. Every path that expands an audience, from plugin assignment and attachment to remote URL edits, backend changes, publication retries, and re-enabling, re-checks the current approval, while narrowing, removal, and disabling stay open. Organization admins can also link a user session issuer to a trusted remote session issuer through the API, giving enterprise-managed authorization an explicit trust anchor instead of a database edit. This release also fixes realtime risk enforcement failing open when an operation id was not a UUID.

Features

• Shadow MCP approvals enforced across distribution #6197 - Distribution and publication retry through Platform MCP, assignment expansion in the dashboard and Platform MCP, plugin attachment, remote URL edits, MCP backend changes, first-endpoint auto-attachment, and re-enable all require an approval that covers the whole target audience. Enforcement rolls out through legacy, report, and enforce modes with a direct-remote distribution kill switch, and an invalid or unavailable rollout state fails closed for expanding writes. (Author: @TristanSpeakEasy)
• Distribution admission reported from Platform MCP #6240 - Reading a plugin or a Shadow MCP review now includes a distribution_admission projection with the rollout mode, whether coverage is complete, and bounded counts of missing audiences, so an agent can tell whether an existing plugin is covered and what repair is needed before it acts. A reviewed Shadow MCP workflow skill keeps approval, registration, assignment, distribution, and browser authorization as separate confirmed steps. (Author: @TristanSpeakEasy)
• Link user session issuers to trusted remote session issuers #6336 - Organization admins can set trusted_remote_session_issuer_id on a user session issuer to point it at an active organization-level or global trusted issuer. Deleting, moving, or migrating an issuer fails safely while active trust links reference it, with the references listed in the preflight, and metadata refreshes persist and revalidate the trusted issuer's public JWK Set atomically. (Author: @bflad)
• Documentation, policy, and terms links on the consent card #6232 - The RFC 9728 protected-resource display metadata a remote MCP server publishes, its resource name, documentation, policy, and terms of service, is stored on the issuer a direct-remote Platform MCP attachment creates, re-probed when the server is updated, exposed on remoteMcp.discoverProtectedResourceMetadata, and linked from the consent card. (Author: @daviddanialy)
• Private network access for hosted MCP servers #6236 - An admin-only Network Access page configures Tailscale private ingress and chooses how each hosted MCP server is exposed. Behind the gram-network-ingress-rollout flag and dormant until the supporting infrastructure rolls out, so the custom-domain page is unchanged for everyone else. (Author: @TristanSpeakEasy)

Bug fixes

• Realtime risk enforcement no longer fails open on opaque operation ids #6384 - Enforcement dispatched over pub/sub accepts operation ids that are not UUIDs instead of letting the operation through unchecked. (Author: @vishalg0wda)
• Directory syncs defer to the running replacement #6398 - An identity map sync that loses the single-writer lock now steps aside for the sync that holds it instead of failing and retrying. (Author: @vishalg0wda)

Know whether a remote session's stored credential still works before anyone dispatches a tool call

A remote session's card now carries a verdict on the credential it holds. The platform verifies a grant automatically the moment it is connected or reconnected, and a Verify action on the consent page re-checks it on demand by presenting the stored credential to the upstream MCP server in a dry run of dispatch: connect and list tools, nothing else. The result, valid, rejected by the member, or unknown, is recorded on the session and shown on the card. Sessions are also enriched from the issuer's userinfo and introspection endpoints, so a login that returned no ID token still shows who it belongs to, and a token the provider reports as dead marks the grant inactive.

Features

• Automatic verification on connect #6295 - Connecting or reconnecting a grant kicks off a verification immediately. The card reads "Verifying" until the verdict lands, and in-flight verifications are drained cleanly on shutdown. (Author: @daviddanialy)
• Verify from the consent page #6175 - The consent card gains a Verify action that presents the stored credential to the member the runtime would dispatch to, routed the same way real traffic is, and records whether the member accepted it. (Author: @daviddanialy)
• Identity from userinfo and liveness from introspection #6231 - When the token exchange returns no ID token, the issuer's userinfo endpoint supplies the identity shown on the card. Verify also consults the introspection endpoint and marks a grant inactive when the provider says its token is dead. (Author: @daviddanialy)
• Issuer metadata refreshed as sessions use it #6220 - Stale or never-fetched issuer metadata is re-fetched off the request path whenever a session flow touches the issuer, and stored capability documents are re-projected onto their typed fields. These refreshes are audited under a new system: principal type that audit feeds display and that can never hold grants. (Author: @daviddanialy)

Risk policies scope only through detection scopes, and MCP requests no longer trigger toolset indexing

Risk policy writes drop three legacy policy-level scope fields in favor of detection scopes. That is a breaking change for API callers and Platform MCP tools, described below. Dynamic MCP toolsets are now indexed by a scheduled background sweep, so an MCP request never has to kick off indexing work, and the AI scan target config directory check accepts any path the device agent can resolve. Setup gains temporary Session Auditor access for confirming inference hook traffic, and the linear wizard returns alongside the board.

Breaking changes

• Risk policies no longer accept policy-level scope fields #6260 - The risk policy create and update endpoints reject message_types, scope_include, and scope_exempt. New policies leave those legacy columns empty and updates carry stored values forward unchanged, so scope every policy through detection_scopes instead. The fields stay readable until the legacy scope migration folds them, and the secrets guide in the dashboard now scopes its default policy through a detection scope. The same change applies to the Platform MCP risk policy tools, where a stored policy still narrowed by legacy message_types is reported as raw_scope (#6257). (Author: @vishalg0wda)

Features

• Session Auditor access granted and taken back during setup #6304 - The Enable logging step explains that an admin sees only their own agent sessions by default, offers to create a Session Auditor role carrying chat:read and add the admin to it so the Confirm traffic step can see the conversation an Anthropic inference hook delivers, then offers to remove them again once traffic is confirmed. Directory-synced organizations create the role and map it from a directory group instead. (Author: @qstearns)
• The linear setup wizard is back #6296 - /setup/wizard walks the board's cards in order again, and a header button swaps between the board and the wizard. (Author: @simplesagar)
• Set up LiteLLM card on the setup board #6297 - The card creates a LiteLLM instance in place, shows its proxy environment, guardrail fragment, and verification requests exactly as the AI Integrations page does, and confirms traffic from the instance's connection diagnostics. LiteLLM guardrail events no longer count toward the other-platforms card. Hidden by default: a platform admin has to reveal it on the board. (Author: @simplesagar)

Bug fixes

• MCP requests no longer trigger toolset indexing #6324 - Dynamic MCP toolsets are indexed by a scheduled background sweep, so an MCP request never has to initiate indexing work. The sweep's discovery query was also sped up so it no longer times out on projects with many HTTP tools (#6342). (Author: @bflad)
• Any resolvable AI scan target directory is accepted #6289 - Scan target config directories are no longer checked for a particular shape. Any path the device agent can resolve works, including one written with a trailing slash such as ~/Library/Application Support/com.openai.chat/. (Author: @subomi)
• Killswitch picker shows project names #6254 - Choosing MCP servers for a killswitch lists project names instead of project IDs. (Author: @speakeasyforgebot)
• Trial conversions land on pay-as-you-go #6335 - An organization converting through Stripe Checkout at the end of a trial now switches to the pay-as-you-go plan instead of staying on enterprise. (Author: @alx-xo)
• Wizard rail rows settle quietly #6313 - Setup wizard rail rows are no longer focusable or announced as buttons while a card's completion is settling. (Author: @simplesagar)

Edit an MCP server's access one scope at a time, and manage user session issuers for the whole organization

The Access tab on an MCP server is now a single list with a row per principal, and each row shows separately whether that person, role, or everyone can connect to, view, and manage the server. Each of the three can be changed on its own, so a role that reaches a server through an organization-wide rule can be narrowed for that one server without touching the role anywhere else, and taking connect away no longer strips view and manage with it. Organization admins also gain an API for user session issuers that every project inherits, with deletion guarded while a live MCP server or toolset still depends on the issuer, and agents working through Platform MCP can read a bounded summary of Shadow MCP policy decisions.

Features

• Per-scope access editing on an MCP server #6246 - The People and Roles tabs and the single "can connect, view, or manage" choice are replaced by one list where each principal has its own line for connect, view, and manage. Blocked scopes are now independent of one another, so "cannot connect but still administers" is expressible for the first time, and a role reaching a server through an organization-wide rule can be narrowed or closed for that server alone. (Author: @adaam2)
• Organization-level user session issuers #6200 - Organization admins can create, update, and delete user session issuers and their CIMD clients at the organization level, inherited by every project, through the management API. Deletion runs a preflight and is blocked while a live MCP server or toolset still references the issuer, and project-level mutations are restricted to issuers the project owns. (Author: @bflad)
• Shadow MCP policy decisions summarized from Platform MCP #6235 - Agents working through Platform MCP can read a bounded summary of Shadow MCP policy decisions without the summary exposing principal identities. (Author: @TristanSpeakEasy)
• Anthropic inference hooks from the setup board #6239 - A new setup card turns on Anthropic inference hooks in one pass: it mints the endpoint Claude posts each conversation to, walks through pasting it into the Claude.ai inference hook settings, switching on enforcement and starting the rollout in Shadow mode, and saves the signing secret Claude reveals. Traffic is confirmed from the conversations the hook delivers. The webhook URL and signing secret controls are shared with the integrations sheet, and the previous Anthropic card lives on as "Set up Anthropic admin controls", hidden by default. (Author: @qstearns)
• Setup board reorganized around outcomes #6202 - "Connect identity provider" and "Directory sync" merge into one "Set up identity provider" card, publishing the plugin marketplace becomes a section at the front of the cards that need it, and coding assistants split into an Anthropic card for Claude Code and Claude Cowork and an "other platforms" card for everything the device agent covers. Each platform's instructions sit inline in its own step, and confirming traffic is the last section of both cards. The linear wizard at /setup/wizard was removed in this release and returns in 1.23.0. (Author: @qstearns)

Bug fixes

• Beta badges removed from Risk Events and Shadow MCP #6234 - The page headers now match the sidebar entries, which dropped their Beta label earlier. (Author: @simplesagar)

Decide who can use each MCP server from its own Access page, and manage killswitches beside the person they restrict

Access control now starts from the thing you are protecting. Every MCP server has an Access page that answers "who can use this server": grant people or roles, set what each one can do, and narrow a rule to particular tools or to tools carrying an annotation. The organization-wide role editor is rebuilt on the same model. Killswitches move onto the Access tab of the person they restrict, so listing, creating, lifting, and the full version history all happen on that person's page. API keys can be bound to a single project at creation, and RBAC-filtered tool inventories are now marked private so a shared cache can never serve one person's tool list to another.

Features

• Per-server Access page and rebuilt role editor #6156 - The read-only Team Access tab on each MCP server becomes an Access page where you grant a person or a role access to that server alone. Each rule reads as a sentence, and narrowing to specific tools or to an annotation such as read-only is a dropdown away. Direct rules are editable in place, inherited organization rules link back to the role that owns them, and a "People this reaches" panel resolves every rule to the members it covers. Role authoring moves onto its own page where permissions are picked from one searchable menu and narrowed on their own row. A guardrail refuses to write a block that would lock the caller out. (Author: @adaam2)
• Killswitches managed from the identity's Access tab #6210 - The separate organization-wide Killswitch screen is retired. Team, connection, and session entry points now open the restricted person's Access tab, where you list, create, edit, and lift killswitches and read their version history. The mark beside a person's name is an icon whose hover text says what the state stops. Old Killswitch addresses redirect, with a single record opening on its subject's Access tab so audit-log links still land on the exact record, in the project and time period the link was read from. (Author: @danielkov)
• API keys bound to one project #6116 - The API key form gains an optional project selector. Omitting it still creates an organization-wide key, and a bound key's project shows separately from its permission scopes in the result and the key list, so a restriction is never confused with a scope. A follow-up restores hosted MCP project context for organization-wide keys executing platform tools while rejecting conflicting bindings (#6115). (Author: @danielkov)
• Filtered tool inventories are never cached across people #5955 - Remote MCP proxy tools/list results that pass through the per-tool RBAC filter are labelled cacheScope: "private" with ttlMs: 0. The MCP 2026-07-28 revision reads an absent scope as public, which would have let a shared cache serve one principal's tool inventory to another, or let a client keep an inventory after the grants that shaped it were revoked. The label applies whether or not anything was filtered, so it never reveals that a caller was. (Author: @bflad)

Agents become first-class identities with their own credentials, policies, and owners

An AI agent no longer has to borrow a person's API key. The platform can now hold an agent as a principal in its own right: a human owner creates it, grants it an allow-only runtime policy narrower than their own, issues it API keys with a required expiry, and can suspend, rotate, transfer, or revoke it. Every request an agent makes is admitted against three live policies at once, the immutable grant it was delegated, its own direct policy, and its current owner's policy, so an agent can never do more than the person accountable for it. If that owner leaves the organization, the agent is blocked until an admin explicitly reassigns it. Agent credential issuance is rolling out per organization behind the gram-agent-credentials-m2 flag.

Features

• Create and manage agent principals #6047 - Human-only APIs and a setup page for creating, renaming, suspending, resuming, revoking, and deleting first-class agents. Owners manage identity and lifecycle without extra grants, other people are checked against exact agent:* permissions, and every transition writes its before-and-after audit event in the same transaction. (Author: @danielkov)
• Agent API keys with delegated grants and bounded expiry #6071 - Issue, list, rotate, and revoke API keys for an agent through the existing keys API. Each key carries an immutable delegated policy, the identity of the human who authorized it, a required expiry, and a one-time secret. Issuance, listing, and rotation are behind the per-organization gram-agent-credentials-m2 flag; revocation always works. (Author: @danielkov)
• Every agent request is admitted against live policy #6068 - Agent credentials are checked on every call against the delegated grant, the agent's direct policy, and the current owner's policy together, and malformed, expired, inactive-parent, or owner-ineligible requests are rejected. Telemetry and audit records name the agent as the actor while keeping its authorizer and owner as separate provenance. (Author: @danielkov)
• MCP sessions for agent subjects #6072 - Agents can hold MCP sessions using the same challenge, token, refresh, and revocation machinery people use. The live parent and delegated policy are re-checked on every access and refresh, and a replayed refresh is denied once its successor session has been revoked. (Author: @danielkov)
• Direct agent policies, allow-only by design #6051 - Owners and people holding agent:write can create, update, and delete an agent's direct runtime policy. Only allow rules from the agent-safe scope registry are accepted, so this surface cannot write a deny rule, a reusable role, or another principal's grants. (Author: @danielkov)
• Owner loss blocks the agent until it is reassigned #6053 - When an owner is deleted, deactivated, or removed from the organization, the agent latches into a blocked state that survives the owner regaining eligibility. Explicit transfer by the current owner, or reassignment by an admin, is the only way out, and both preserve the agent's identity and direct policy. (Author: @danielkov)
• Agent management capabilities in custom roles #6041 - Four new capabilities, agent:read, agent:write, agent:authorize, and agent:transfer, are added to new organization-admin roles and exposed in the custom role editor under an Agents group, kept separate from the runtime scopes an agent itself may hold. (Author: @danielkov)

Bug fixes

• Typed agent policy selectors #6077 - Create and update request bodies preserve typed policy selectors, and the dashboard API client contracts are regenerated to match. (Author: @danielkov)

Choose which AI tools your device agents scan for, export risk findings over OTLP, and a sharper prompt injection judge

The Shadow AI scan list is yours to edit. From the Device Agent configuration tab, organization admins add their own targets, switch a built-in default off and back on, and edit or delete what they added, with no agent release needed for a change to reach devices. Risk findings join the data export sources, delivering new findings to your SIEM or observability stack as privacy-safe OTLP log events. Prompt injection detection is rebuilt around a typed judge, and every prompt-based risk policy now runs on one benchmarked model that catches more and misfires less at lower latency.

Features

• Manage Shadow AI scan targets per organization #6171 - The list of AI tools device agents probe for is served per organization: the built-in defaults overlaid with the targets you add or customize through the new agent.listAiScanTargets, agent.upsertAiScanTarget, and agent.deleteAiScanTarget endpoints. Every change lands in the audit log, and the served list version is echoed on scan receipts. The Device Agent Configuration tab gains a section where targets are entered as tags (#6173). (Author: @subomi)
• Risk findings as an OTLP data export #6018 - Add Risk Findings as a project-scoped source in Data exports and new, non-excluded findings are relayed to your configured OTLP log destinations. The log carries a stable finding ID plus policy, rule, source, and confidence for filtering and deduplication, never the matched content. Exclusions are re-evaluated immediately before each delivery and fail closed. (Author: @tgmendes)
• One benchmarked judge model for prompt-based risk policies #6024 - The per-policy model picker is gone and every prompt-based policy runs on Gemini 3.5 Flash Lite. On the risk judge benchmark the new model improves accuracy, precision, latency, and token usage over the previous default while keeping perfect recall. Policies keep their temperature and fail-open settings. (Author: @vishalg0wda)
• Typed prompt injection detection #4479 - The prompt injection judge now makes one call per event with bounded session context and returns a typed finding: the kind of directive, its target, whether it is operational, and a privacy-safe rationale. Your risk policies decide block versus surface exactly as before. (Author: @vishalg0wda)
• Turn off the observability plugin per project #6161 - Org admins can disable a project's observability plugin from the Observability card on the Plugins page. A disabled plugin is omitted from the published marketplace, is not installed by the device agent, and rejects direct downloads, and a connected marketplace is republished automatically. Marketplace settings changes are recorded in the audit log. The backing column shipped separately as a schema-only migration (#6170). (Author: @speakeasyforgebot)
• Gateway calls classified as the gateway, not shadow MCP #6180 - A hook-observed call whose server URL is a gateway endpoint now shows as that gateway in Tool Logs and insights instead of falling through to shadow MCP. Gateway activity hides members no longer on the gateway, and the activity charts link to the tool logs and insights pages filtered to that gateway. (Author: @daviddanialy)
• Clearer Watchdog exposure bar #6129 - Hovering a category dims the other slices so one reads at a time, and Custom Rules gets its own color so no category looks inactive. (Author: @adaam2)

Bug fixes

• Policy scopes saved as the scanner reads them #6092 - Policy setup saves message type selections as category detection scopes, so the "Applies to" value in Policy Center matches the scanner's effective scope and the scopes a policy's other categories relied on are preserved. (Author: @vishalg0wda)
• Imported chats with NUL bytes no longer fail the sync #6103 - AI provider chat messages and titles containing NUL bytes are stored with the byte dropped instead of failing the compliance sync for that window. (Author: @subomi)

Point an MCP server at your identity provider's issuer and see who each connection belongs to

External OAuth configuration now works the way identity providers publish it. Choose provider-hosted or platform-hosted OAuth metadata, review the live discovery result before saving, and switch an existing configuration safely. Discovery probes every well-known location and merges the OpenID Connect and RFC 8414 documents, so fields a provider publishes in only one of them are captured. Remote logins request the scopes a provider actually advertises, retry once without a resource indicator when an issuer rejects it, and validate the RFC 9207 iss parameter. When an issuer returns an ID token, the platform verifies it and shows the connection as "Connected as" that person. The Authentication settings for an MCP server are reorganized into three rows with one table for allowed clients.

Features

• Issuer-backed external OAuth configuration #6049 - Choose whether an MCP server advertises provider-hosted or platform-hosted OAuth metadata, and switch an existing configuration after reviewing live discovery results. The server side ships in two halves so the change rolls out without a flag: every server first learns to read and advertise issuer-only records (#6045), then the create, update, and clear operations land with an SSRF-safe discovery step that requires an exact issuer match (#6085). (Author: @walker-tx)
• Discovery merges every well-known document #6094 - Issuer discovery probes every well-known candidate and merges same-issuer OpenID Connect and RFC 8414 documents, capturing jwks_uri, claims_supported, and ID token signing algorithms wherever the provider publishes them. Discovery and refresh also record the userinfo and introspection endpoints, back-channel logout, and RFC 9207 support, and the create forms accept the same fields. (Author: @daviddanialy)
• Spec-aligned scopes, resource indicator retry, and iss validation #6109 - Remote logins request openid, email, profile, and offline_access whenever the issuer advertises them, and operators can pin a verbatim scope request per issuer with scope_override. A login or refresh answered with invalid_target is retried once without the RFC 8707 resource parameter, and resource_indicator_supported can be set to false on an issuer that never accepts it. Issuers advertising RFC 9207 have iss validated on the callback, and the consent page offers a reconnect when a live grant lacks openid. (Author: @daviddanialy)
• "Connected as" from the issuer's ID token #6104 - When code exchange or refresh returns an ID token, it is verified against the issuer's published keys and reduced to its claims, and the consent card shows who the upstream grant belongs to. Non-standard token response members are kept alongside, minus anything credential-shaped; the raw token is never stored. (Author: @daviddanialy)
• Reorganized MCP Authentication settings #6132 - Session length, client access, and connected services each get their own row with a one-line hint, terminology moves behind "What is this?" modals, and the verified client catalog and your own allowed client URLs become one table behind a "Manage allowed clients" link. Dashboard only, no API change. (Author: @adaam2)

Bug fixes

• Dead refresh grants reported on a 2xx are cleared #6088 - OAuth error bodies on successful upstream token responses are read, so a dead refresh grant reported that way, such as GitHub's bad_refresh_token, clears the stored token instead of being retried forever. (Author: @daviddanialy)

Review shadow MCP, assign access roles, and read the event feed from Platform MCP

Admin work that used to require the dashboard can now be done from the Platform MCP server inside your coding agent. Ask for the last events in your organization's Event Feed, list unsanctioned MCP usage in a project and approve or deny a reviewed target, create or update custom MCP access roles and assign them to members, and drill into masked tool and skill usage by user. Every read is privacy-safe: raw URLs, hosts, person-level details, and evidence documents never reach the model, and every mutation is confirmed, idempotent, and budgeted so an agent retry cannot double-apply a decision.

Features

• Event Feed from Platform MCP #6136 - The new list_organization_events tool returns the most recent Event Feed entries for an organization admin, newest first, over the last day by default and up to seven. Results are summaries with a dashboard link to the full feed; attributes, trace IDs, and user identities are never returned. (Author: @simplesagar)
• Inspect and decide shadow MCP access #6117 - The list_shadow_mcp_inventory and get_shadow_mcp_review tools show unsanctioned MCP usage in a project with its review and enforcement state using generic target labels and exact event counts. The decide_shadow_mcp_access tool then approves or denies a reviewed target with a bounded rationale and an idempotency key, reusing the dashboard's own approval transaction (#6118). Available for projects on the MCP approval rollout. (Author: @TristanSpeakEasy)
• Manage and assign MCP access roles #6113 - Confirmed, idempotent tools create and update custom MCP access roles, and a follow-up assigns them to members without replacing the roles those members already hold (#6127). Privacy-safe reads of role, member, and configured MCP access back both (#6075). (Author: @TristanSpeakEasy)
• Usage attribution by user #6181 - Drill-downs for masked MCP tool and skill usage by user, with tool and error attribution scoped to the selected server at call level. (Author: @TristanSpeakEasy)
• Plugin assignment reads #6062 - Privacy-safe reads for plugin assignments and assignment versions, so an agent can check what is assigned before proposing a change. Optional subject counts may be integers, suppression labels, or null (#6153). (Author: @TristanSpeakEasy)
• Clearer inventory and setup failures #6054 - The MCP inventory names each server's backend kind and the management operations it supports, and setup failures are classified into privacy-safe categories with actionable next steps (#6056). (Author: @TristanSpeakEasy)
• Platform MCP setup lives in headless mode #6144 - The separate Platform MCP settings page is gone; setup happens from headless mode, and old /platform-mcp links redirect there with their entry source preserved. (Author: @adaam2)

Bug fixes

• Catalogue servers alongside legacy servers #6182 - Reviewed catalogue MCP servers can be registered in projects that also contain legacy toolset-backed servers. (Author: @TristanSpeakEasy)

One flow for adding MCP servers, whatever kind they are

The MCP page is now the inventory and the only place a server is added. One "Add new" button offers the catalog, a remotely hosted server, a tunneled one, and an Advanced group for OpenAPI documents, functions, and building a server from a source the project already has. Servers are named for how they are reached rather than the backend behind them, remote servers verify connectivity before they can be saved, and breadcrumbs lead back up from every step. Sources move under MCP instead of going away, with a page per source showing its file, the tools it produced, and the deployments it is versioned by. Old source and catalog links redirect. Further down, project admins can rename a project, Legacy Pro organizations receive the enterprise feature bundle, organization setup gets its logging step back, and a run of fixes covers logout, sign-up, and plugin rollout.

Features

• One flow for adding MCP servers #6012 - The MCP page becomes the inventory and the only place a server is added. Remote servers must verify connectivity before they can be saved, sources live at /mcp/sources with a page per source, deploying a function offers the flow that builds a server from it, and old /sources and /catalog URLs redirect. A follow-up restores the grid and table toggle on the servers and sources lists and the plugin skills section, adds a search box to Environments, and brings back the source page's MCP servers list, document viewer, and function runtime details (#6142). (Author: @adaam2)
• Legacy Pro organizations get enterprise feature access #5912 - An operator-run, dry-run-by-default backfill grants Legacy Pro organizations the enterprise-access entitlement bundle while preserving any entitlement an admin explicitly disabled. Billing and resource limits are unchanged. (Author: @simplesagar)
• Rename a project from Settings #5880 - Project settings show the display name and slug, and project admins can update the display name. The new projects.update endpoint validates and audits the change, and the dashboard refreshes its project cache so the new name appears everywhere. (Author: @alx-xo)
• Unsupported MCP protocol versions rejected before auth #6201 - Hosted, platform, and gateway MCP surfaces answer an unsupported protocol version with error code -32022 and the requested and supported versions, so a client can retry with a compatible one instead of being served under legacy semantics. Proxied backends still relay to their upstream. (Author: @bflad)
• Gateway install page and clearer tool-call keys #6157 - MCP gateway endpoints serve an installation page instead of a not-found page. The execute_tool description, gateway instructions, and missing-name error now name the name and arguments keys so clients stop guessing a tool key (#6087). (Author: @daviddanialy)
• Organization setup gets its logging step back #6219 - Both the wizard and the board regain an "Enable logging" step with a single switch that turns on Enable Logs, Record Tool I/O, and Agent Session Capture together. The board marks the task done once all three are on, the wizard resumes past it, and the "enterprise rollout" card on the organization home opens the wizard it describes. New organizations still start with the bundle enabled. (Author: @simplesagar)
• Setup wizard and board, side by side #6098 - The Wizard/Board switcher returns, so the linear wizard at /setup/wizard is available alongside the board. Setup task assignees are notified by email, assigned owners can verify onboarding traffic, and the header and footer are expanded with support escalation and a responsive layout (#6063). The Cowork manual setup callout is restored in the same change. (Author: @simplesagar)
• Setup reminder moves to the sidebar #6148 - The full-width setup banner on every organization page is replaced by a persistent "Finish organization setup" entry in the sidebar footer, and the organization home headline fits on one line. (Author: @adaam2)

Bug fixes

• Logout returns you to the login page #6042 - Logging out from the account menu now redirects to login. The page still navigates if the logout call rejects or stalls. (Author: @alx-xo)
• Signing up again after a WorkOS deletion #6046 - Signing up with an email that was deleted in WorkOS reactivates the user, restores RBAC access, and keeps sign-up off the book-a-demo gate. (Author: @alx-xo)
• Legacy register flow removed #5921 - The session-aware /register compatibility flow is gone; stale links redirect to /sign-up. (Author: @alx-xo)
• Identity pages keep their place in the sidebar #6199 - The Observability group stays open on identity pages, a breadcrumb leads back to the roster, and roster cells are evened out. (Author: @adaam2)
• Plugin rollout keys auth can find #6149 - The plugin rollout sweep no longer mints API keys under the system placeholder creator, and existing orphaned keys are rewritten onto a real organization member. (Author: @speakeasyforgebot)
• Audit log attributes background work and spend-cap changes correctly #6140 - Scheduled jobs are recorded as the system acting surface instead of unknown, so an unknown surface once again means an unattributed request. Spend-cap changes carry the surface they came through into the workflow, so your own change is no longer recorded as an unattributed write (#6141). (Author: @simplesagar)