AI Agent Governance — One Engineer, Over a Hundred Repositories and the Decisions No Agent Makes

What AI agent governance looks like when every commit has one author#

Required reviews and required checks are the standard answer. The first assumes a second person. The second assumes a rule in every repository that names the right job and is kept current as jobs change. This fleet has one maintainer, me, plus my agents, and it carries neither, by decision 16: branch rules block force-push and deletion, and nothing else. In that state, this is the recipe GitHub documents for merging Dependabot’s pull requests:

1
# dependabot-auto-merge.yml, shortened from the GitHub documentation recipe: safe only where a branch rule requires the checks
2
name: Dependabot auto-merge
3
on: pull_request
4

5
permissions:
6
  contents: write
7
  pull-requests: write
8

9
jobs:
10
  dependabot:
11
    runs-on: ubuntu-latest
12
    if: github.event.pull_request.user.login == 'dependabot[bot]'
13
    steps:
14
      - name: Enable auto-merge for Dependabot PRs
15
        run: gh pr merge --auto --merge "$PR_URL" # nothing required: gh merges at once, red checks included
16
        env:
17
          PR_URL: ${{ github.event.pull_request.html_url }}
18
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The documentation pairs it with advice to require status checks on the target branch, and with that rule in place the recipe is sound. Without it, the GitHub command line does not wait. Its source merges at once in three merge states, and two of them matter here: clean, and unstable, which GitHub defines as mergeable with a non-passing commit status.

A dependency update whose verification failed is still mergeable, because nothing that failed was required. It merges the moment the job runs.

I reproduced it on 18 October in a private throwaway repository with no branch rules and one check that fails on every pull request. With the check red, GitHub reported the merge state as unstable, and the documented command merged the pull request two seconds later without ever switching auto-merge on. Then I added one ruleset that requires that check and opened a second pull request. The same command switched auto-merge on and waited, and nothing merged.

So the ruleset is the right fix wherever someone maintains it. Across more than a hundred repositories it is a string that has to match a job name in each one, and a renamed job blocks every merge in that repository until somebody edits the rule.

The workflow below carries the dependency inside itself. It cannot run before the verification finishes, because the verification finishing is what starts it.

1
# 18 October 2026, GitHub CLI 2.97.0, a private repository whose only check fails on every pull request
2
pull request 1, no rule requires the check
3
  before:  mergeable=MERGEABLE  mergeStateStatus=UNSTABLE  verify=FAILURE
4
  gh pr merge --auto --merge  ->  merged at 15:52:09 UTC, auto-merge never enabled
5
pull request 2, a ruleset requires verify
6
  before:  mergeStateStatus=BLOCKED  verify=FAILURE
7
  gh pr merge --auto --merge  ->  auto-merge enabled at 15:52:42 UTC, not merged

1
# dependabot-automerge.yml, shortened from the workflow every template here carries: the verification on that commit decides
2
name: Dependabot auto-merge
3
on:
4
  workflow_run:
5
    workflows: ["Deployment Verification"]
6
    types: [completed]
7

8
permissions:
9
  contents: read
10

11
jobs:
12
  merge:
13
    if: github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.event == 'pull_request'
14
    runs-on: ubuntu-latest
15
    permissions:
16
      contents: write
17
      pull-requests: write
18
      actions: write
19
    steps:
20
      - env:
21
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
22
          REPO: ${{ github.repository }}
23
          SHA: ${{ github.event.workflow_run.head_sha }}
24
          VERIFY: ${{ github.event.workflow_run.path }}
25
        run: |
26
          pr="$(gh api "repos/$REPO/commits/$SHA/pulls" \
27
            --jq '.[] | select(.state=="open" and .user.login=="dependabot[bot]") | .number' | head -1)"
28
          [ -n "$pr" ] || exit 0
29
          gh pr merge "$pr" --repo "$REPO" --squash --delete-branch
30
          # a push made with this token starts no workflows, so verify main as merged
31
          gh workflow run "$(basename "$VERIFY")" --repo "$REPO" --ref main

Here the decision belongs to the repository’s own verification, run on that commit. A red run means the job does nothing. The update waits for a person. The last line closes a second gap: a merge pushed with the job’s own token starts no workflows, so main carried a merge nobody had verified. On 17 September that was 14 repositories out of 94, up from four two days earlier.

In a decade of production infrastructure, the controls that held never trusted who made a change; they checked what the change did. Authorship is not a control. Verification is.

Why this keeps happening#

Governance for agents is borrowed from governance for people. A human team scales review by adding reviewers. An agent multiplies the changes and adds no one, so the second pair of eyes that every default assumes is the one resource that shrinks. What is left is to approve faster or to let the agent approve.

Either way, the audit trail records a person approving everything.

Credentials make it worse. An agent running under an engineer’s account inherits whatever that account can do: spend, publish, delete. Nothing in the account knows whose hand is on the keyboard. Decision 7 took one class of key out of reach. The model credentials come from workload identity federation, so no API key exists to leak, and the only thing that can spend them is a workflow on one branch of one repository.

The good defaults are invisible too. Since 14 July 2026, Dependabot waits until a release has been on its registry for three days before proposing it, unless a configuration file shortens the wait or switches it off. Security updates are exempt and open at once. A default that needs no configuration is also a default nobody notices being turned off, which is why a fleet rule here fails any repository that shortens it.

