Account security
Everything that protects the people on your account rather than the keys: two-factor enrolment, which sessions are open, recent sign-in activity, the password, and where security alerts are sent. All of it is on one dashboard page: Security.
Restricting account API calls to known networks is on its own page: IP allowlist.
Everything below acts on the signed-in person, not on a key, and there is no API call for any
of it, under any credential: a rail_* key cannot read or change any of this about the people on
your account. Key management is on the API key surface instead.
Two-factor authentication
Two-factor is a standard TOTP authenticator (any app that reads an otpauth:// URI). It does two
jobs: it is a second factor at sign-in, and it is the step-up that destructive dashboard
actions demand: creating and revoking API keys, changing webhook configuration, changing the
team, and changing the IP allowlist. Without it enrolled, those actions
cannot be performed at all: the dashboard tells you to enrol first, not to try again.
From Security → Two-factor authentication you can see whether it is set up and switched on, enrol a new authenticator (scan the QR code or enter the secret, then confirm with a code), and switch it off (which needs a current code from the authenticator you are switching off).
An invalid code is refused.
Each code is accepted once. A code that has already been accepted, at sign-in, for a step-up or while enrolling, is refused: wait for your authenticator to show the next one. A reused code does not count as a wrong one. Five wrong codes within five minutes lock the second factor for five minutes. Until then every check of a code for that account, including sign-in and step-up, is refused, even the right code. A lock does not sign you out of a session you already have; actions that need a code wait until it lifts.
Re-enrolling is disable → setup → enable, in that order. Starting setup on an account that already has two-factor enabled is refused: re-running it would replace a working secret and switch the account back to password-only, so the path to a new authenticator goes through proving you still hold the old one.
Disable needs a valid code, so someone who has lost their device cannot reset their own second factor, deliberately, because neither could anyone who took over their session. Contact TensorRail support; the reset is an audited operator action.
Step-up on a sensitive action
Creating or revoking an API key, changing webhook configuration, changing the team, and changing the IP allowlist each ask you to confirm with a current two-factor code before they take effect. The dashboard prompts for it inline and remembers it for a couple of minutes, so a burst of related actions does not re-prompt each time.
Active sessions
Security → Active sessions lists your own open sessions (where each one started, last activity, which device), lets you sign one out, or sign every session out at once, including the one you are using; both need a fresh two-factor code. You can only sign out your own sessions.
revoke-all is the right first move on a suspected session compromise: sign everything out, then
sign back in. It is tightly rate-limited. Pair it with an
emergency key revoke if a key may also be exposed; the two are separate
credentials and revoking one does nothing to the other.
If our identity service cannot be reached, this list is shown empty rather than as an error. Treat an unexpectedly empty list as "unknown", not as "no sessions are open".
Recent logins
Security → Recent logins shows up to 30 groups of recent sign-in activity for the account, most recently seen first. Activity is grouped by network prefix and browser family rather than stored as full addresses. Each group shows when it was first and last seen and a count of authenticated dashboard requests from that group (a count of requests, not of sign-ins), and a group first seen in the last seven days is marked new. Individual sign-ins are not listed.
The network and browser are those of the person using the dashboard. An address on a private or internal network is never used as a baseline or listed here.
Password
Security → Password: enter your current password and a new one, with a fresh two-factor code. The current password is verified before the new one is set.
A new password must be at least 8 characters and contain an uppercase letter, a digit and a special character.
Changing the password does not sign other sessions out; use revoke-all for that.
Security notifications
Security-relevant events email your account. The Security notifications card on the Security page shows the current preferences and lets you change them.
| Field | Default | Event |
|---|---|---|
security_email | (empty) | Where these emails go. Empty means your notification address, and failing that the account email. |
notify_on_key_emergency_revoked | true | An API key was emergency-revoked. |
notify_on_key_rotated | true | An API key was rotated. |
notify_on_login_unusual | true | The dashboard was used on your account from a combination of network (the /24 or /48 prefix) and browser family not seen on it in the last 90 days. The account's first activity sets the baseline without an alert. If our edge could not identify where a dashboard session came from, the alert is sent without a network. |
notify_on_ip_allowlist_changed | true | An IP allowlist entry was added or removed. |
Changing one preference leaves the rest as they were. An address without an @ is refused; clearing
security_email back to blank goes back to your notification address, and failing that the
account email.
Turning an email off does not stop the event being recorded: the audit log keeps every one of them either way.
Related
- IP allowlist: restricting secret-key API calls to known networks.
- Team and roles: who can do what, and how to invite them.
- API key management: the other half of account access.
- Emergency key revoke: immediate revocation for a compromised key.
- Reporting API: reading the audit trail.
TensorRail, Limassol, Cyprus.