AI coding agents and remote build execution (RBE) are a natural fit. Agents iterate fast: run a build, watch it fail, fix it, then rebuild. Everyone always asks if their executor fleet can keep up. Almost always, they find that it can. After all, RBE was built exactly for these kinds of parallel, high-frequency builds.
The real question is should agents have access to that infrastructure at all?
When an AI coding agent runs on your RBE cluster, it’s working in the same environment as your engineers, with access to the same executor pool, the same secrets, and the same artifact cache your release builds depend on.
Your RBE cluster was designed with human engineers in mind. Someone authenticated, accountable, with a job title and an oncall rotation is lurking on the other end. An agent doesn’t have any of that. Yet most teams have quietly handed it full CI-level trust anyway.
We ran into this with a healthcare technology company. Their fix: a second Aspect Workflows deployment that runs nothing but AI coding agents, isolated from their human CI behind its own network boundary, with its own access audit trail.
## When agents cross the trust threshold
When you’re a small team, running a handful of agents occasionally, sharing a cluster is no big deal. The risk is low because the scope is narrow. It’s not fine when you realize your agent has unfettered access to infrastructure that’s not set up to be audited that way.
There are a few concrete signs it’s time to isolate your agents:
* **Agents are running non-stop:** Your nightly batch job touches the cluster for an hour then clocks out. An agent loop, on the other hand, is active during business hours. It spawns builds on every commit and hangs out on your executor fleet all day.
* **Build load is blending:** Your human CI builds and agent retry loops compete for the same executors. When agent-driven builds gang up on your human builds and push them back in the queue, it’s not an executor problem. It’s actually two workloads that were never meant to share a queue — you just found out the hard way when your PR is stuck behind an agent’s umpteenth retry.
* **Your audit trail can’t tell the difference:** Your logs show that a build ran on executor X. They don’t tell you whether X was a person or an agent (at least not without additional tools). Do you know what an agent touched last week? Or even two days ago? That gap in logging is a compliance nightmare in regulated environments and a forensic dead-end anywhere else.
* **Compliance isn’t reactive:** Some teams have security conversations after something breaks or an audit asks a question you can’t answer. For teams in certain industries (healthcare, finance, defense, cybersecurity) compliance comes before an incident. Either way, the need will arrive. And the infrastructure you’ve been running on was never built to answer those questions.
## Blast radius: what an agent can actually get its hands on
The trust argument is abstract. The blast radius is concrete. When your agent is unruly, gets compromised, or just operates with the speed and energy of an overcaffeinated toddler, here’s what it can reach on a shared cluster.
### The artifact cache
Bazel’s remote cache is keyed by action hash. An agent looking around a large change set generates action hashes across a wide slice of the build graph. Every query fills the cache’s hot tier with entries your engineers will probably never need and pushes out the ones they probably do. A build that should’ve been fast turns into a partial cold rebuild, not because of any changes in the code, but because an agent went on a querying quest an hour earlier. That’s a correctness-adjacent problem: your cache is now shaped by how agents wander, not by how your team actually builds.
Without any changes to infrastructure you can create separate cache namespaces, set with `--remote_instance_name` in your Bazel config. Your human CI reads and writes to one namespace and agents get their own. Take it even further and tier your storage: fast, low-latency storage for humans and a cheaper tier for agents, where a cache miss costs less because the agent rebuilds anyway.
### The executor pool
The agent retry loop is a tight one: build, fail, fix, rebuild. Enough of those running at once and your executor pool is at 100%, leaving your human CI waiting in line. The fix is queue prioritization: human builds get a dedicated capacity reservation, agent builds get burst capacity. Most RBE platforms support priority classes, but somebody has to configure it. It doesn’t happen by default. On a dedicated cluster, this doesn’t come up, because agents physically can’t reach the pool human builds depend on.
### The secrets those executors can reach
RBE executors have access to things like API tokens, signing keys, registry credentials, and other secrets your build actions ask for. An agent running wild on the same fleet has the same reach as your engineers. If you haven’t explicitly scoped what an agent can touch, you’ve implicitly given it access to all the things. You ask it to "fix the failing test" and it queries the whole graph, hitting targets that touch credentials, and burning signing resources, all without leaving a trace that tells you it wasn’t a person.
A dedicated cluster means two IAM configurations instead of one, and the agent one is short. Access to the cache. That’s it — no signing keys, no registry writes, nothing that touches a deploy. The scope is explicit because you made it that way, not because you’re hoping no one asks.
## Compliance: the audit trail problem
For a healthcare technology company, the whole thing didn’t start as a performance conversation. It started with an audit.
When it comes to regulated industries the concerns are specific: who had access to the executor that ran this build, and what could they reach? On a shared cluster, the honest answer is "whoever was in the CI IAM policy at the time, including any agents that happened to be running." That just doesn’t satisfy an auditor and it doesn’t tend to hold up in a security incident review either.
A dedicated agent cluster makes the audit trail clean. Every action lands in your cloud’s native audit log, tagged to that cluster automatically. No one has to build a special agent-tracking dashboard. Agent activity is visibly separate from human activity because there are two clusters, not with a tool that’s cobbled together. When an auditor asks what the agent accessed, the answer is bound by what that cluster was allowed to reach and that’s a short list.
This carries over to data residency. If you have requirements for where code artifacts live or get processed, an air-gapped or single-region Workflows deployment keeps agent build data inside the same jurisdictional lines as everything else, regardless of what the agent is doing.
As a practical side benefit, it’s simpler to reason about. CI executors need write access to your artifact registry, signing keys for release builds, and deployment credentials. Agents don’t typically need any of that. Scoping those permissions differently on one cluster is awkward. With two clusters, there are two policies, and the agent policy is short.
## Cost attribution: governance follows isolation
Once you’ve split execution planes, you can actually see what agents cost. On a shared cluster, agent and human CI builds are a blended bill. You can watch the spend as agents become more active, but you can’t easily separate what drove it.
It’s easily fixed by tagging compute resources by workload. Compute resources in the agent cluster get a tag like `workload: agent`; human CI gets `workload: ci`. Most cloud billing dashboards already group by tag, so per-workload cost shows up without additional tooling. The same pattern works if multiple teams are running their own agent clusters — each team’s infrastructure cost is a separate line.
The more useful number is cost per unit of output rather than raw compute cost. For human CI that’s cost per merged PR or per successful build. For agents, it’s cost per accepted commit or cost per resolved issue. Those numbers take more manual work to pull together, but worth computing once to establish a baseline. Dedicated infrastructure adds a bit of fixed overhead, but it also makes the comparison honest. You can’t do that with a blended bill.
Chargeback models differ from team to team. Some teams bill agent infrastructure back to the team running the agents; others treat it as a shared platform cost. Either way, attribution only works if the workloads were separated at the infrastructure level. You can’t make a governance decision about agent adoption off a number that mixes two different things together.
## What this looks like in practice
The healthcare technology company runs two [Aspect Workflows](https://aspect.build/platform) deployments in their AWS account. One handles all their human CI. The other handles nothing but agent-driven builds, behind its own network boundary, with its own IAM policies and its own audit trail.
The agent cluster reads from the same cache the human CI fills, so agents aren’t starting from nothing every time. Writes go to a separate namespace, so they can’t step on your CI cache. Executor pools are separate. IAM policies are separate. Billing tags are separate.
Running two clusters costs the same operational overhead as one. Aspect engineers deploy and operate both either way. What the company walks away with is a compliance posture they can describe to an auditor and a trust boundary they can point to.
## Get your agents off shared CI
Everyone’s busy solving fast enough. We’ve got that part down. The trust boundary problem has been largely ignored. It’s the one that shows up in audits, in incident postmortems, and on the day an agent-driven build quietly touches a signing key it shouldn’t have.
Give agents their own Workflows deployment and their own execution plane: separate VPC, separate IAM, separate audit trail. It still reads from the same artifact cache your human CI fills. It just doesn’t get to write to it, or touch anything else.
If you want to see what this looks like for your infrastructure, [reach out and we’ll walk through it](https://aspect.build/request-demo).