# How to Safely Run AI Coding Agents on Your Own Repos

> Run AI coding agents on your own repositories safely: least-privilege tokens, branch protection, isolated git worktrees, secrets hygiene, and real PR review.

Updated October 17, 2026 (first published August 3, 2026) · by the AQ team · Canonical: https://aq.dev/guides/safe-ai-coding-agents-on-your-own-repos/

Teams can safely use AI agents on their own repos with five controls: least-privilege credentials (a fine-grained GitHub token scoped to the one repository the agent works on), branch protection so nothing reaches main without a human approval, one isolated git worktree per task, secrets kept out of the agent's working directory, and a reviewer who did not drive the session on every agent pull request. The agent CLIs themselves add a sixth: Claude Code, Codex, Cursor, and OpenCode all ship permission and sandbox modes that bound what a session can touch. None of this requires new tooling; git, GitHub, and the CLIs already include every piece. This guide walks through each control in order.

## What can actually go wrong

An AI coding agent is a program that executes shell commands with whatever credentials and filesystem access you gave it. That framing tells you the failure modes:

- **Destructive commands.** An agent trying to "clean up" can delete files, reset branches, or drop a local database.
- **Credential misuse.** A token that can push to every repository you can reach turns one bad session into an organization-wide problem.
- **Prompt injection.** Instructions hidden in files, web pages, or tool output can redirect an agent that reads them. Published research through 2026 has found every tested coding agent vulnerable to some degree; vendor guardrails reduce the success rate but do not eliminate it.
- **Unreviewed code shipping.** The least dramatic risk and the most common: plausible agent code merging without a second set of eyes.

