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. Save the signing secret shown at creation. Verify x-provenant-signature as sha256=followed by the hex HMAC-SHA256 of the exact raw request body, using that secret and a constant-time comparison. Do not parse and reserialize the body before verification. Deduplicate the verified body's id(also sent as x-provenant-event-id). Persist or enqueue verified events before returning success. Deliveries retry with exponential backoff, up to six attempts, and failed deliveries can be inspected and replayed in Settings. Handle duplicates and do not assume ordering. An approval event precedes completion of downstream execution; fetch the action's current state. Delivery requires a paid plan.
  • 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.