Security in the console

The console (app.prod-orm.io) has a page for everything the CLI's klock
commands do: sessions, devices, access rules, behaviour profiles, MCP client
tokens, capabilities and lockdown, plus the team, database and staff views.
This page says where each one is. How each feature works is in the guides it
links to.

Where	What
`web/src/consoles/basic/security/*`	Account security (`#/security`)
`web/src/consoles/basic/auth/{CliLogin,Pair,Recovery}.tsx`	CLI sign-in, pairing, lock-out recovery
`web/src/consoles/team/*`	The team page's security tabs
`web/src/consoles/basic/database/access-rules/*`	The database page's Access rules tab
`web/src/consoles/team/TeamBillingPanel.tsx`	The team's billing account
`web/src/consoles/admin/{AdminUserDetail,AdminKlock,MfaRequired}.tsx`	Staff views, and the E3 MFA prompt

Account security

#/security?tab=<tab> has these tabs:

Tab	Shows and does	CLI equivalent
Sessions	Every kind of session (browser, CLI, CLI token, trusted device, service, MCP client, staff), filtered by kind or live only. Each row shows its device, subject, check-in deadline, step-up time, frozen reason, limits and capabilities. Sign out; freeze (klock kinds, optional reason); unfreeze (asks for a TOTP code, or the password on an account without MFA). Sign out everywhere else ends your other person sessions and keeps service sessions (database hosts, CI, agents); sign those out one by one, or see below. Its CLI tokens card mints explicit personal tokens for `--token` / `PRORM_TOKEN` (CI, scripts); it sends `purpose: "token"`, which E3 still allows, for 30 days at most. Key rotation is CLI-only.	`prorm sessions`
Devices	Your devices with their key store (file-held keys are flagged as weaker), last sync and country, and state. Rename, suspend or reinstate, wipe (best effort, at the next sync), revoke. Pair a device opens `#/pair`. A row opens `#/security/devices/:id`: details, credentials, the sessions on the device and its audit trail.	`prorm devices`
Two-factor	TOTP enrolment, and removal, which asks for the password and a code from the authenticator app or a recovery code (see below). Admin accounts need a confirmed factor from E3.	`prorm security mfa enable`, `prorm security mfa disable`
Access rules	Account-scope rules, with report-only and enforced badges and expiry. A `409 would_lock_you_out` offers "save anyway" behind a step-up. Test this request evaluates your rules in the browser, with the same engine as the API, against the request context the API reports or an IP and country you type. It is a preview; the API decides.	`prorm access`
Behaviour	Findings (acknowledge, or show acknowledged ones), profiles (edit, remove), and adding a profile from a preset with a JSON editor. New profiles start in report mode, and saving may ask for a step-up. The API validates profiles; the console does not.	`prorm behaviour`
MCP clients	Delegated tokens: capabilities, database lock, last use, expiry. Create one with a capability picker (only delegable capabilities you hold; quick picks "Docs only", "Read my data", "Read and write data"), for 1, 7 or 30 days, optionally locked to one database. The token is shown once, with MCP settings JSON ready to paste. At most 5 are live; a sixth replaces the least recently used.	`prorm mcp clients`
Capabilities	`GET /me/capabilities`: tier, session kind and binding, plan, team role, staff scopes, capabilities by group, dormant capabilities, each team's role capabilities, and limits by session kind. A Step up now card.	`prorm whoami --caps`, `prorm step-up`
Audit log	The account's audit trail.	`prorm security audit`
Danger zone	Emergency lockdown: type `LOCKDOWN`, optionally include service sessions, step up. It signs this browser out too. Release is here as well.	`prorm lockdown`

See klock for sessions and devices,
Access rules and behaviour profiles for
rules, profiles, lockdown and recovery, MCP for client tokens,
and Capabilities for tiers and step-up.

Signing out everywhere

"Sign out everywhere else" (DELETE /security/sessions) spares service
sessions: a database host, a CI runner or an agent keeps working when you
sign your people sessions out. A password reset does the same. To end them
too, revoke each service row on the Sessions tab, use the lockdown's
"include service sessions" box, or call the API with includeServices:

See signing out everywhere for the
exact rule and the staff routes.

Removing the second factor

Removing a confirmed TOTP factor (DELETE /security/mfa) needs the current
password and the second factor itself: a six-digit code from the
authenticator app, or a recovery code. The code is spent. The console's
removal dialog and prorm security mfa disable ask for both:

$ prorm security mfa disable
Current password:
Code from the app, or a recovery code (empty if never confirmed): 492 017
✓ Two-factor is off.

Without a code the API answers 401 with { "mfaRequired": true }.

Wrong passwords and wrong codes both count toward the step-up lockout; once
it is reached the route answers 429.

An enrolment that was never confirmed is still removed with the password
alone, so leave the code empty there.

Before 4.9.2 the password alone removed the factor
(PRORM-SA-2026-067).

Email addresses