The right posture is to treat the agent as a capable but untrusted contributor: productive, fast, and never handed more access than the task in front of it needs. For a control-by-control treatment of the destructive-command case, see [limit what a coding agent can destroy](https://aq.dev/guides/limit-what-a-coding-agent-can-destroy/).

## Give the agent least-privilege credentials

Start with the token. GitHub's fine-grained personal access tokens can be scoped to selected repositories with per-permission grants, and GitHub itself recommends them over classic tokens precisely because classic tokens grant broad scopes across everything you can touch. For a coding agent, a sensible grant is: access to only the repository it is working on, Contents read and write, Pull requests read and write, an expiration date, and nothing else: no admin, no org scopes.

Just as important: keep credentials per user, not shared. A single "agent bot" token used by the whole team cannot tell you who ran the session that pushed the bad commit, and revoking it interrupts everyone. When each engineer's agent authenticates as that engineer (their GitHub identity, their model-provider account), the audit trail is real, revocation is surgical, and a leaked credential exposes one person's scope instead of the team's.

## Protect main before the first agent session

Branch protection is the control that makes every other mistake recoverable. In GitHub, a branch protection rule or ruleset on your default branch should, at minimum: require a pull request before merging, require at least one approving review, require your CI status checks to pass, and block force pushes. Rulesets (the newer mechanism) can layer with classic protection rules and apply organization-wide.

With that in place, an agent can do whatever it likes on its own branch and none of it reaches main without a human clicking approve. Give agent branches a recognizable prefix (ai/ or agent/) so reviewers know what they are looking at and you can audit agent activity later with nothing more than a branch listing.

Treat passing CI as the floor, not the ceiling: tests catch only what they cover, which is why the review step below stays mandatory.

## One task, one git worktree

Agents should not work in your primary checkout, and two agents should never share a working directory. Git worktrees solve both cheaply: a worktree is a linked working directory sharing the same .git data as your main clone, so each task gets its own files and its own branch without duplicating the repository.

```
# One isolated working directory per task
git worktree add ../fix-auth-flow -b ai/fix-auth-flow
cd ../fix-auth-flow   # point the agent here, not at your main checkout

# When the branch has merged
git worktree remove ../fix-auth-flow
```

The isolation contains the blast radius: an agent that mangles its worktree has mangled a disposable directory, not the checkout with your uncommitted work. It also makes parallel sessions practical, since agents cannot trample each other's edits. Our [git worktrees guide](https://aq.dev/guides/git-worktrees-for-ai-coding-agents/) covers the pattern in depth. One honest caveat: worktrees isolate code state, not runtime state, so give parallel tasks separate dev-server ports and scratch data.

## Keep secrets out of the agent's reach

Assume anything the agent can read can end up in a prompt, and anything in a prompt leaves your machine. That assumption drives four habits:

- **Keep secret files out of the repository.** .env files stay gitignored, and the agent's worktree should hold development-scoped values, never production credentials. If a task does not need a credential, the credential should not be in the directory.
- **Scan before commit.** An open-source scanner like gitleaks as a pre-commit hook rejects commits that match known secret patterns, which matters more when a fast-moving agent is the one committing.
- **Turn on server-side push protection.** GitHub secret scanning with push protection blocks pushes containing detected secrets, catching whatever slips past the laptop.
- **Prefer references over values.** Production systems should pull secrets from a secrets manager at runtime; the agent's environment then holds nothing worth exfiltrating.

This is the control teams most often get half right (the .env file is gitignored but still sits readable in the agent's directory), so we keep a dedicated guide to [keeping secrets out of coding agent prompts](https://aq.dev/guides/keep-secrets-out-of-coding-agent-prompts/).

## Use the guardrails the agent CLIs already ship

The major CLIs now have real permission systems, and most teams simply never configure them. As of October 2026, re-checked on each vendor's documentation: Claude Code asks before file edits and shell commands by default, supports allow and deny rules for specific tools and commands, and ships a sandboxed Bash tool (off until you enable it with the /sandbox command or the sandbox.enabled setting) whose boundaries the operating system enforces (Seatbelt on macOS, bubblewrap on Linux and WSL2; native Windows runs commands unsandboxed). Inside that sandbox, commands write only to the working directory, a per-user temp directory, and directories you have explicitly added; network traffic goes through a local proxy whose allowed-domain list starts empty, and the first command that needs a new domain triggers an approval prompt. One scope caveat the docs are upfront about: the sandbox covers shell commands only, while file tools, MCP servers, and hooks run outside it under the regular permission rules. OpenAI's Codex CLI has three sandbox modes (read-only, workspace-write, and danger-full-access), enforced by Seatbelt on macOS and bubblewrap on Linux and WSL2. In workspace-write, the default posture for local work, writes stay inside the workspace, network access inside the sandbox is off unless you turn it on in config, and editing files outside the workspace or running commands that need the network escalates to an approval prompt; danger-full-access removes the filesystem and network boundaries entirely and belongs nowhere near a machine holding real credentials.

The pattern holds across the rest of the field. Cursor's CLI configures allow and deny lists over shell, file, and web-fetch actions plus a sandbox for shell commands with filesystem and network controls, and Cursor's own docs are direct that the allowlist is best-effort rather than a hard security boundary. OpenCode sets each tool to allow, ask, or deny in its opencode.json permission config, takes pattern-level rules for individual shell commands, and denies reads of .env files by default. For a deeper treatment of how these boundaries work and where each one ends, see [coding agent sandboxes explained](https://aq.dev/guides/coding-agent-sandboxes-explained/) and [coding agent permission modes explained](https://aq.dev/guides/coding-agent-permission-modes-explained/).

Two rules of thumb: run the strictest mode that still lets the task proceed, and never grant blanket auto-approval on a machine that also holds credentials you care about. Filesystem and network isolation matter together; an injected agent that can read a secret but not reach the network cannot exfiltrate it. And the looser the mode you choose, the smaller the blast radius has to be: full-auto belongs in a disposable worktree on an isolated machine, never in your primary checkout.

## Review agent PRs like a human wrote them

The controls above bound what an agent can touch. What actually ships is decided in review, and the industry's current habit is worrying: a July 2026 [LeadDev analysis](https://leaddev.com/ai/ai-coding-agents-kill-team-collaboration) of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. One person prompting, merging, and vouching for the same change is [self-review](https://aq.dev/self-review-problem/) with extra steps.

The fix is policy, not tooling: agent PRs get a reviewer who did not drive the session, held to the same standard as human code. We keep a dedicated guide to [reviewing pull requests from AI agents](https://aq.dev/guides/reviewing-pull-requests-from-ai-agents/), and for the session itself (the prompts, corrections, and abandoned paths behind the diff) a [session review checklist](https://aq.dev/guides/session-review-checklist/).

## Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Most of this guide's checklist is AQ's default shape rather than something you assemble. Credentials stay per user: each engineer connects the CLIs with their own Claude or OpenAI account (AQ never marks up usage on your own subscriptions) and their own GitHub auth, so agent commits and PRs carry a real identity. Every workspace gets its own isolated git worktree on a branch named ai/{id}-{slug}, with dependencies installed automatically and a one-click rebase onto main, so the one-task-one-worktree rule enforces itself. Agents run as real CLIs in persistent tmux sessions on your team's VM (there is no shared multi-tenant execution tier), and each PR an agent opens is tracked on its workspace.

The review habit gets easier too. Sessions stream live to the browser, so a teammate can open the workspace and watch the same terminal while the work happens instead of meeting the diff cold; typing into someone else's terminal requires the owner to approve a control request in one click. Workspace visibility is owner-managed: team-visible by default or private and shared with specific people. Pricing follows how you host: the Free plan is a personal sandbox machine AQ creates for one person, and the AQ Pro plan at $50 per user per month (promotional; standard $200) adds your whole team, VMs from your own cloud, and a dedicated always-on AQ-managed machine, with the rate locked for your first 12 months. Details on the execution and custody model are in [docs: security and isolation](https://aq.dev/docs/security-and-isolation/).

To be plain about it: AQ does not remove the need for fine-grained tokens, branch protection, or human review. It packages the isolation and makes the review part visible by default, which is the part most teams skip.

## Frequently asked questions

### What can an AI coding agent actually delete?

Anything its filesystem access and credentials reach: files in its working directory (including your uncommitted work, if you pointed it at your primary checkout), local branches, local databases, and, with a broad token, remote branches on any repository that token can push to. Contain it by pointing the agent at a disposable worktree instead of your main clone, scoping its token to one repository, and blocking force pushes on protected branches, so the worst case is a directory you can delete and recreate.

### How do I keep secrets out of an AI coding agent's reach?

Assume anything the agent can read can end up in a prompt. Keep production credentials out of the agent's working directory entirely, gitignore .env files and hold only development-scoped values in the worktree, run a secret scanner like gitleaks pre-commit, enable GitHub push protection server-side, and use the CLI sandboxes, which as of October 2026 keep network access off or behind an empty allowlist until you approve each domain, since an agent that cannot reach the network cannot exfiltrate what it reads.

### Who should review an AI agent's pull requests?

Someone who did not drive the session. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, which is self-review with extra steps. Passing CI is the floor, not the ceiling: route agent PRs to a second human and hold them to the same standard as human code.

### Is it safe to let an AI coding agent push directly to main?

No. Agents should work on branches, and your default branch should carry a protection rule or ruleset requiring a pull request, at least one approving review, and passing status checks before merge. With that in place, agent mistakes are contained to branches and every change that ships has had a human decision attached to it.

### What GitHub permissions should an AI coding agent have?

A fine-grained personal access token scoped to only the repository the agent is working on, with Contents and Pull requests permissions and an expiration date. Avoid classic tokens, which grant broad scopes across every repository you can access, and avoid shared bot tokens: per-user credentials keep the audit trail honest and make revocation surgical.

### Do git worktrees make AI coding agents safe by themselves?

They solve one problem well: filesystem isolation between tasks, so an agent's mistakes land in a disposable directory and parallel sessions never collide. They do not constrain credentials, network access, or what merges. You still need least-privilege tokens, branch protection, and review, and note that worktrees share runtime resources like ports and local databases.

---

About AQ: AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Start at [aq.dev](https://aq.dev/).