How to protect repo against unwanted deletion?

[tmmlsBE]

Select Topic Area

Question

Body

The use of LLMs in development teams has become indispensable. These powerful AI features can perform many tasks autonomously, for hours on end, including command prompts, and unfortunately it is not entirely clear what has been executed. How do you prevent an LLM from accidentally deleting your entire online project repo or compromising versions and branches? What is the best approach?

[MuchuCAT]

Great question , this is a real risk when using LLMs with broad automation rights.

A practical, defense-in-depth approach usually works best :

1. Protect critical branches

• Enable branch protection rules on main / release
• Require PR reviews
• Disable force-push and direct deletes
  This alone prevents most catastrophic mistakes.

2. Least-privilege access for automation

• Never give LLMs or bots admin rights
• Use fine-grained GitHub tokens with read/write only where strictly needed
• Separate “analysis” bots from “write” bots

3. Mandatory human-in-the-loop

• Any destructive action (delete repo, rewrite history, mass delete files) should require explicit human approval
• Treat LLMs as assistants, not operators

4. Backups and recovery

• Enable repository backups (GitHub Enterprise or external mirrors)
• Periodic git clone --mirror to cold storage
• Rely on GitHub’s repo recovery window as a last resort, not a strategy

5. Guardrails in automation

• Dry-run mode by default
• Explicit allowlists (what can be changed) instead of blocklists
• Logging every action executed by the LLM

Protect branches, restrict permissions, require human confirmation for destructive ops & keep backups.

LLMs are powerful but they should never be trusted with irreversible actions.

[FaizalZahid]

An LLM should:

• Propose actions
• Simulate results
• Prepare commands
• Explain impact

But not execute destructive actions autonomously.
It's called copilot 😏, not autopilot.

TL;DR: you don’t rely on intelligence, you rely on constraints.

1. Strict Least-Privilege Access (Non-Negotiable)

Never give an LLM credentials that can:

• Delete repositories
• Force-push protected branches
• Modify production secrets
• Administer org-level settings

Do instead:

• Use read-only tokens by default

• Separate tokens per task (CI analysis ≠ repo writes ≠ deployments)

• Scope GitHub/GitLab tokens to:

  • single repo
  • specific branches
  • no admin rights

---

2. Hard Branch & Repo Protections

This protects you even from humans.

Mandatory protections:

• Protected branches (main, release/*)
• No force pushes
• Required PR reviews (human or bot)
• Required CI checks
• Disallow branch deletion
• Disable repo deletion except by owners

An LLM operating through Git physically cannot bypass these.

---

3. Human-in-the-Loop for Destructive or Global Actions

Define a clear line:

Action type	LLM allowed?
Code suggestions	✅
Local refactoring	✅
Creating PRs	✅
Merging PRs	❌
Deleting branches	❌
Changing CI/CD infra	❌
Secrets / credentials	❌

Pattern to use:

• LLM generates a plan + diff
• Human approves execution explicitly
• Execution happens via a separate, audited process

---

4. Sandbox Everything (Ephemeral Environments)

LLMs should:

• Run in throwaway environments
• Operate on forks, not the canonical repo
• Use temporary workspaces
• Never touch production state directly

If something goes wrong:

• Kill the environment
• Nothing persists
• Nothing breaks

This is exactly how cloud providers test automation safely.

---

5. “Dry Run First” Enforcement

Force the LLM to:

• Generate commands with --dry-run
• Output diffs instead of applying them
• Describe what will change before any execution

Example:

git diff
terraform plan
kubectl diff

If the system can’t show you what will happen, it doesn’t get to run.

---

6. Immutable Audit Logs (So You’re Never Guessing)

Your concern about “it’s not entirely clear what has been executed” is a red flag.

You want:

• Every command logged

• Every token usage traceable

• Every LLM action correlated to:

  • time
  • prompt
  • output
  • execution result

If you can’t reconstruct events, you’re flying blind.

---

7. Separation of Roles (Critical for Teams)

Use different LLM roles, not one omnipotent agent:

• Reviewer LLM → reads code, comments only
• Author LLM → generates diffs, no merge rights
• Ops LLM → observes metrics, cannot deploy
• Planner LLM → proposes actions, executes none

This mirrors real engineering orgs for a reason.

---

8. Backups and Repo Immutability

Even with everything above:

• Enable repo backups
• Enable object retention (where supported)
• Mirror critical repos to a secondary remote

If disaster still strikes, recovery is minutes, not weeks.