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)
