Sessions and connected clients

Use session records to answer an access question

Start with the person and client you are investigating. Session and connected-client records help establish which identity reached Durin and the recorded authentication state. They are useful when an employee changes clients, reports repeated sign-in prompts, or needs to stop a client’s access.

A visible client record is not proof that every action from that computer passes through Durin. The inventory describes the managed connection observed by Durin. Review the client’s configured endpoints separately if you need to establish broader coverage.

What is a session?

A session represents an authenticated connection between a person or client and Durin. Sessions are created when an MCP client connects to Durin and authenticates. Each session is bound to a specific user and client instance.

View sessions

The Sessions page shows all active and recent MCP client sessions. Personal workspace shows your own sessions. Admin workspace shows sessions for all organization members.

Client inventory

The connected clients view scopes visibility to the signed-in owner or current administrator. It shows which MCP clients are connected, their authentication state, and which connections they are using.

Read state alongside recent activity

Authentication state, last observed activity, and successful upstream execution are different facts. A client can authenticate while a particular tool remains unavailable because of membership, team scope, provider consent, or review status.

1. Open Sessions in the appropriate personal or Admin workspace.
2. Identify the owner and client you intend to inspect.
3. Compare the displayed authentication state and recent activity with the time of the reported problem.
4. Open the relevant activity record to see the tool decision and outcome. Do not infer a successful provider request from the presence of the client alone.

Revoke a client authorization

Use the session’s revoke control when you want that client authorization to stop being used. Personal controls are scoped to the signed-in owner; administrators can manage organization sessions. Current authorization checks enforce revocation on subsequent requests.

Revoking a client is distinct from disabling a provider connection, revoking organization membership, or withdrawing provider consent. Choose the narrowest control that matches the incident or access change. Keep the activity record and the time of revocation so you can distinguish earlier requests from later attempts.

Reconnect after the underlying issue is resolved

A reconnect action does not waive other access requirements. The client may still need authentication, and the member, connection, reviewed tool, and provider authorization must remain valid.

If an administrator revoked a session, the owner cannot simply override that administrative decision with a personal reconnect. Ask the administrator to review it. After an authorized reconnect, run a reviewed read and inspect the new activity rather than assuming an old session label establishes current access.