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:
parent
524b1de98c
commit
8e366c8a10
1 changed files with 11 additions and 7 deletions
|
|
@ -52,13 +52,17 @@ 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:
|
||||
|
||||
- **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.
|
||||
- **Operator merges, not the agent** — an agent may *push* branches, but a
|
||||
**human (the operator) merges the PR**, keeping a person in the loop on the
|
||||
highest-value action. On the **internal forge this is technically enforced,
|
||||
not just convention**: agents can't create repos (`max_repo_creation = 0`),
|
||||
so every repo is `core`-created with branch protection **on by default** —
|
||||
merges restricted to the operators team + a required operators-team approval
|
||||
(`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
|
||||
blast-radius-y operations route through the operator approval queue
|
||||
(see [`approvals.md`](approvals.md)).
|
||||
|
|
|
|||
Loading…
Reference in a new issue