How to Safely Run AI Coding Agents on Your Own Repos

Published August 3, 2026 · by the AQ team

Running AI coding agents safely on your own repositories comes down to five controls: give the agent least-privilege credentials (a fine-grained token scoped to one repository, not your whole account), protect your main branch so nothing merges without a human, isolate each task in its own git worktree, keep secrets out of the agent's reach and out of the repository, and review agent pull requests the way you would review a stranger's. None of this requires new tooling: git, GitHub, and the agent CLIs already ship every piece, turned on before the first agent session rather than after the first incident. 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.

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 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.

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 August 2026: Claude Code asks before edits and commands by default, supports allow and deny rules for specific tools and commands, and offers an OS-level sandboxed shell (Linux bubblewrap, macOS Seatbelt) that enforces filesystem and network boundaries rather than relying on prompts alone. OpenAI's Codex CLI defaults to a workspace-write sandbox with network access disabled inside the sandbox, escalating to approval when a command needs to go beyond the workspace; its danger-full-access mode removes both boundaries and belongs nowhere near a machine holding real credentials.

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.

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 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 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, and for the session itself (the prompts, corrections, and abandoned paths behind the diff) a 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 model usage) 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 the full product on a VM you bring (you pay only your cloud provider), and the Team plan at $100 per user per month (promotional; standard $200) includes a dedicated always-on VM managed by AQ in its own isolated network, with the rate locked for your first 12 months. Details on the execution and custody model are in 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.