Access control

Least privilege is the default across users, machine credentials, and enterprise identity.

Role-based access control

Atlas provides organizations with roles and granular permissions, so access is granted by role rather than per user. Membership and role assignment are scoped to an organization, and — like all tenant data — that scoping is enforced at the data layer (see Tenant isolation), so a role in one organization can never reach another's data.

Least-privilege API credentials

Machine access uses scoped credentials, and scopes are enforced by a guard at request time — not merely stored on the key. A few consequences of that design:

• A personal access token or API key can only do what its scopes allow; broad access is opt-in, not the default.

• Impersonation is walled off: minting a sign-in token requires its own dedicated scope, so a credential with users:write cannot quietly escalate into signing in as a user.

• Destructive automation is gated: destructive tools exposed to the Model Context Protocol (MCP) integration require a literal boolean confirm, and refusals are recorded in the audit log — not just successful actions.

Because scopes are checked on every call, revoking or narrowing a credential takes effect immediately rather than depending on where it was used.

SSO and SCIM for enterprises

• SSO: Atlas supports enterprise single sign-on over SAML 2.0 and OIDC, alongside its broad catalog of social and enterprise login providers. Organizations can enforce SSO, requiring members to authenticate through the connected identity provider.

• SCIM provisioning: Atlas supports inbound SCIM (your IdP provisions and deprovisions users into Atlas via short-lived SCIM tokens) and outbound SCIM provisioning (Atlas pushes users and groups to downstream targets). Deprovisioning through SCIM removes access without manual cleanup.

• Network controls: network ACLs and allow/block lists can constrain where and how an instance is reached.

Visibility

Every privileged action is observable. Administrative and security-relevant events are written to the audit log, which is append-only and exposes no mutation path (covered in Application security and below), and audit data can be streamed to your own SIEM via log streams for independent retention and alerting.