A default is a decision made for a team that is not yours.

Risk and blast radius#

Change management is what an auditor reads first. The change-management criterion of SOC 2 expects each change to be authorized, tested and approved before it is implemented. When an agent commits under an engineer’s account and auto-merge decides, the record shows the engineer authorizing every change. The engineer saw none of them. The auditor’s finding lands on the control.

The usual answer is to give each agent an account of its own. That fixes attribution, which an auditor will ask for: the record would say which changes an agent wrote. It does not fix authorization. An agent account with write access merges what the engineer’s account merges, and the documented recipe merges its red pull requests the same way. Attribution answers who. The control has to answer whether.

The supply chain is the second exposure, and it is measured. This fleet merged 309 dependency updates in those 30 days, a median of 4.3 minutes after each was proposed. Fast is right when the verification decides and the release is three days old. Without the cooldown, a poisoned release could reach main within minutes of being published, and with a red check that is not required, it would reach main anyway. The blast radius of a template fleet is every server that pulls a template, not the repository. The recipe travels, too. Copied into a customer’s repository by a consultant or a forward-deployed engineer, it inherits that repository’s branch rules, or their absence, and nobody on either side has looked.

Three exposures never show up in CI at all: what an agent spends, what it publishes and what it destroys. Those are the three decisions kept out of its reach here.

Ways to decide whether a change merges, compared#

The table is about who holds the decision. Four of the five merge within minutes either way.

Framework: three decisions held by mechanism, the rest decided by checks#

1
# rules.sh, with the GitHub CLI: the one ruleset every default branch here carries
2
gh api --method POST "repos/${OWNER:?}/${REPO:?}/rulesets" --input - <<'JSON'
3
{
4
  "name": "default branch: no rewrite, no delete",
5
  "target": "branch",
6
  "enforcement": "active",
7
  "conditions": { "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] } },
8
  "rules": [{ "type": "non_fast_forward" }, { "type": "deletion" }]
9
}
10
JSON
11

12
# a credential reaches the CLI on standard input from the macOS keychain, never as an argument
13
security find-generic-password -s github-fleet -w | gh auth login --with-token

1
# .github/dependabot.yml: Dependabot's three-day cooldown stated, so shortening it shows up in review
2
version: 2
3
updates:
4
  - package-ecosystem: github-actions
5
    directory: /
6
    schedule:
7
      interval: weekly
8
    cooldown:
9
      default-days: 3

1
# plants.sh, in bash: each line of plants.tsv is a file, the text to replace, its replacement, and the check that must name it
2
set -uo pipefail
3
missed=0
4
while IFS=$'\t' read -r file old new check; do
5
  [ -n "$file" ] || continue
6
  cp "$file" "$file.orig"
7
  body="$(cat "$file")"
8
  if [[ "$body" != *"$old"* ]]; then
9
    echo "stale plant: $file no longer contains its text"
10
    missed=1
11
  else
12
    printf '%s\n' "${body/"$old"/"$new"}" > "$file"
13
    out="$(./run-checks.sh 2>&1 || true)"
14
    if grep -qF -- "FAILED $check" <<<"$out"; then
15
      echo "caught by $check: $file"
16
    else
17
      echo "MISSED by $check: $file"
18
      missed=1
19
    fi
20
  fi
21
  mv "$file.orig" "$file"
22
done < plants.tsv
23
exit "$missed"

Tradeoffs#

Holding decisions by mechanism costs speed exactly where speed is dangerous. A dependency update waits three days for its release to age, then a median of 4.3 minutes for verification. One opened while verification is broken stays open until a person looks, and two sat for four and seven days in a private repository before the heartbeat learned to look there. The model jobs cannot run from a laptop. OpenSSF Scorecard’s code-review check stays at zero, and the evidence page says so beside the score.

The alternative has a number too: 309 updates in 30 days, at five minutes of human reading each, is more than 25 hours a month spent approving lockfiles, and that review becomes a rubber stamp by the second week. The machine spends a median of 4.3 minutes on each and asks a person only when it says no.

The closing argument#

Agents will keep getting faster at writing changes, and arguing about how capable they are does not change what they are allowed to do. In this fleet they write, test and merge anything a check can judge, under my name. They do not spend past thirty dollars, publish or rewrite history. Capability is the vendor’s problem. Decision rights are yours.

Sources#

• GitHub Docs, Automating Dependabot with GitHub Actions (the auto-merge recipe and its advice to require status checks), accessed October 2026
• GitHub Docs, API reference for pull requests (the merge states, with unstable defined as mergeable with a non-passing commit status), accessed October 2026
• GitHub CLI, source of the pull request merge command (the merge states in which the auto-merge flag merges at once), accessed October 2026
• GitHub Changelog, Dependabot version updates introduce default package cooldown, 14 July 2026
• AICPA, Trust Services Criteria with revised points of focus (change management), accessed October 2026
• GitHub, the auto-merge workflow every template carries and the fleet’s conformance rules (the cooldown floor and stored cloud keys), accessed October 2026
• heyvaldemar.com, Evidence, who decides what, Decisions and the Ledger (the current counts, as of 19 October 2026)

Discussion#

If you run AI agents against a repository with one reviewer or none, or you have a reason to trust auto-merge without required checks, drop a comment below. Counterarguments are welcome and the comment thread is where I respond first. For longer back-and-forth with senior practitioners, join the discussion on Discord.