Skip to main content
The Sessions page (Sessions List, tabs Records and Charts) shows sign-ins to your Digital Twin: one row per person, browser and Digital Twin, for the selected date range. It is the record of “who signed in, from where, when” — for audits, security reviews and incident response. Admin Sessions Interface

​
Overview

A session record is created when a person signs in to a Digital Twin from a browser or device; its Last Active moves forward each time a conversation turn is saved from it (at most once a minute). One person typically has several: laptop, phone, tablet, second browser.The list is sorted by Last Active (most recent first) and defaults to the last 30 days.

​
Reading Last Active

Last Active is the last time a conversation turn was saved from that browser — signing in, opening pages or uploading files do not move it. A session active minutes ago is someone talking to the Digital Twin now; one idle for more than 30 days is removed automatically.

​
Data tracked per session

The list shows Instance, User, Ago, Alive, IP, Browser, Engine and OS (with versions); Columns adds First, Last, AI Name, Created and Last Keep-Alive. The record holds:The filter bar narrows the list:
  • Account — span all Digital Twins in an account
  • Instance — sessions for one Digital Twin
  • User search — by email, first name, or last name
  • Date range — by Last Active; up to roughly the last month (older sessions are removed automatically — see retention below)
Filters persist as you scroll so you can sweep a large window without losing context.

​
Reading a session row

Each row shows the Digital Twin, the user, how long ago the session was active (Ago), the date and time of that last activity (Alive), the IP address, and the browser/engine/OS breakdown. Click the pencil (needs sessions.edit) to open the read-only Session Details panel:
  • User and Digital Twin cards (who, and which Digital Twin the session is attached to — a person with access to several Digital Twins has separate sessions per Digital Twin)
  • Session ID, source IP, created and last-updated timestamps, and current status
  • Device details when the browser reports them: type, vendor, model, and CPU architecture
  • The full raw user-agent string (useful when the device columns abbreviate)

​
Deleting a session record

The trash icon (Delete Session) marks a record deleted; tick several rows to delete them together. The row can still show in the list, marked in its details, until the 30-day cleanup. It does not sign anyone out — the list is a record of sign-ins, not a control over them. To end someone’s access now:
  • Set a new password for them under Users → Security. That signs them out everywhere and signs out their trusted browsers (see MFA).
  • Make them inactive (Users → Status) to block them at once while keeping their account.
  • Lowering someone’s account type signs them out automatically; they sign back in with their new rights.
Export the filtered list to CSV before you delete a row you may need for an incident file.

​
Detecting suspicious activity

Things to scan for during a security review:
  • Two far-apart networks for the same user in the same hour. Pria shows the IP address, not a place — look it up if you need one. A session from one network and another from a very different one minutes later is almost certainly account sharing or a stolen credential.
  • Unfamiliar user-agent. A non-browser UA string on an account that has only ever used standard browsers warrants attention.
  • Long gap between Created and first Last Active update. Suggests the credential was captured and used later from a different environment.
  • Burst of new sessions for one user across many IPs. Classic credential-stuffing signature.
These are manual review patterns for the Sessions list itself. Note that Praxis Shield automatically monitors conversation activity for abuse — including unusual automation volume and coordinated activity across accounts — and raises incidents for review; pair a suspicious session with the user’s Shield incidents and Histories before acting.

​
Coordinating with the user

When you spot a suspicious session, the standard playbook is:
  1. Set a new password for the person under Users → Security (or make them inactive) — that ends the suspicious access at once.
  2. Email the user at the address on the session row, asking them to confirm whether it was them. Use the email field in the detail panel.
  3. Have them choose their own password through Forgot password on the sign-in page. If the account uses API Keys, rotate them too.
  4. Require MFA going forward if the user did not already have it enabled.
  5. Review their Histories for the same window — sometimes the suspicious session shows in conversation patterns even when the IP looked routine.
Document the action in your incident log.

​
Session retention

Sessions are a rolling window, not a permanent archive: records idle for more than 30 days are removed automatically (the page says “Sessions older than 30 days are automatically removed.” next to the date-range filter). A session stays in the window as long as conversation turns keep coming from it.If your compliance process needs session evidence beyond 30 days, make the CSV export part of your routine — for example, a monthly export filed with your audit records. For your deployment’s broader data-retention commitments, see Privacy & Educational Consent.Sessions interact with two other security surfaces:
  • MFA — if a suspicious session prompts a credential reset, check whether the user has two-step verification enabled, and require it going forward. A user’s MFA state and trusted devices are managed from Users → Edit → Security.
  • Personal API Keys — programmatic access via API key exchange creates short-lived tokens; those calls do not show in the Sessions list. Admins concerned about a specific user’s key activity should ask the user to rotate their key from Settings → Developer.

​
Export

CSV downloads the loaded rows with the columns you have visible. Export all (the caret next to it) prepares the whole filtered list on the server and emails you a download link, with fixed columns (names, email, Digital Twin, IP, browser, engine, OS, created, last updated). Neither includes the raw user-agent string or the device details — those are in the details panel.
Session tracking supports FERPA compliance by maintaining a verifiable record of who accessed educational data, when, and from where.

​
Required permissions

You also need the Admin account type. See Entitlements for how to grant these.
  • Users — manage the user accounts behind each session
  • MFA — multi-factor authentication requirements
  • Personal API Keys — programmatic access for Admin users
  • Entitlements — sessions.* permissions
  • Histories — what each session was used to do
  • Praxis Shield — automatic threat and abuse monitoring of conversations
  • Configuration — Digital Twin security settings