Container Isolation

Security Model

When deployed as a platform, each code review runs in an isolated container that is destroyed after completion. This ensures:

• Your code is only accessible during the review
• Reviews cannot interfere with each other
• No data persists between reviews
• The backend never directly touches your code

How It Works

One-Way Communication

The security model is built around one-way communication:

Backend ──watches──▶ Container Runtime API
                     (Docker events / K8s watch)

Container ──pulls code──▶ GitHub/GitLab
Container ──posts review──▶ GitHub/GitLab
Container ──✗ cannot reach──▶ Backend, Database, Other Containers

1. Backend dispatches — The backend creates a container job with the necessary credentials (short-lived tokens)
2. Container pulls code — The container pulls the repository directly from GitHub/GitLab
3. Container runs review — The AI agents analyze the code and post comments
4. Backend watches — The backend monitors container status via the runtime API (Docker events or Kubernetes watch). Containers cannot call back
5. Container is destroyed — After completion (or timeout), the container is removed

What the Backend Never Does

The backend never:

• Clones or reads your repository code
• Stores source code in the database
• Passes code through the message queue
• Keeps code after the review completes

The backend only handles: user auth, webhook events, job dispatching, and status tracking.

Security Properties

Network Isolation

• Docker: Containers run with --cap-drop ALL, --security-opt no-new-privileges, read-only root filesystem, and PID limits. Can be placed on isolated networks
• Kubernetes: NetworkPolicy denies all ingress and restricts egress to external HTTPS only — review pods cannot reach internal services

See the Security Hardening guide for detailed network isolation configuration

Resource Limits

Both backends enforce resource limits to prevent runaway processes:

Non-Root Execution

Containers run as a non-root user (UID 1000) by default. On Kubernetes, this is enforced via pod security context:

run_as_non_root: true
run_as_user: 1000
run_as_group: 1000

Ephemeral Containers

Containers are destroyed after completion. Nothing persists between reviews:

• No shared volumes between review containers
• No persistent storage
• No container reuse

Short-Lived Credentials

Containers receive short-lived tokens (GitHub installation tokens, GitLab PATs) that provide access only to the repository being reviewed.

Kubernetes-Specific Security

Kubernetes provides additional isolation layers: