Skip to lesson
Exit
AI-assisted review, testing & anti-patterns1 / 2

2 min lesson

The governance guarantee: automations never merge

Take this case and make the call: "A customer worries that wiring automations into their SDLC means agents will merge code on their own and that it opens a big new security surface. Reassure them precisely."

Step 1 of 2

The governance guarantee: automations never mergethe merger is accountable, full stop

Here is how Cursor's own engineering team states the rule, and it's the cleanest version of the bright line you can hand a customer: no automation agent ever merges directly to the repo. It always produces a PR a human reviews and the person who clicks merge is accountable for what lands. You can layer BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. and as many validation automations as you like in front of that PR. The accountability never moves off the human who merges.

Staying on the propose side doesn't mean dumb dispatch. A mature pattern is the risk-rated PR automation: an agent triggers on PR-opened, classifies the change as low / medium / high risk, and routes accordingly. A genuinely low-risk change (say a title or copy tweak) gets auto-approved and merges easily; a high-risk change is held for human review and the automation assigns the right reviewers by running Git blame to find the people who actually own those lines. That's the deterministic dispatch behind the bright line: the agent does the routing, the human still owns the merge on anything that carries risk.

The one genuinely new attack vector

Wiring automations almost never changes your security story, with one exception worth saying out loud: a triggerable automation opens a new vector. If anyone in a Slack channel (or any external surface) can fire an automation that touches code, then everyone who can fire it effectively has a path to your codebase. If those people shouldn't have repo access, don't wire them to a code-touching automation.

Contain it the usual way: read-only integrations where you can (a read-only SQL connection can't drop a prod table), least-privilege scopes, and hooks that block secrets or private keys before any change is proposed.