AI Writes the CI/CD Pipeline: Auditing AI-Generated GitHub Actions Workflows

Developer Simon Willison published simonw/browser-compat-db in June 2026 — a ~66 MB SQLite database built from Mozilla's mdn/browser-compat-data repository and served directly from a GitHub branch. What makes it worth a security team's attention is not the data itself but the authorship of the automation: Willison used two different AI models on two distinct tasks, with no hand-written pipeline code in sight.

Two Models, One Pipeline

Claude Code (Opus 4.8) authored the Python conversion script that transforms the MDN JSON corpus into SQLite via sqlite-utils. Codex Desktop (GPT-5.5) wrote the GitHub Actions workflow that rebuilds the database on demand and force-pushes the result to a db orphan branch. The split reflects an emerging pattern in AI-assisted development: different models for different tasks, with the developer acting as orchestrator rather than author.

What This Means for CI/CD Security Reviews

As AI code generators become the default author of CI/CD automation, security teams face a practical problem: most code review culture focuses on application logic. GitHub Actions workflows — which can access organisation secrets, write to repositories, and trigger downstream deployments — often receive far less scrutiny than a pull request touching business logic. That gap widens when the YAML was generated at speed by a model rather than typed by an engineer who might at least have noticed the permissions block.

Five Things to Check in AI-Generated Workflows

• Permission scoping: AI models frequently omit the permissions: block entirely, defaulting to whatever the repository or organisation grants. Every workflow should declare explicit, minimal permissions.
• Unpinned action versions: AI-generated workflows commonly reference actions by mutable branch tag (actions/checkout@v4) rather than immutable commit SHA. A compromised upstream action can poison every build without any change in your own repository.
• Secret exposure in log steps: Look for echo ${{ secrets.TOKEN }} patterns or environment variable bleed-through in debug steps — models sometimes add instrumentation that leaks credentials to build logs.
• Expression injection via untrusted input: If a workflow interpolates ${{ github.event.issue.title }} or similar user-controlled fields into a run: step, it is vulnerable to injection. Sanitise inputs or bind them to intermediate environment variables first.
• Scope of write access: Workflows that push to branches need explicit review of which branches are protected and whether automated pushes can overwrite release or deployment targets.

The Orphan Branch and Force-Push Trade-off

Willison's workflow force-pushes the rebuilt database to an orphan branch called db. This is a reasonable pattern for generated binary artefacts — you do not want a growing commit history for a file rebuilt on every run. The risk is that GitHub branch protection rules are usually scoped to named branches such as main and do not automatically cover orphan or automation branches. Security teams should verify that automation branches are excluded from deployment triggers unless explicitly intended, and that protection policies cover every branch capable of influencing a production deployment.

CORS, Public Data, and the CDN Layer

The decision to serve the database from a regular repository branch rather than a release asset was driven by CORS: GitHub release assets do not carry open Access-Control-Allow-Origin headers, but repository-hosted files do. This works well for public, non-sensitive data. For teams considering similar patterns with internal or regulated data, the implication runs the other way — files committed to a GitHub repository can be exposed via misconfigured token scopes or accidental repository visibility changes. Public CDN hosting through a repository branch demands the same access-control rigour as any public API endpoint.

The broader lesson from browser-compat-db is not a warning against AI-assisted development — it is a prompt to build review processes that match how automation is now actually written: by AI, quickly, and often without a human reading the YAML before it runs. Checklists and automated linting close that gap without slowing delivery.