Our security posture: How we safeguard your repositories

Our customers trust us with their most valuable asset: their source code. That trust is why security is central to our mission of helping developers ship better code faster.

When there’s a chance to strengthen our security posture, we act quickly and decisively. And when we design new systems, we design them with “security by default” in mind.

We share below the architecture that makes CodeRabbit more resilient, limits the potential impact of any one component, and ensures that the data entrusted to us remains safe under all circumstances.

Overview

Customers install CodeRabbit on their git platforms via the app marketplace. We integrate via webhooks with all popular Git providers such as GitHub, GitLab, Bitbucket & and Azure DevOps. The integration allows us to register webhooks on events such as PR opened, user comment, etc.

Each event is processed in complete isolation. We maintain a secure internal queue that verifies subscriptions, applies rate limits, and ensures that only authorized events are allowed through. Events are handled one at a time, with zero shared state and no assumptions about what came before or after.

This model gives us something incredibly valuable: containment by default. If an attacker were to compromise one event, they would find nothing else to pivot to – no shared memory, no long-lived tokens, no context beyond that single, short-lived process. Every review starts from scratch, runs alone, and ends clean.

Our architecture at a glance

Here’s a high-level look at how our system is structured in our git-based, IDE, and CLI reviews:

This design is focused on limiting an attacker’s potential “blast radius” – or how much damage an attacker can do if they succeed at breaching one component. By isolating secrets, tightly scoping tokens, and strengthening our encryption, we’ve drastically reduced that radius.

Our layered approach

We use these layered strategies:

1. Sandbox

We create a secure sandbox environment for each code review event to clone the codebase in order to read files, pull context from various sources in our knowledge base about your code and to run tools, linters, web search queries & verification checks. Our sandboxed environment only has the short-lived token for that particular repository, but it contains absolutely no other secrets, API keys, or credentials. Even if an attacker were to achieve remote code execution within our sandbox environment or get out of the sandbox and break the sandbox kernel-based isolation mechanism, they would find nothing of value - no environment variables with tokens, no configuration files with secrets.

Internal network access is also blocked from the sandbox. Tools may connect to the internet when required, but they cannot reach CodeRabbit’s internal services.

2. Token Service Separation

To reinforce the isolation of workloads, we have fully embraced a model based on short-lived session tokens rather than long-lived secrets. Instead of passing environment variables or static credentials, every process is scoped with query or event-specific tokens. These git provider tokens are valid only for the duration of the event or process. These are customer-specific, short-lived tokens. These tokens also have strict rate limiting and audit logging.

This means that workloads never carry unnecessary privileges. They can only access the resources required to process a specific pull request – and nothing more.

By removing persistent credentials from execution environments, we eliminate one of the most common attack surfaces. Even if a third-party tool were exploited, the attacker would see nothing beyond the minimal context of the current event.

3. Customer Data Isolation & Encryption

Each customer's code review is completely isolated. We provision separate containers per code review and use customer-scoped tokens that can only access their specific repositories. There is no shared state between customers.

We also ensure that our code index and all cached code is encrypted with a unique key per customer. Even CodeRabbit employees can't see any code-related data we store. You can also opt out of these features if you don’t want a cached copy of your code.

This layered approach ensures that even if an attacker were able to gain access, they would be unable to access anything critical.

Our broader security posture

A security best practice is to layer multiple controls so that if one fails, others remain in place. We’ve implemented several layers of defense to protect customer code and data:

Automated sandbox enforcement: Every external tool must run in an isolated sandbox environment. This rule is enforced automatically.

• Hardened deployment gates: We’ve added pre-deployment checks that verify no service can bypass sandbox isolation or attempt to run with escalated privileges.

• Encryption by customer key: Code indexes and cached code are encrypted with a per-customer key. This ensures that even if cache data were exposed, it would remain unreadable without the correct key.

• Auditing and monitoring: We’ve expanded our monitoring of sandboxed environments and added automated alerts for unexpected behavior or network activity.

• Expanded training: Every CodeRabbit engineer receives additional security training focused on secure-by-design practices and safe handling of secrets.

• Least privilege access: Users, processes, and systems are granted only the minimum level of permissions and access rights necessary to perform their specific tasks and nothing more.

• Vulnerability disclosure program (VDP): We maintain a formal program that invites independent security researchers to report potential issues responsibly. This ensures that if a weakness is discovered, it can be addressed quickly, transparently, and in partnership with the security community.

• Penetration testing and architectural reviews: We work with multiple third parties to conduct routine penetration testing and architectural reviews to routinely audit and improve our security posture.

Looking ahead

We’re committed to building on this foundation by continuing to work with independent auditors, engaging with security researchers through responsible disclosure, and refining our internal practices.

Our goal is to deliver world-class AI code reviews with the highest levels of security and reliability.