Skip to content
Kutrion
Browse docs

browser-extension

Settings and security dashboard

Extension settings stay in the browser profile; manage enrolled devices, review recent audit activity, and configure inactivity auto-lock (15 minutes by default) — without changing server state beyond the existing device and audit endpoints.

Updated Oct 6, 2026

The extension popup includes a settings and security dashboard for the browser device itself. It lets you configure local behavior, see which devices are enrolled on your account, and review recent activity — all without standing up anything new on the server.

Where settings live

Extension preferences stay in the browser profile, on this device only. Most of them (site-access choices, autofill behavior, theme and similar) are ordinary extension storage. Three things are kept apart from those, in a store that belongs to the extension itself and that the web pages you visit cannot reach:

  • the auto-lock interval, so a page cannot quietly switch auto-lock off,
  • the last-activity time auto-lock counts from, so a page cannot keep postponing the lock, and
  • the device-session refresh token, which is what keeps this browser signed in across restarts.

None of this is vault data.

If the browser gives the extension no such store (for example, a Firefox profile with history disabled), the refresh token is held in memory only. You stay signed in while the browser is running, but expect to sign in again after the browser restarts or after it stops and restarts the extension in the background, which browsers do on their own. In that case the auto-lock interval and the last-activity time stay in ordinary extension storage.

Managing enrolled devices

The dashboard lists the devices enrolled on your account and lets you act on them:

  • Review enrolled devices. Each browser or client that has registered shows up as its own device.
  • Revoke a device. Removing a device invalidates its session, so a lost or retired browser can no longer refresh its way back into the vault.

These actions use the existing device endpoints — the dashboard is a view over them, not a new control plane. See Install and unlock for how a device gets enrolled in the first place.

Reviewing recent activity

The dashboard surfaces recent audit activity so you can see what has happened on the account from inside the extension. This reads the same tamper-evident trail described in Audit logs; the extension does not keep its own separate log. If something looks wrong, this is where you would notice an unexpected access or device.

Auto-lock

Auto-lock counts inactivity in Kutrion, not system idle time. You set a timeout; the extension records the last moment you used it and locks once that timeout has elapsed, dropping its in-memory token so the next use requires the unlock again.

  • The timeout is 15 minutes unless you change it. The choices are 1, 5, 15 or 30 minutes, 1 hour, or Never.

  • Never turns auto-lock off: the extension stays unlocked until you lock it yourself or sign out. You have to pick it; an install where nothing was chosen, or where the stored choice cannot be read, gets the 15-minute default.

  • Only what you do with Kutrion itself counts as activity: the toolbar popup, the sign-in page, the inline login list, and the fill shortcut or context-menu command. Requests a web page’s script can trigger on its own, such as a passkey prompt or the inline button opening the list, do not hold the vault open.

  • It does not use the browser’s idle API, and the extension does not request the idle permission. Safari has no idle API at all, so a setting built on one would have rendered, accepted a value and locked nothing on that browser.

  • Two things enforce the deadline, and both are needed: an alarm scheduled for it, so the vault locks while a suspended extension is unattended, and a check in front of every request the extension handles, so nothing is answered past the deadline even if the alarm never arrives.

  • The deadline is derived from the last-activity time rather than stored, so shortening the timeout applies to inactivity that has already elapsed, not just the next window. The last-activity time survives a browser restart on purpose — closing the browser for a week must not silently restore an unlocked vault.

  • Locking clears the cached session in memory; it does not delete the enrolled device or the refresh token, so unlocking again is just the unlock prompt rather than a fresh enrollment.

Nothing here changes server state

The settings and security dashboard is intentionally read-and-local: it keeps preferences in the browser profile and otherwise only calls the existing device and audit endpoints. There is no extension-specific server state — managing devices and reviewing activity go through the same APIs the rest of Kutrion uses.

Where to go next