<!-- llms-explorer concept facts · https://llms-explorer.com/tree/atlas-three-tier-identity-model/ · pack 2026-10-23 · ~1271 tokens -->

# Atlas Three-Tier Identity Model

> Source-anchored research for Atlas Three-Tier Identity Model. Run status: COMPLETED.

Parent: [MongoDB Atlas IAM and RBAC](https://llms-explorer.com/tree/mongodb-atlas-iam-and-rbac/) · 6 facets · 13 facts · page: https://llms-explorer.com/tree/atlas-three-tier-identity-model/

## Definitions

- The three-tier description refers to organization roles, project roles, and database-user roles within clusters. Atlas separately distinguishes Atlas users from database users; three authorization scopes therefore do not imply three separate user directories. (high confidence) — [source](https://aws.amazon.com/blogs/opensource/decoupling-authorization-at-scale-mongodb-atlas-and-cedar-based-resource-policies/)

## Structure and components

- Organizations contain projects and centralize billing and teams. Projects separate environments, cluster configurations, network settings, and database-user credentials. (high confidence) — [source](https://www.mongodb.com/docs/atlas/organizations-projects.md)
- Organizations contain projects, and clusters belong to projects. Organization-level billing retains project usage visibility. Separate projects can isolate environments, credentials, and security configurations; this makes the project a meaningful security boundary. (high confidence) — [source](https://www.mongodb.com/docs/atlas/organizations-projects.md)

## How it works

- Organization Owner inherits Project Owner authority across the organization, including database access, even when explicitly assigned a weaker project role. These inherited owners are absent from the project access list. Auditing only that list can therefore miss privileged users. (low confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/atlas/reference/user-roles.md)
- Separate identity stores do not prevent management-plane data access: Project Owner includes Data Explorer access, and project data-access roles can authorize database operations through the UI. Review these permissions when separating operators from data readers. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/atlas/reference/user-roles.md)

## Problems, failure modes and limitations

- Database users belong to a project and, by default, can access its clusters and federated database instances subject to their roles. Restrict Access to Specific Clusters/Federated Database Instances narrows deployment scope; database roles further limit permitted operations and resources. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security-add-mongodb-users.md)
- Project Database Access Admin can manage database users and custom database roles without directly granting Data Explorer access. This distinguishes credential administration from direct UI data access; it does not prove that credential administrators cannot obtain data access indirectly. (low confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/atlas/reference/user-roles.md)

## Comparisons and alternatives

- Manage Atlas database users through supported Atlas interfaces. MongoDB documents CLI support, and DVLA describes using atlas dbusers list, describe, and create in test automation. DVLA supplies operational evidence for database-user lifecycle automation, rather than evidence about GCP authentication. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/security-add-mongodb-users.md)

## Facts and statements

- Atlas users authenticate to the management application; database users authenticate clients to MongoDB databases. An Atlas console login is not a database connection credential. (high confidence) — [source](https://www.mongodb.com/docs/atlas/organizations-projects.md)
- Database-user roles determine database privileges. Built-in-role users initially cover all clusters in their Atlas project; resource restrictions can narrow access to selected clusters. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security-add-mongodb-users.md)
- Manage Atlas database users through the Atlas UI, CLI, Administration API, or a supported integration. Unsupported direct modifications are rolled back. DVLA demonstrates database-user lookup and creation through atlas dbusers in an AWS test environment; that example is not a GCP authentication recipe. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security-add-mongodb-users.md)
- Assign application database users only the required database or collection privileges. Atlan documents creating a separate crawler database user and choosing built-in read access or a custom role limited to selected resources. (high confidence) — [source](https://www.mongodb.com/docs/atlas/security-add-mongodb-users.md)
- An Atlas account used to administer the service is separate from a database user used by database clients. An integration such as Atlan explicitly creates its own database user and assigns database privileges. (high confidence) — [source](https://www.mongodb.com/docs/atlas/organizations-projects.md)
