Security

The Security page, under Manage in the sidebar, gathers the tenant's security posture in one place. It is shown to tenant administrators, to the built-in Security Auditor role, and to any custom role that carries at least one of the grants of its tabs; a tab the user cannot open is not shown.

Tab	Grant	What it holds
Overview	security_log.view	The controls in force and the last seven days, as numbers.
Audit Log	security_log.view (export and forwarding also need security_log.export)	The append-only record of who did what in the tenant. See the Audit Log guide.
Sessions	tenant.manage	Who is signed in to the tenant right now, and the means to end a session.
Trust Center	any Security grant	How this deployment is run and where the tenant's data goes, plus the public trust documents.

Authentication settings (single sign-on) and data retention will join as tabs of this page.

Overview

Four headline tiles (failed sign-ins and the accounts behind them, active sessions, exports and downloads, audit records written) over the last seven days, then four cards:

• Sign-in protection: succeeded, failed and blocked sign-ins in the window, and the throttling policy in force per account and per source address (slowed after 5 failures, blocked for 15 minutes after 20 within 15 minutes; per address 20 and 100). Links to the sign-in records.
• Access: active and deactivated users, custom roles, groups, active API keys, keys not used for 90 days and keys expiring within 30 days. Links to Team and to API keys.
• Audit log: retention, records per category in the window, and whether forwarding to a SIEM is on and delivering.
• Notifications: whether the tenant's security emails are on and how many addresses would receive them, with a Configure notifications link for tenant administrators (see Notifications below). The card says plainly which of three states applies: on, turned off for this tenant, or no mail server on this deployment. A warning appears when notifications are on but nobody holds the tenant administration permission tenant-wide, because then nothing can be delivered.

Every number is counted from the audit log and the tenant configuration when the tab opens; there is no separate store that could drift. Reading the Overview is not itself recorded in the log (it is counts, not records); opening the Audit Log tab is.

Sessions

Every live session of the tenant, one row each: the person (with You on the session you are using, and Deactivated on a user whose account has since been switched off), when they signed in, when they were last active, when the session expires, the source address, the browser and platform in plain words, and the sign-in method. Search matches email, name, address and client. Columns sort, reorder, resize and hide like the Team table.

A session lasts 7 days and renews itself while it is in use, so an abandoned browser drops off this list on its own within a week. To end one sooner, open the row's menu:

• End this session signs that one browser out on its next request.
• End all sessions of this user signs the person out everywhere in this tenant. A session the same person holds in another tenant is that tenant's business and is not touched.

Both ask for confirmation and are recorded in the audit log as auth.session.revoked with the reason revoked_by_admin, the person as the target and the number of sessions ended; session tokens are never written anywhere. Your own session cannot be ended from here: sign out for that. The menu on your own row offers to end your other sessions only.

The list is read from the session store when the tab opens, so it is exact at that moment; press Refresh for a new reading. The "last active" time is the last request the session made, at minute resolution.

The tab is the answer to "who has access right now" during an incident: end the sessions, then deactivate the account on the Team page (which ends sessions as well) or reset its password. The other direction works too: a user's row menu on the Team page offers Sessions, which opens this tab searched on that person.

Notifications

A small, fixed set of security events is sent by email: repeated failed sign-ins blocking an account, changes to a role's permissions, assignment of a role that can manage the tenant, new API keys, audit retention changes and audit log exports. The set is the same for every tenant and is not configurable per event; anything beyond it is a rule in your SIEM over the forwarded audit log.

Who receives them, and whether they are sent at all, is the tenant's own setting. Configure notifications on the Overview (tenant administrators, tenant.manage) opens a dialog with:

• Send email notifications: on by default. Turn it off when a SIEM receives the forwarded log and the emails would only duplicate its alerts.
• Also send to: extra addresses, one per line, such as a security team mailbox. Up to 20. The tenant administrators (everyone holding tenant.manage tenant-wide with an email address) always receive the emails while the switch is on; the dialog shows how many that is.

Every change to this setting is itself recorded in the audit log as config.security_notifications.updated.

When the deployment has no mail server, the switch is disabled and the card and dialog say so; invitations and license alerts are affected in the same way. Configuring email is the platform operator's job (System Settings, Email). The operator has a separate address and switch for the emails that concern them (audit write failures, retention changes on the system stream); neither side governs the other.

Security Auditor

The built-in Security Auditor role is the compliance or SOC person's role: it holds security_log.view and security_log.export and nothing else, so its holder can read the audit log, download it and configure SIEM forwarding without being able to manage users, sessions or the tenant. It is tenant-wide (the audit log has no project) and only a tenant administrator can assign it. An export by an auditor is itself recorded and emailed to the tenant administrators, which is what makes handing the evidence out to a non-administrator safe. A read-only variant is a custom role carrying security_log.view alone.

Trust Center

The tab has two halves.

This tenant is read from the deployment's configuration, never declared by hand, so it cannot drift from what is actually running:

• the deployment model (vendor-hosted, self-hosted in your cloud subscription, or on your own infrastructure);
• where documents are stored and how they are encrypted at rest (with the local file system backend the application does not encrypt files itself, so that depends on the disk);
• how long the audit log is kept, whether it has its own storage container (the precondition for an immutability policy) and whether it is forwarded to a SIEM;
• whether the AI assistant is enabled;
• where your data goes: which services receive data on the tenant's behalf, grouped by purpose (AI models, OCR, the assistant, the license service, email, audit forwarding). A known provider is named as such; any other recipient is shown by its domain. The number of configured endpoints behind each purpose is given (the same unit as the Models page, so several deployments on one host count separately), endpoints the tenant added on the Models page are counted on their own, and the AI models entry lists the tasks those endpoints declare (split, classify, extract, redact, and so on).

This list is the answer to the "who receives our data" question of a security questionnaire, for the deployment in front of you rather than in general. It deliberately stops at the provider: resource hostnames would tell you nothing more and would describe the deployment to anyone who reads the page, and an endpoint's configured region is a routing preference rather than a residency guarantee, so neither is shown. Residency commitments are stated in the Sub-processors document.

Documents links to the public Trust Center pages and the Audit Log guide, and offers to request the security questionnaire pack by email. The deployment facts also link to the self-hosted deployment guide and the performance calculator, for a tenant weighing where to run the product.

The Support page's Trust Center row lands here for anyone who can open the Security page, and on the public pages for everyone else: one name, the depth follows the grant.

Where License went

The License page is no longer a sidebar item. Open the user menu at the bottom of the sidebar; under the current tenant, holders of the Manage license permission see a License row with the current state (expiry or the reason it needs attention) that opens the License page.