Security settings
Business Summary: Security settings will centralize SSO, API keys, and session policies for your organization. Until they ship, manage access through invites, roles, workstream teams, and connector authentication.
You will learn what the Security settings tab is for, what is planned (SSO, API keys, session policies), and where to manage access until those controls ship.
The Security tab under Settings is a roadmap surface — placeholder copy today, not production security controls.
Note: Security settings are planned. SSO, API keys, and session policies are not implemented in the web app yet. Manage access through organization roles, invites, and workstream teams meanwhile.
How this fits in Nimbus
Nimbus separates three security layers: platform authentication (sign-in today), org security policy (Security tab — planned), and governance (approvals and connector writes during agent work).
flowchart TB
SignIn[Sign-in today]
Security[Security settings - planned]
Gov[Governance and HITL]
Connectors[Connector auth]
SignIn --> Work[Agent work]
Security -.-> SignIn
Gov --> Work
Connectors --> Work
Governance controls what agents may release; Security settings will control how users and automation authenticate to Nimbus itself.
Opening Security settings
- Go to Settings
- Select the Security tab
- Or open Settings → Security
Planned capabilities
The empty state describes future controls:
| Capability | Intended purpose |
|---|---|
| SSO | Single sign-on via corporate IdP (SAML/OIDC) |
| API keys | Programmatic access for integrations and automation |
| Session policies | Session length, re-auth for sensitive actions, device rules |
Enterprise customers should discuss SSO timelines with their account team.
What to use today
Until Security settings ship:
| Need | Use today |
|---|---|
| Who can access Nimbus | Inviting teammates, org roles |
| Who can approve writes | Workstream HITL, Human-in-the-loop |
| Who can pay bills | Admin / super admin on Usage & Billing |
| Connector auth | Per-connector OAuth and keys at Connectors in the sidebar |
Sign-in already supports Firebase auth providers (email, Google, Microsoft) at the app level — distinct from org SSO policy UI.
Relation to governance
Governance controls agent outputs and connector writes. Security settings will control authentication and programmatic access — complementary layers. See Governance.
Example scenario
An enterprise IT lead asks when corporate SAML SSO will be self-serve. You open Settings → Security, share the planned capabilities list with her, and point her to current controls: invite-only access, org roles, workstream team restrictions, and IdP MFA on Google or Microsoft sign-in. Security settings document the roadmap; governance handles approval gates today.
What you'll see
Settings → Security today shows a planned empty state:
| UI element | Content |
|---|---|
| Icon | Lock |
| Title | Security controls |
| Body | Copy referencing future SSO, API keys, and session policies |
| Actions | None live — use Inviting teammates and org roles meanwhile |
FAQs {#faqs}
Q: Is our data insecure because this tab is empty? A: No — authentication and cloud security operate at platform level. This tab is for self-serve org security policy UI coming later.
Q: When will SSO arrive? A: On the product roadmap without a public date. Enterprise engagements may receive early access.
Q: Where do I rotate connector secrets? A: At Connectors connection management — not Security settings. See Managing connections.
Q: Can I enforce MFA? A: MFA enforcement will likely live here or via IdP when SSO ships. Use IdP MFA today if email/Google/Microsoft sign-in applies.
Q: Who can see the Security tab? A: Any signed-in user may see the placeholder; configuration actions will be admin-gated when implemented.
Q: How is this different from Governance? A: Governance governs agent outputs and external writes. Security settings will govern who can sign in and which API keys can call Nimbus programmatically.