Settings

Organization configuration — identity, team, and integrations (admin-only).

Organization — name, the fleet risk-approval threshold, and the approval SLA (minutes before a pending approval escalates and re-notifies). The danger zone below it deletes the organization outright: an admin types the exact org name, the subscription is cancelled, and everything the org owns — members, agents, action history, and the entire audit ledger — is irreversibly erased (the GDPR-erasure path). Export first.
Team — invite teammates and manage roles (admin / operator / viewer). For a member locked out of MFA (lost authenticator and recovery codes), an admin can Reset security: their second factors are cleared (audited in the ledger), their password works again, and — when the org requires MFA — re-enrollment is forced at their next sign-in. Admins cannot reset their own factors.
Identity — configure OIDC single sign-on (endpoints, client id/secret, allowed domain, JIT provisioning & default role) and SCIM 2.0 provisioning (generate / rotate a bearer token, disable). SSO login requires the IdP to assert a verified email before it matches or provisions an account (opt out per-connection only for an IdP you trust). Deprovisioned users lose access on their next request. The Sign-in security card can require a second factor for password sign-ins: members without one (including invited and SCIM-provisioned accounts using a password) are walked through enrollment at their next sign-in, before they get a session.
Secret managers — per-org Vault / AWS / Azure / GCP configuration for secret references, including multiple named instances of the same provider type.
Notifications — per-org approval notification channels (Slack, PagerDuty, or a generic webhook) carrying signed out-of-band approve/deny links.
Webhooks — HMAC-signed callbacks on denials, approvals, anomalies, and budget warnings/exceeded.
License — on self-hosted deployments only: the license key that sets the deployment's plan and validity.

Each member manages their own factors on Your profile (sidebar footer): an authenticator app (scan the QR, confirm a code), passkeys (Touch ID, Windows Hello, security keys), and ten one-time recovery codes minted at enrollment. A passkey is also a complete sign-in on its own — "Sign in with a passkey" on the login page needs no email or password (the device's biometric/PIN check stands in for both factors). Password accounts can also change their sign-in email from the profile: current-password-gated, and nothing changes until the confirmation link sent to the new address is opened (the old address gets a security notice). SSO/SCIM accounts can't — their identity provider owns the address. Accounts are removed by an admin (Settings → Team) or by SCIM deprovisioning — members don't delete their own accounts.

MFA and SSO

The MFA requirement applies to password sign-ins. Sign-ins through your identity provider are exempt on purpose: the IdP owns authentication strength there, so require MFA in its policy (Okta, Entra, Google) instead of stacking a second prompt here. The setting still protects any password fallback sign-ins.

The sole admin has no safety net

The admin Reset security action deliberately excludes yourself — so an organization whose only admin loses both their authenticator and their recovery codes has no in-product recovery. Keep recovery codes somewhere durable, register a passkey as a second path, or appoint a second admin. (Self-hosted operators have database-level recourse; the hosted platform treats this as a manual support case.)

Organizations created by self-serve signup also get an email-verification link. It's non-blocking — the account works immediately, with a dashboard banner (and a resend button) until the link is opened. Verifying protects account recovery: a mistyped address can't receive password resets. Invited and IdP-provisioned members are not asked to verify.

Connectors are configured under Govern → Connectors; SDK snippets and the deployment's runtime facts are under Operate → Developer.