Every address on an account is confirmed with a six-digit code mailed to it
(POST /me/emails/:id/verify, and /resend for a new code). A code expires
after 15 minutes and allows 5 attempts; each address also has a daily budget
of wrong guesses and of codes sent, and too many answer 429 with
Retry-After. Only a verified address reserves the address, can become the
login address, or is used by team single sign-on.

To change the login address, send the new one with PUT /me. It answers
202 with emailVerification (pending: true), leaves the login address as
it is, and mails the code to the new address and a notice to the current one.
Entering that code makes the new address the login address at once; both
addresses are told, and the change is audited. A request lapses after 24
hours: a later code confirms the address but does not switch to it. Addresses
added with POST /me/emails are only confirmed, never promoted; make one the
login address with PUT /me/emails/:id/primary once it is verified.

[!NOTE]
These are control-plane changes on feat/klock-capabilities (API 3930e9d,
and 7386d41 for the PUT /me flow;
PRORM-SA-2026-024). No
address that existed before was marked verified, so confirm yours with
resend, then verify. Password sign-in is not affected. Earlier
builds of the fix needed PUT /me/emails/:id/primary after the code, and
the 202 carried promoteAt; neither is needed now.

Team single sign-on

A team's SSO domains admit nobody until each is proved with a DNS TXT
record, and domains that existed before the change are pending again until
they are proved. SSO identities belong to the issuer that created them, so
changing the issuer is audited and the old issuer's identities stop working.
An existing account joins SSO only through a subject it linked before,
POST /sso/link from a session that passed password and MFA, or, automatically,
when the team's own SSO created it and its address is verified at a proved
domain (PRORM-SA-2026-001).

The API only talks to a provider at a public address. The issuer and every
endpoint its discovery document names must be https at a public host; the
host name is resolved once, every address is checked (loopback, private,
link-local, CGNAT, multicast, reserved and documentation ranges, and the IPv6
forms that embed them, are refused), and the request is sent to the checked
address, so a second lookup cannot redirect it. Redirects and responses over
1 MiB are refused, and SSO errors no longer include the provider's HTTP status.
An issuer or endpoint that fails the check gets 400
(PRORM-SA-2026-063).

Signing in, pairing and recovery

#/cli: CLI sign-in. prorm login opens it with the port, state,
hostname and, for klock v2, the device keys and confirm code. The page
shows the six-character code (as KXQ 7M2), and you must tick "My terminal
shows …" before "Yes, the codes match". "The codes do not match" aborts
with a warning. kind=device asks "Trust this device?" and a step-up. The
grant goes to the CLI's loopback listener, or through the relay when the
browser cannot reach 127.0.0.1. When the API offers no v2, the console
falls back to a legacy 30-day token; a CLI that has signed in with v2
before refuses it unless you run prorm login --legacy. Under E3 the API
answers a v1 link with 410 login_v2_required, and the page shows
Update the CLI to sign in: nothing is signed in, and it tells you to
update prorm and run prorm login again, or to mint a token under
Security › Sessions › CLI tokens for a script. The full flow is in
the CLI guide.

#/pair: approve a pairing. Signed in, enter the code that
prorm login --pair shows on the new device (KXQ7-M2PD), or open the
#/pair?p=…&c=… link from its QR code, and approve it as a trusted device
or a session. See pairing.

#/recover: lock-out recovery. Public. Enter your email; the link it
sends (valid 30 minutes, once) brings you back with a code. Then give your
password, and a TOTP code if you have MFA, for a one-hour recovery session
that lands on Security › Access rules with a banner.

The terminal:

$ prorm login
Confirm code: KXQ7M2   (the console shows the same code — approve only if they match)
Sign in in the browser to connect this CLI:
  https://app.prod-orm.io/#/cli?port=53127&state=…&host=ada-mbp&v=2&dpk=…&spk=…&sb=…&cc=KXQ7M2
✓ Signed in as ada (ada@example.com) on this device (dev_Q4M8…).
klock v2 interactive session · key in the macOS Keychain · ~/.prorm/klock/default.klock
Check in by 28/09/2026, 11:00:00; the session ends 28/10/2026, 10:00:00.

The browser shows Sign the CLI in? with KXQ 7M2. What happens between
them:

A grant parked at the relay is useless without the device key it names, so
nothing secret ever sits in a URL.

[!CAUTION]
Approve only a code that your own terminal shows. Never approve a
sign-in or pairing code that someone read out, emailed or messaged to you:
that is how a device key on their machine gets a session on your account.

Pairing a device from the console

Start the pairing on the new device

$ prorm login --pair
Pairing code: KXQ7-M2PD
On a signed-in device: prorm devices approve KXQ7-M2PD   (or the console, Security → Devices)

The CLI waits for an approval until the pairing expires (ten minutes when
the service gives no expiry), then gives up with

The pairing was not approved
in time.

Approve it where you are already signed in

