Access & Security Policy
Requiring multi-factor authentication, capping session and credential lifetimes, and restricting the organization to an IP allowlist.
What it is
Access Policy is where an organization sets the rules everyone in it has to meet to get in and stay in. It answers two separate questions: how strong a sign-in has to be and how long it stays valid, and which network addresses are allowed to reach the organization at all. You find it from Organization -> Access Policy, and only organization admins can view or change it.
The screen is split into two sections that save independently. Changing something in one section and pressing Save access policy does not disturb the other, so you can tighten sign-in rules today and add an IP allowlist later without redoing either.
Access Policy requires the Pro plan or higher. On lower plans the screen shows an upgrade message in place of the form, and the organization runs on the platform defaults described below. The IP allowlist section has a higher bar still: it appears only on the Enterprise plan.
Every change you make here is recorded in the audit log, including who made it and when, so tightening or relaxing a policy is always attributable.
Sign-in and sessions
These four controls govern how members authenticate and how long that authentication counts for. Each one is optional: leave a field blank and the platform default applies.
| Control | What it does | If left blank or off |
|---|---|---|
| Require multi-factor authentication | Refuses any sign-in that cannot prove a second factor was used. | Members sign in with whatever their account supports. |
| Idle timeout (minutes) | Signs a member out after that long without activity. Minimum 5 minutes. | No idle limit; only the maximum session length applies. |
| Max session length (days) | Caps how long a single sign-in stays valid before the member has to sign in again. Between 1 and 90 days. | The platform default of 14 days. |
| Max credential lifetime (days) | The longest expiration anyone in the organization can put on a new API key or MCP token. Minimum 1 day. | No cap; credentials can be created with any expiration, including none. |
Idle timeout and maximum session length work together rather than overriding one another. A 30-minute idle timeout with a 7-day maximum means an active member is asked to sign in again once a week, and an inactive one is signed out after half an hour.
A note on multi-factor authentication
Turning this on does not add a second factor to the platform’s own sign-in; it requires that the sign-in you arrive with can demonstrate one already happened. Some providers cannot make that assertion at all. Google sign-in is the common example: it does not tell the application whether multi-factor authentication took place, so once this toggle is on, a member signing in with Google is refused even if their Google account genuinely has MFA enabled.
Before enabling this, confirm which providers your members actually use. Anyone signing in with a provider that cannot assert multi-factor authentication has to move to a work account that can, or to single sign-on. Enabling it without checking can lock out members who have done nothing wrong.
How the credential cap is felt
The maximum credential lifetime applies at creation time. When someone mints an organization API key, a personal API access key, or an MCP token, the expiration they choose has to fall inside the cap. Credentials that already exist are not shortened when you set or lower the cap; the limit takes effect on the next credential created.
This section applies to local email and password sign-in and to social sign-in with Google or Microsoft. If your organization uses single sign-on, members authenticate against your own identity provider, and that provider’s policies decide what multi-factor and session rules they meet. Set those expectations there, not here. The credential lifetime cap still applies either way, because API keys and MCP tokens are issued by the platform rather than by your identity provider.
IP allowlist
An IP allowlist restricts the organization to a fixed set of network locations. With a list in place, requests to the organization’s management interface are accepted only from addresses on it, and refused from everywhere else. An empty list means no restriction, which is the default.
You build the list one row at a time. Each row is either a single address, such as 203.0.113.4, or a CIDR range covering a whole block, such as 203.0.113.0/24. Add rows for each office, VPN exit, or build agent that needs access, and remove a row when that location is retired.
The IP allowlist section appears only on the Enterprise plan. Pro and Team organizations see the sign-in and session controls but not this section.
Before saving, the list is checked against your own current IP address. If the list you are about to save would exclude you, the save is refused and nothing changes. That makes it safe to experiment: the worst outcome is an error message telling you the list would shut you out.
The safeguard protects the admin doing the saving, not the rest of the organization. A list built from your office address alone will refuse every remote member, and any automation that reaches the organization from an address you did not list. Collect the addresses your organization actually uses before you turn this on, and expect to revisit the list whenever a network changes.