Security and Isolation: Where Agents Run, Whose Keys They Hold, Who Sees What

Published August 3, 2026 · by the AQ team

Using AI coding agents safely on your own repositories is mostly a custody question, not a model question. An agent is a process with a shell: it holds a working copy of your code, credentials that can push and open pull requests, and whatever network position its machine has. Whether that is safe depends on where the process runs, whose credentials it acts with, what separates one task from another, and who can see and steer it while it works. This page lays out those questions in vendor-neutral terms, then documents how AQ answers each one.

What actually needs securing

Strip away the product category and an agent session is a small stack of sensitive state:

• A full working checkout. Not just the repository history: uncommitted changes, generated artifacts, and anything the agent has read into its context.
• Live credentials. A git credential that can push, the agent CLI's own login, and any secrets the task needs (database URLs, API keys, tokens in environment files).
• A shell with network position. Whatever the machine can reach, the agent can reach: package registries, staging services, internal endpoints.
• The session itself. The running conversation and terminal, which is both a steering surface and the best audit record of what the agent actually did.

The failure modes follow directly. Throughout 2025 and 2026, security researchers repeatedly demonstrated prompt injection against coding agents: instructions planted in an issue, a pull request description, or a dependency's files steering an agent into reading environment variables and sending secrets outward. The defenses that hold up are structural, not behavioral: contain what a single session can touch, keep credentials scoped to one person and one task, keep destructive actions behind a human, and make the session reviewable by someone other than the person who launched it. You cannot prompt your way out of a custody problem.

Five questions to ask any cloud AI dev workspace

These questions sort the market quickly, and they are worth asking of your own scripts too:

1. Where does the agent execute? On the vendor's shared infrastructure, on a vendor-managed machine dedicated to you, or on a machine you own? This decides where your checkout, secrets, and build artifacts physically live, and who else's workloads share the hardware.
2. Whose credentials does the agent act with? A pooled service account breaks attribution: every commit, push, and API call looks the same in the log. Per-user credentials mean the trail names a person.
3. What separates one task from another? Two agents editing one checkout produce corrupted work long before they produce a security incident. Per-task isolation (in practice, one git worktree per task) is the difference between parallel work and interference.
4. Who can see and control a running session? Shadow agent use thrives in the dark. If sessions are visible to the team by default, review happens naturally; if control of a session can be delegated deliberately, nobody shares passwords to help a teammate.
5. Where does agent output meet human judgment? The safe merge path for agent work is the same as for human work: a branch, a pull request, protected main, and a reviewer. A platform should make that path the default, not an option.

On the last question, the industry's current baseline is weak. 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. Whatever workspace you choose, plan for a second person in the loop; a platform where sessions and PRs are visible to the team makes that practical instead of aspirational.

How AQ answers these questions

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. The rest of this page is AQ's answer to each question above, stated concretely.

Where agents execute: your team's machine, no shared execution tier

Agents in AQ run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser. There is no shared multi-tenant execution tier: your agents do not run on servers that also execute other customers' workloads.

The two plans are two ways to own that machine. On the Free plan you bring your own VM and pay only your cloud provider; the full product runs against it. On the Team plan ($100 per user per month promotional, standard $200, billed monthly, rate locked for your first 12 months) AQ manages a dedicated always-on VM for your team in its own isolated network. Either way, the checkout, the credentials, and the shell live on a machine that belongs to exactly one team. Our runners and infrastructure page covers the execution layer in more depth.

Credentials: per user, never pooled

AQ does not sit between your team and the model providers with a shared key. Each engineer connects the agent CLIs with their own login (your own Claude or OpenAI account), and AQ never marks up model usage. GitHub access is per user too: when an agent commits, pushes, and opens a pull request, it does so with the credentials of the person driving that workspace, so the repository history and the PR trail name a real teammate rather than a bot account everyone shares. Offboarding follows the same lines: one person's access is one person's access.

Isolation between tasks: one git worktree per workspace

Every workspace gets its own isolated git worktree on its own branch (ai/{id}-{slug}), with dependencies installed automatically and a one-click rebase onto main when the trunk moves. Two agents working the same repository never share a checkout, so a half-finished migration in one task cannot bleed into another, and abandoning a workspace abandons its branch without touching anything else. Workspaces documents the full lifecycle.

Visibility and control: owner-managed, delegated in one click

Every session in AQ is a live terminal streamed to the browser, which makes the session itself the review surface: what the agent is doing is what anyone with access sees. Who has that access is the workspace owner's decision. A workspace is either team-visible or private, and a private workspace can be shared with specific people.

Control is delegated, never taken. Teammates who open a shared workspace watch the same live session; typing into someone else's terminal requires the owner to approve a control request, which they grant in one click, and the owner keeps their own input the whole time. That replaces the two bad patterns teams fall into otherwise: shared SSH keys, and screen-sharing a terminal nobody else can operate.

The same posture extends outward. Live dev-server previews have shareable links that work without an account for viewing, so showing a stakeholder the running app never means granting repository access. Comments pinned on the preview can be sent to the agent as prompts; outside reviewers comment via a review link after a quick email sign-in, without attachments.

Where agent output meets human judgment

Agent work in AQ ends where team review begins: agents commit, push, and open pull requests, and every PR is tracked on its workspace. Branch protection on main stays your repository's job and keeps working exactly as it does for humans, because agents arrive through the same door: a branch and a PR. Because sessions are visible, a reviewer can go one layer deeper than the diff and read the session that produced it: the prompts, the corrections, the paths abandoned along the way.

Operating the machine

A dedicated machine is only a security property while it is healthy and observable. AQ ships the operational layer: the installer runs preflight checks before the first workspace, runner health is visible in the product itself rather than only over SSH, and an aq-runner doctor command diagnoses a broken host from the machine's side.

The questions and AQ's answers at a glance

If your evaluation of a cloud AI dev workspace starts with these five questions, you will eliminate most of the risk before writing a policy document. AQ's design goal is that every answer is the conservative one by default.