docs(security): operator-merge IS enforced on the internal forge

Per mara (verified in forge.rs): agents have max_repo_creation=0, so every
internal-forge repo is core-created with branch protection on by default
(merge restricted to operators team + required operators-team approval via
apply_operator_branch_protection / the config-repo equivalent), and agents
(write collaborators, not admins) can't change it or self-merge. So it's
technically enforced there, not just convention — only external VCS (GitHub)
is unprotected. Corrects my prior over-correction.
This commit is contained in:
atlas 2026-06-26 01:42:04 +02:00 committed by mara
commit 8e366c8a10

View file

@ -52,13 +52,17 @@ shell) on the attacker's behalf.
Mitigations are therefore about **bounding capability and inserting human Mitigations are therefore about **bounding capability and inserting human
checkpoints**, not about sandboxing the agent from its own tools: checkpoints**, not about sandboxing the agent from its own tools:
- **Operator-merge convention** — an agent may *push* branches, but the norm - **Operator merges, not the agent** — an agent may *push* branches, but a
is that **a human (the operator) merges the PR**, keeping a person in the **human (the operator) merges the PR**, keeping a person in the loop on the
loop on the highest-value action. This is largely **convention, not a highest-value action. On the **internal forge this is technically enforced,
blanket enforced gate**: the internal forge applies branch protection only on not just convention**: agents can't create repos (`max_repo_creation = 0`),
the `core`-managed config repos (the config-PR merge flow), and it is **not** so every repo is `core`-created with branch protection **on by default**
set up for external VCS (GitHub etc.) — there, operator-merge is process and merges restricted to the operators team + a required operators-team approval
accepted risk, not a technical control. (`apply_operator_branch_protection` / the config-repo equivalent) — and an
agent (a write collaborator, not a repo admin) can neither change those
settings nor merge its own PR. It is **not** set up for external VCS (GitHub
etc.), though — there, operator-merge is process + accepted risk, not a
technical control.
- **Approvals** — config changes, schedule additions, and other - **Approvals** — config changes, schedule additions, and other
blast-radius-y operations route through the operator approval queue blast-radius-y operations route through the operator approval queue
(see [`approvals.md`](approvals.md)). (see [`approvals.md`](approvals.md)).