From 524b1de98c7e27c1fe0aa03a7d9c373a6e1e435f Mon Sep 17 00:00:00 2001 From: atlas Date: Fri, 26 Jun 2026 01:29:23 +0200 Subject: [PATCH] docs(security): correct the operator-merge bullet (mara review) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per mara: branch protection isn't a blanket enforced check, and it's not set up for external VCS (GitHub). Reframe the bullet as the operator-merge *convention* — technically enforced only on the core-managed config repos, and explicitly NOT wired up for GitHub/external VCS (process + accepted risk there, not a control). --- docs/security.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docs/security.md b/docs/security.md index 350fa7e9..20b1d571 100644 --- a/docs/security.md +++ b/docs/security.md @@ -52,11 +52,13 @@ shell) on the attacker's behalf. Mitigations are therefore about **bounding capability and inserting human checkpoints**, not about sandboxing the agent from its own tools: -- **Branch protection** — agents may *push* branches, but PRs are **merged by - the operator only** (existing hive convention; enforced on `main` via - branch-protection rules). This puts a human in the loop on the highest-value - action. It applies to **any** external VCS access too (GitHub etc.), not - just the internal forge. +- **Operator-merge convention** — an agent may *push* branches, but the norm + is that **a human (the operator) merges the PR**, keeping a person in the + loop on the highest-value action. This is largely **convention, not a + blanket enforced gate**: the internal forge applies branch protection only on + the `core`-managed config repos (the config-PR merge flow), and it is **not** + set up for external VCS (GitHub etc.) — there, operator-merge is process and + accepted risk, not a technical control. - **Approvals** — config changes, schedule additions, and other blast-radius-y operations route through the operator approval queue (see [`approvals.md`](approvals.md)).