The Air-Gapped CI Pipeline: Inside twentyhq/ci-privileged

How the open-source CRM Twenty isolated its GitHub Actions to solve the "pwn-request" problem, creating a zero-trust DMZ for automated code review.

7 min read • View on GitHub • More from twentyhq

A medieval castle lowering its drawbridge to admit a wooden Trojan horse holding a glowing lockpick. This represents the vulnerability of untrusted code entering a trusted build environment.
Untrusted pull requests present an existential threat to open-source CI environments holding cloud secrets.

Privileged CI operations for twentyhq/twenty. Handles PR comments, cross-repo posting, and other write operations isolated from contributor-accessible workflows.

Felix Malfait, Top Contributor · twentyhq/ci-privileged
Key Takeaways

The Open-Source Trust Paradox

When an open-source project runs Continuous Integration on a public pull request, it invites untrusted code into its infrastructure. If a workflow has write permissions or access to cloud secrets, a malicious contributor can alter the execution path to exfiltrate them. This is the "pwn-request" problem.

Standard mitigations often involve manual approvals or stripping permissions entirely. However, modern automated workflows require elevated access to post preview URLs, run visual regression tests, and analyze breaking changes. The team behind the Twenty CRM needed a way to maintain automation velocity without compromising security.

The Demilitarized Zone

To solve this, Twenty built ci-privileged. It acts as a highly restricted execution environment that holds sensitive tokens but never executes code from the main repository. The architecture enforces a strict unidirectional trust flow.

Hedcut portrait of Felix Malfait.

The unidirectional trust flow isolates execution while allowing automated feedback.

The main repository is treated as hostile. It can only emit a repository_dispatch signal across the boundary. The privileged repository wakes up, reaches across the boundary, and downloads static artifacts.

Defensive Engineering and Eventual Consistency

Because the privileged repository cannot rely on synchronous execution, it must poll the main repository for artifacts. The scripts use robust retry logic to account for the eventual consistency of the GitHub API.

for attempt in $(seq 1 30); do
  # ... curl API ...
  if [ -n "$ARTIFACT_URL" ]; then break; fi
  sleep 30
done

Once the artifact is secured, the script parses the data and uses an HTML marker to upsert comments on the original pull request. This keeps the timeline clean rather than spamming the thread with new comments on every commit.

The Visual Regression Vault

A close-up of a secure pneumatic tube system connecting to a heavy steel vault door. A sealed glass cylinder containing a rolled-up blueprint arrives at the vault. Mechanical eyes scan the cylinder before the gears turn.
The privileged repository functions like a vault that only accepts static, scannable packages, refusing executable instructions.

The most complex workflow in this repository handles visual regression testing. It downloads a Storybook tarball, assumes an AWS OIDC role to upload it to S3, and calls a private Cloudflare-protected API to trigger a visual difference check.

By moving this entire sequence to the privileged repository, sensitive AWS and Cloudflare credentials never touch the main environment. The untrusted code has no pathway to the secrets.

The Cost of Paranoia

This custom approach offers a unique blend of automation velocity and token isolation. It is a masterclass in defensive infrastructure engineering for open source.

ApproachAutomation VelocityToken IsolationSetup Complexity
Dispatch DMZ (ci-privileged)HighCompleteHigh
GitHub EnvironmentsLow (Requires Manual Clicks)PartialLow
Cloud OIDCHighVulnerable (GitHub PR write tokens exposed)Medium