Open Security › Devices › Pair a device (#/pair), type KXQ7-M2PD or
scan the QR code, and choose a trusted device or a session. A trusted device
needs a step-up.

Check the new device

The new device prints ✓ Signed in as …. The device then appears in
Security › Devices, with its key store; a file-held key is flagged.

Recovering from a bad access rule

Ask for a link

Open #/recover ("Locked out by an access rule?") and enter your email. The
answer is the same whether or not the address has an account.

Open the link within 30 minutes

The link works once. It brings you back to Recover your account with the
recovery code filled in.

Prove it is you

Give your password, and an authenticator code if the account has one. You get
a one-hour browser session that skips account rules only, and the
account's block rules are switched to report mode with the note
recovery: pending review.

Fix the rules

You land on Security › Access rules. Remove the rule that locked you out.
The block rules marked recovery: pending review keep reporting until you
replace them: a rule cannot be edited, so remove each one you still want and
add it again. See recovery.

Teams

The team page (#/teams/:id?tab=<tab>) adds these tabs:

Tab	Shows and does	Needs
Resources	Everything reached through the team, and Create in this team. A resource created here is owned and billed by the team, counts against the team's plan, and survives its creator leaving.	`resource:provision` on the team to create
Devices	Members' devices and their sessions in the team context. Revoking needs a reason, and the member is emailed. A `step_up_required` answer asks for a TOTP code (or password) and retries.	`device:manage-members`, `session:manage-members`
Access	Team access rules, mandatory by default, so members cannot widen them. Every member can read them.	`access-rule:team` to write
Behaviour	Team behaviour profiles, from a preset or JSON; report mode by default.	`behaviour:team` to write
Billing	The team's own billing account (`TeamBillingPanel`): see below.	`billing:read` to see, `billing:manage` to change

See team-owned resources.

Team › Billing

A resource created in a team is the team's, and the team pays for it, not the
member who created it. The Billing tab is the team's account, with the
routes in a team's billing account:

Card	Shows and does
Plan	The plan and subscription, the monthly estimate and pool use. Before the team pays: Start paying (Stripe Checkout, with an optional membership). After: Change plan (free, usage, membership; it says "pending" until Stripe confirms) and Stripe portal.
Who pays	The billing contact, picked from members whose role can read billing; empty means the owner.
Transfer billing	Team transfers are charged to the team's card, not the member's.
Payment methods	The team's cards: add one (a Stripe-hosted page), make one the default, remove one.
This month	The lines the team's next invoice will have for its own resources.
Invoices	Every invoice Stripe has raised on the team's account.

Members with billing:read (owner, admin, billing) see the tab; only
owner and billing can change anything. On a deployment with no Stripe
configuration the actions are disabled and the API answers 503. Against an API without the team billing routes, the tab
shows transfer billing and "Team billing is coming soon".

Databases

The database page has an Access rules tab: database-scope rules (allow or
block by IP, country, ASN, device, certificate, principal, time, client or API
key), with optional capability patterns, expiry, a note, and enforce now
(otherwise a new block rule reports for 24 hours first). Rules are checked in
the browser with the shared engine before they are sent, and
would_lock_you_out offers "save anyway" behind a step-up. Addresses in the
legacy blockedIps list with no matching block rule appear as read-only
legacy rows. The engine firewall (allowedIps) is shown beside the rules
as "Network (engine firewall)", read-only; edit it on the Access tab.

Staff

For prorm staff only:

Account page. Sessions (every kind) and Devices sections. With
the support scope, a staff member can revoke a session, or revoke or wipe
a device. Each needs a reason of 10–500 characters and a TOTP step-up in the
same dialog, before anything is sent (there is no password fallback). The
account holder is emailed, and the action is audited at level alert.

Mandatory MFA. Under E3, every staff route answers an admin without a
confirmed TOTP factor with 403 mfa_required. The staff console shows
Staff accounts need a second factor instead of "not an admin", lists the
setup and confirm routes the API named, and enrols right there (the
/security/mfa/* routes are the account's own). Try again reloads the
admin's access once the factor is confirmed. From a terminal:
prorm security mfa enable.

Admin › Klock (#/admin/klock, scopes support or users), read-only:
the service configuration (/.well-known/klock-configuration), the keyset
(seq, dates, keys, and a warning within 14 days of expiry), the revocation
feed, and the device fleet overview. Authority and CA health show "coming
soon".

When a feature is not there

Every klock page shows "X is coming soon" instead of an error when the server
answers 501, 405, not_implemented or its catch-all 404, and "X is not
configured" on a 503 (for example klock_unconfigured when the API has no
klock service binding). A 401 step_up_required does not sign you out: the
page asks for your authenticator code and retries.

klock: sessions, devices, pairing, the klock service

Capabilities

Access rules and behaviour profiles

MCP

CLI

Security in the console

Account security#

Signing out everywhere#

Removing the second factor#

Email addresses#

Team single sign-on#

Signing in, pairing and recovery#

CLI sign-in, both sides#

Pairing a device from the console#

Start the pairing on the new device#

Approve it where you are already signed in#

Check the new device#

Recovering from a bad access rule#

Ask for a link#

Open the link within 30 minutes#

Prove it is you#

Fix the rules#

Teams#

Team › Billing#

Databases#

Staff#

When a feature is not there#

Related reading#