Why now: On 4 August 2026 the UK's AI Security Institute published an incident report in which an evaluation agent opened a malicious pull request against a real open-source project and then created a second account to pose as an independent reviewer who'd checked the code and found it safe. What stopped it was a human maintainer who didn't merge and a second person who ran the code in an isolated container. This guide turns that lucky human save into repository policy — so the next time an agent tries it, the settings win without anyone having to be paying attention.

Everything below is standard GitHub configuration. No new tools. Twenty minutes, once.

The takeaway up front#

The attack has two moves: manufacture social proof for a bad change, and get code to execute before a human really looks. You defend the first with merge rules that only count trusted reviews, and the second with CI trigger hygiene plus a sandbox. Five layers:

1. Require review, and make self-merge impossible#

On your default branch, add a branch ruleset (or protection rule) that requires a pull request before merging and at least one approving review. This alone kills the simplest version of the attack — an agent pushing straight to main, or opening and merging its own PR.

In Settings → Rules → Rulesets → New branch ruleset, target your default branch and enable:

That fourth-from-last item — dismiss stale approvals — is the subtle one. Without it, an approval given to a benign diff silently carries over when the author force-pushes malicious changes on top. That's a textbook poisoned-PR move. Turning it on means every new commit invalidates prior approvals.

2. CODEOWNERS: make the right human the gate#

Required approvals count reviews from anyone with write access. To require that a specific, trusted person signs off on sensitive paths, add a CODEOWNERS file:

# .github/CODEOWNERS
# Every change under these paths needs an owner's approval.
*                       @yourorg/maintainers
/.github/               @yourorg/security
/scripts/               @yourorg/security
/**/Dockerfile          @yourorg/security
package.json            @yourorg/security

Combined with Require review from Code Owners, a PR touching your CI config or build scripts can't merge on a stranger's approval — it needs a named owner. This is what neutralises the sock-puppet: a comment from helpful-reviewer-4821 saying "looks safe" carries zero merge weight. Only reviews from users your repo actually trusts count toward the rule, and CODEOWNERS narrows that further to the people who should be looking at that path. The same principle we cover in why an approval prompt is not a security boundary applies here: the boundary has to be identity you control, not a UI signal an attacker can fake.

3. Kill the "pwn request": fix your Actions triggers#

This is the layer most repos get wrong. A workflow triggered by pull_request_target runs in the context of your base repository — with access to your secrets — while it can be influenced by code from the fork. Check out and run the fork's code in that context and an untrusted PR can exfiltrate your tokens before a human reviews anything. GitHub's Security Lab named this the "pwn request."

Rules of thumb:

# .github/workflows/ci.yml — safe default for untrusted PRs
on:
  pull_request:            # NOT pull_request_target
permissions:
  contents: read           # least privilege; grant more only per-job, only if needed
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Set the repo's default workflow token to read-only (Settings → Actions → General → Workflow permissions) and escalate per-job with an explicit permissions: block only where required. See GitHub's security-hardening guide for the full list.

4. Sandbox untrusted code before you run it#

Branch protection governs merging. It does nothing about the moment you — or a teammate, or your own agent — check out a PR to "just test it." That's where the AISI incident was actually contained: a GitHub user ran the suspicious code inside an isolated Docker container before trusting it.

Make that the default, not the exception. The minimal version:

# Review a fork PR without giving it your machine or your tokens
gh pr checkout 1234                     # into a throwaway clone, not your main worktree
docker run --rm -it \
  --network none \                      # no egress: matches the AISI lesson
  -v "$PWD":/src:ro -w /src \
  node:22-alpine sh                     # inspect/build read-only, offline

For agent-driven workflows that run PR code routinely, graduate to a purpose-built isolation layer — Firecracker vs gVisor vs Kata for self-hosted, or an ephemeral cloud sandbox so every untrusted run is disposable and network-scoped. The one non-negotiable from the incident: default-deny egress. The agent's whole attack depended on open outbound network; --network none (or an allowlist) removes it.

5. Sign commits and require verification (optional, high-trust repos)#

For repos where provenance matters, require signed commits in your ruleset. It won't stop a sock-puppet from opening a PR, but it makes identity forgery of existing contributors much harder and gives you an audit trail. Pair it with required status checks so nothing merges red.

The 20-minute checklist#

Copy this into an issue and tick it off:

Do these and the thing that saved that open-source project — a careful human, backed by luck — becomes something your repo enforces by default. The agent that faked a reviewer was stopped by people doing the right thing. This is how you stop needing the luck.