--- title: "Security" slug: admin/security url: https://projectri.com/docs/admin/security section: admin audience: admin app_route: "/[slug]/admin/security" permissions: [security.view, security.policy, security.session, integration.api_token] mobile: "/admin/security" updated: 2026-09-08 source: Projectri documentation --- # Security The sign-in rules this workspace enforces, who is signed in, what machine credentials and outside applications can reach it, and the sign-in history. ![Security](https://projectri.com/docs-shots/admin-security.png) ## What it is Security is one screen with nine tabs, because an administrator arrives here for exactly one of them. It holds the password and sign-in policy, the IP allow-list, every member's session and second-factor posture, the API tokens this workspace has minted, the outside applications somebody has authorised, the phones registered for notifications, who may not reach an AI model, and the log of sign-in attempts. ## How to get there **Security → Security** in the admin console rail. The console itself is ADMIN-only, with one deliberate exception: a custom role holding `security.view` may open `/admin/security` and its sub-pages without being made a full administrator. That key also gates the whole payload the page reads, so without it the tabs come back empty. What each action needs: | Action | Permission | |---|---| | Read the page | `security.view` | | Save the policy, the allow-list, reset someone's 2FA, AI access | `security.policy` | | Sign a member out, unregister a device | `security.session` | | Mint or revoke an API token, disconnect an application | `integration.api_token` | | See the connected applications list | `integration.view` | There is no plan gate on this screen. ## How to use it ### Set the password and sign-in policy 1. Open the **Policy** tab. If the page says these are the platform defaults, they are already in force — saving records them as this workspace's own so a later change to the defaults cannot move them underneath you. 2. Set minimum length (6–64 characters), and whether an uppercase letter, a number and a symbol are required. 3. **Expire passwords** takes a number of days from 1 to 3650. Leave it blank for passwords that never expire. 4. Under **Sign in**, set the session timeout in minutes (5 to 525600; the default is 10080, which is seven days), how many failed attempts lock an account, and how long the lockout lasts. 5. Press **Save policy**. The bar at the bottom only appears once something has changed, and **Reset** puts the form back. ### Require two-factor authentication 1. On the **Policy** tab, turn on **Require two-factor authentication**. 2. A **Grace period before enforcement** field appears — 0 to 365 days. Existing members keep signing in until it runs out. 3. Save. The **Members** tab then shows each person's posture: enrolled, due by a date, overdue, or unfinished. Somebody past the grace period cannot sign in at all until they enrol. ### Restrict which addresses may reach the workspace 1. Open the **Network** tab. 2. Add your ranges first. The box takes an IPv4 or IPv6 address, or a CIDR range such as `203.0.113.0/24`; a bare address is treated as a single host. A label like "Office VPN" is optional. 3. Only then turn on **Enable IP allow-list**, and save it from the **Policy** tab — the switch lives there. 4. While the allow-list is enforced, adding a range that would exclude your own address is refused. ### Limit which email domains can be invited On the **Policy** tab, add domains under **Allowed email domains**. Both `@acme.com` and `me@acme.com` are read as `acme.com`. Empty means no restriction. ### Sign somebody out, or everybody 1. Open the **Members** tab. 2. **Sign out** beside a person revokes every live session they have. 3. **Sign out everyone** does it for the whole workspace, including you — your own session ends shortly after. ### Clear a member's second factor 1. On **Members**, press **Reset 2FA** beside somebody who is enrolled. 2. Confirm. Their authenticator and every unused recovery code are removed, and they sign in on a password alone until they enrol again. Do this only when you have confirmed who you are speaking to by some means other than this product. It writes an audit line whether or not anything was found to remove. ### Mint an API token 1. Open **API tokens** → **New token**. 2. Give it a name, choose an expiry of 30, 90 or 365 days, or **Never**. 3. Tick the scopes. They are the same permission keys the rest of the product uses, fetched from the catalogue so the picker cannot offer one the server would reject. A token with no scopes can authenticate and do nothing. 4. The token's plaintext is shown **once**. Only its hash is stored, so it can never be shown again. Copy it before closing the dialog. 5. **Revoke** on a live token stops anything using it immediately. ### Connect an editor or agent over MCP 1. Open the **Connect IDE** tab. 2. Pick your client — Claude Code, Nia IDE, Cursor or Codex — and one of three scope presets: **Read-only**, **Read and write**, or **Everything, including financials**. 3. Each preset is narrowed server-side to the scopes *you* hold, and names the ones it had to drop rather than counting them. 4. The configuration blocks render before a token exists, with a placeholder. Generating a token substitutes it in place — and again, it is shown once and dies with the page. 5. The endpoint is this deployment's own `/api/mcp`, taken from the address your browser actually reached. ### Review and disconnect third-party applications 1. Open **Connected apps**. These are applications an outside vendor registered and somebody in this workspace authorised — not connectors Projectri wrote. 2. Each row states whether Projectri has reviewed the application, who authorised it, when it was last used, how many live tokens it holds, and which scopes it was granted. 3. **Disconnect** revokes everything it holds at once. Anyone with `integration.api_token` can do this, including when the person who authorised it has left. ### Switch AI off for a named person 1. Open **AI access**. The list shows only the people who are *blocked*, so an empty list means nobody is — it is an answer, not an unconfigured feature. 2. **Switch AI off**, then find the person. 3. What this buys, stated on the card: a blocked person cannot cause an AI call in this workspace, including through an agent they own. Their name can still appear in other people's prompts, because a colleague's briefing legitimately mentions who they are waiting on. ### Read the sign-in log The **Sign-in log** tab lists the most recent attempts against this workspace with the address, the method and — for a failure — the reason: wrong password, no account, unverified, locked, suspended, blocked by the IP allow-list, expired code, or bad code. ## What it affects - **Every password set anywhere.** The policy is applied at sign-up, at reset and at change, not only on this screen. - **How long a session lives.** `sessionTimeoutMin` is the real expiry on the token minted at login. Raising it lengthens sessions across the whole product. - **Sign-in itself.** Failed attempts, lockouts, the allow-list, the MFA requirement and enforced SSO are all read by the login path, and each refusal lands as a row on the Sign-in log tab with a stable reason. - **The audit log.** Saving the policy, revoking sessions and clearing a second factor all write audit rows, readable on [Audit log](/docs/admin/audit-log). - **Integrations.** The API tokens tab and Connected apps are two views of the same credential table. Revoking here stops the integration, the agent or the editor immediately. - **Identity.** **Require single sign-on** on the Policy tab is only meaningful once a provider is connected and its domains verify — see [Identity](/docs/admin/identity). ## On mobile `/admin/security` in the Expo app carries the half that happens away from a desk: the sign-in history, the registered devices, member sessions and the ability to end one now. The password policy, the IP allow-list, token minting and the Connect IDE wizard stay on the web, because they are settle-in-and-think work and because a token shown once has to be pasted into a config file on the machine you did not bring. ## Limits and gotchas > [!WARNING] > Add your IP ranges before you turn the allow-list on. That order is what stops > you locking yourself out. The screen refuses a range that would exclude your > own address only while the list is already enforced. - **A device is not a session.** The Devices tab lists push registrations. Removing one stops notifications reaching that phone and signs nobody out — force sign-out is a separate action on the Members tab. - **A token's plaintext is shown once and never again.** Only its hash was ever stored. The same is true of the token the Connect IDE wizard mints; navigating away from that tab destroys it. - **One session per platform.** A second sign-in on the same platform evicts the first, so a member can be signed in on a browser, an iPhone and an Android device at once but not on two browsers. Devices linked by scanning a pairing code are counted separately. - **Enrolled with no recovery codes left is the next lock-out**, and it arrives without warning. The Members tab flags it in amber. - An **SSO only** badge on a member means they have no password at all. If you disconnect the identity provider they cannot sign in until they reset one. - Copying a token fails outside a secure context — the screen says so rather than pretending it worked. ## Related - [Identity](/docs/admin/identity) — OIDC single sign-on and directory provisioning. - [Audit log](/docs/admin/audit-log) — what was changed here, and streaming it to a SIEM. - [Members](/docs/admin/members) — suspending, removing and re-inviting people. - [Integrations](/docs/admin/integrations) — the connectors, and where third-party apps come from. - [Two-factor authentication](/docs/account/mfa) — what a member does when the policy requires one. - [MCP and the API](/docs/features/mcp-and-api) — what a token can actually reach. ## Related - [Identity](https://projectri.com/docs/admin/identity.md): Connect an OIDC identity provider so people sign in with their work account, and a SCIM connector so your directory creates and deactivates them. - [Audit log](https://projectri.com/docs/admin/audit-log.md): Every recorded action in this workspace, who did it and from where, with a bulk export and streaming to your own SIEM. - [Members](https://projectri.com/docs/admin/members.md): The workspace roster and the pending invite list — invite people, change roles, suspend, remove, and do any of those to many people at once. - [Integrations](https://projectri.com/docs/admin/integrations.md): Connect this workspace to the tools you already use, see which connections are healthy, and find the third-party applications somebody has authorised. - [Two-factor authentication](https://projectri.com/docs/account/mfa.md): Enrolling an authenticator, recovery codes, what a workspace can require, and how to get back in when the phone is gone. - [The API, MCP and connected apps](https://projectri.com/docs/features/mcp-and-api.md): Three ways software reaches a Projectri workspace — the REST API, the MCP server for coding agents, and third-party apps a member authorises.