Decoupling Authorization at Scale: MongoDB Atlas and Cedar-Based Resource Policies

As organizations scale applications, managing authorization becomes increasingly complex. What starts as role-based permissions quickly evolves into intricate rules spanning multiple services, regions, and compliance requirements. Traditional approaches of embedding authorization logic in application code lead to fragmented policies scattered across codebases, making them difficult to maintain, audit, and scale.

These challenges have become more acute in the age of AI. Modern applications now combine transactional databases with vector indexes, retrieval pipelines, streaming data flows, and model-driven services, all of which introduce governance boundaries. The rate of infrastructure experimentation has also increased, making hard-coded authorization logic increasingly brittle.

With all of this in mind, to best serve enterprise customers (including ~75% of the Fortune 100—and to put a policy framework in place that could move as quickly as AI—MongoDB evolved its Atlas database service beyond role-based access control to support the security demands of mission-critical applications.

This innovation was built on Cedar, an open source authorization engine and policy language developed by AWS and a current Cloud Native Computing Foundation (CNCF) sandbox project. It separates authorization logic from application code, provides human-readable yet machine-enforceable policies, supports both role-based and attribute-based access control, and includes mathematical verification of correctness. AWS offers Amazon Verified Permissions, a managed Cedar-based service, enabling customers to centrally manage authorization policies while benefiting from AWS’s security investments and proven scaling capabilities.

MongoDB’s adoption of Cedar in 2025 demonstrates how an Independent Software Vendor (ISV) and modern data platform provider can implement scalable resource governance across a multi-tenant platform. Through Cedar-based resource policies, MongoDB Atlas enables platform teams to enforce organizational guardrails across thousands of database deployments and multiple cloud providers— separating policy logic from provisioning code. This blog explores MongoDB’s decision to adopt Cedar, the architectural patterns for integration, and the business impact for both SaaS providers and their enterprise customers.

The Path To Cedar

MongoDB Atlas has traditionally offered role-based access control (RBAC) across organizational, project, and cluster scopes: organization roles (such as Organization Owner), project roles (for example Project Cluster Manager), and database-user roles within clusters. This three-tier model served MongoDB well through years of growth, providing clear separation of concerns and straightforward permission models that aligned with how enterprises organize their teams.

However, as MongoDB scaled to become the foundation of mission-critical applications for large enterprises such as Coinbase, Deutsche Telekom, and Novo Nordisk, a pattern emerged: while RBAC handles “who can do what,” it fundamentally cannot enforce “under what conditions” or “with what configurations.” Enterprise platform teams managing hundreds of projects and thousands of clusters faced an authorization gap. They could delegate cluster creation permissions, but they couldn’t prevent developers from:

• Creating clusters in non-compliant regions (data residency violations)
• Enabling wildcard IP access (0.0.0.0/0) that exposed databases to the internet
• Deploying undersized instances that couldn’t handle production load
• Using outdated TLS versions that failed security audits

Why Traditional Solutions Failed

MongoDB evaluated several approaches before choosing Cedar:

1. Expanding RBAC with more roles: While MongoDB continued to invest in RBAC with more granular roles for access control, using roles to enforce resource configuration constraints would quickly become unmanageable. MongoDB considered creating specific roles for every combination of cloud provider, region, configuration, and compliance requirement. What starts as a few combinations quickly grows into hundreds or thousands, becoming impossible to manage. MongoDB needed a dedicated mechanism for resource governance that complemented its existing access control model.
2. Hard-coded validation rules: Embedding these checks directly in Atlas provisioning code would have scattered authorization logic across the codebase. Each new constraint would require code changes, testing, and deployment. Policy updates would take weeks instead of minutes, and customers couldn’t self-manage their own guardrails.
3. Custom policy Domain-Specific Language (DSL): Building their own policy language would have required years of investment in language design, parser development, validation tooling, and security hardening—capabilities that weren’t core to MongoDB’s database expertise.

The Cedar Decision

MongoDB chose Cedar for three strategic reasons that align with how the company approaches product development:

1. Separation of concerns: Cedar cleanly decouples policy logic from provisioning logic. MongoDB engineering teams maintain API endpoints, cluster lifecycle management, and infrastructure orchestration without needing to understand every customer’s compliance requirements. Meanwhile, security and platform teams author policies that evolve independently of Atlas release cycles.
2. Declarative and auditable: Cedar policies are human-readable infrastructure-as-code. Customers can version them in Git, code-review them with Terraform configurations, and audit exactly which guardrails apply to which resources. This aligns with the DevOps practices enterprise customers already use.
3. Open source maturity: Rather than building authorization infrastructure from scratch, MongoDB leveraged AWS’s significant investment in Cedar. A policy language with formal mathematical verification, Cedar offers extensive tooling (VS Code extensions, validation APIs, test frameworks) and a growing ecosystem. Cedar underpins Amazon Verified Permissions and is battle-tested across AWS’s multi-tenant services.

Atlas Resource Policies Architecture

MongoDB scaled its enterprise RBAC authorization model by introducing Atlas Resource Policies, defined using Cedar. With these policies set at the organization level, Atlas customers can enforce constraints across all projects and clusters unless explicitly exempted.

Policies can enforce:

• Geographic restrictions: Limit clusters to approved regions (e.g., only EU for GDPR compliance)
• Network security: Prevent wildcard IP access (0.0.0.0/0) in IP access lists
• Configuration standards: Enforce minimum TLS versions (1.2+)
• Resource limits: Cap cluster tier sizes, disk sizes, sharding configuration to better control costs
• Cloud provider controls: Restrict deployments to specific providers (AWS-only, multi-cloud, etc.)

The key innovation is the enforcement level: policies evaluate at Organization scope but can reference project-level and cluster-level attributes. This means a single policy can say “across the entire organization, no cluster in any project may use TLS version below 1.2” to enable centralized governance with distributed execution.

From the developer perspective, Cedar-based policies enable self-service with safety. When a user attempts to create a cluster that violates a policy—for example, trying to deploy in an unapproved region—they receive immediate feedback with a clear error message explaining which policy was violated. This is fundamentally different from RBAC rejection, which only says “you don’t have permission.” Cedar failures explain “your configuration violates organizational security policy XYZ.”

This design philosophy reflects MongoDB’s broader product principle: empower users with clear constraints rather than restrict them with opaque permissions. Developers maintain autonomy to provision infrastructure quickly, while platform teams retain control over security boundaries.

Integration Patterns for MongoDB

MongoDB Atlas, as a database-as-a-service platform serving tens of thousands of organizations, needed a clear separation between the provisioning system (handling API endpoints, UI workflows, IAM roles, cluster lifecycle) and the policy evaluation system (enforcing guardrail logic). By embedding a Cedar evaluator that receives the principal, action, resource, and contextual attributes (such as context.cluster.cloudProviders, context.project.clustersInProject, context.cluster.minTLSVersion), MongoDB avoids scattering policy checks throughout the application code. Instead, policy authors work in Cedar, while engineers maintain provisioning workflows.

This architecture delivers several key advantages: consistent policy semantics across all tenants, seamless integration with infrastructure-as-code workflows (Terraform, CloudFormation), and the ability to evolve policy sets independent of core service logic. By adopting Cedar—an open source language with formal verification— MongoDB leverages a mature, high-performance decision engine rather than building authorization infrastructure from scratch. The result is a policy-driven guardrail layer that scales with Atlas’s multi-tenant platform, evaluating policies in real-time without impacting cluster provisioning experience.

Policy Evaluation Flow

As depicted in Figure 1, Atlas’ provisioning logic takes the resource creation or modification request and evaluates the access based on the role. If the role is not authorized, RBAC stops the processing. If the role is authorized to perform the action, it builds the contextual attributes for the request and passes them to the Cedar evaluator along with the defined resource policies. The evaluator consumes the defined resource policies and the contextual attributes to return a binary decision.

Figure 1. MongoDB Atlas resource policy evaluation flow

Implementing MongoDB Atlas resource policies

The following walkthrough demonstrates how to use the Atlas console to generate a geographic restriction policy in an Atlas organization to control the deployment of MongoDB Atlas clusters. This policy limits deployments to two AWS regions (us-east-1 and us-west-2), a common pattern for organizations managing data residency compliance, cost optimization, or regulatory requirements. Atlas evaluates the policy when users create or modify clusters—blocking non-compliant configurations and providing clear error messages that reference the violated policy.

Access Resource Policies

To create a resource policy, first navigate to the policy management page in the Atlas console:

1. Access Organization Settings by clicking on the MongoDB Atlas Icon
2. Find “Resource Policies” under Configurations in the left menu, and click to access the policy management page
3. Click the “Create Policy” button

Creating the Resource Policy

With the policy editor open, define your policy by providing a name, an optional description, and the Cedar policy code:

1. Enter a unique policy name, such as: “Limit Access to certain AWS regions” in the Policy Name field
2. (Optional) Add a policy description such as: “Limits launching MongoDB instances in AWS us-east-1 and us-west-2 regions only” in the Policy Description field
3. Paste the Cedar Policy code into the policy editor to define region restrictions, then click the “Create policy” button

Once created, the policy immediately enforces geographic restrictions across all projects in your organization. Atlas assigns a unique policy ID (for example, 693c658373154521ea8a3502) that you can use to reference this policy via the Atlas Administration API or Terraform. The policy evaluates in real-time during cluster operations—when users attempt to deploy or modify clusters outside us-east-1 or us-west-2, Atlas blocks the operation and returns a clear error message identifying the policy that was violated.

Policy validation occurs pre-enforcement, rejecting policies with parsing errors or unsupported principals and actions.

After creation, Atlas displays the active policy:

Creating a new MongoDB cluster

Attempting to create a cluster in any region other than us-east-1 and us-west-2 will receive an ‘Unsuccessful deployment’ error due to the resource policy restrictions:

Learn how to create Resource Policies tailored to your organization’s security and compliance requirements in the MongoDB Atlas documentation.

Business Impact & Use Cases

For MongoDB, Cedar-based Resource Policies enable scalable governance for thousands of Atlas organizations without engineering overhead. Rather than embedding authorization logic in provisioning code—requiring code changes, testing, and deployment cycles for each new constraint—MongoDB maintains policies as declarative Cedar code that platform teams can update independently. This separation reduces engineering maintenance burden, ensures consistent policy enforcement across all customers, and enables rapid policy iteration as compliance requirements evolve.

For Atlas customers, Resource Policies enable platform teams to enforce organizational standards without restricting developer velocity. These declarative guardrails provide audit-ready documentation of security controls while allowing developers to self-service provision clusters within defined boundaries—balancing governance with agility.

As of this writing, over 1,562 organizations have adopted Atlas Resource Policies to enforce governance standards across their deployments. Geoffrey Céré, Solution Architecture Advisor at iA Financial Group, explains: “Implementing Resource Policies has allowed us to proactively supervise the platform’s usage by our IT delivery teams. This has been helpful in preventing non-compliant configurations with the company’s regulatory framework.”

Conclusion

Looking ahead, MongoDB will continue expanding its use of Cedar to create new Atlas Resource Policies. Beyond current capabilities, MongoDB is developing policies to enforce database authentication methods, require clusters to use customer-managed encryption at rest, and control Atlas Search deployments. Each new policy uses the same Cedar language and evaluation engine, allowing platform teams to manage all organizational guardrails through a unified policy-as-code approach.

For platform providers building multi-tenant services, this implementation offers a proven pattern: adopt a declarative policy engine, manage authorization as code, and enforce at runtime with clear separation from business logic. As enterprises increasingly require fine-grained governance alongside operational agility, this architecture provides a sustainable path forward.

Resources & Call to Action

●      MongoDB Atlas Resource Policies documentation: https://www.mongodb.com/docs/atlas/atlas-resource-policies/

●      Cedar Policy Language Reference Guide: https://docs.cedarpolicy.com/

●      Cedar GitHub repository: https://github.com/cedar-policy/cedar

●      AWS documentation on Cedar: https://aws.amazon.com/about-aws/whats-new/2023/05/cedar-open-source-language-access-control/ (Amazon Web Services, Inc.)

For Platform Engineers and Security Teams: Explore how Atlas Resource Policies can enforce organizational standards while enabling developer self-service. Get started with the MongoDB Atlas Resource Policies documentation to create your first policy, or experiment with the Cedar Policy Playground to test policy logic before deployment.

For SaaS Platform Providers: Cedar offers a proven path to scalable authorization governance. Start with the Cedar GitHub repository to explore the open source engine, or deploy using Amazon Verified Permissions for a fully managed Cedar service.