Skip to main content
Every architecture has a weak side. Ours are listed here because a buyer who finds one of these in week three of an evaluation has learned something worse about us than the gap itself.

Isolation is a container on your hardware, and the default is weaker

An agent’s step runs in a container with its own identity and its own credential volume — not as the login user of the machine. The caveat: the executor is configuration, and on some setups the host executor is still the default. A runner enrolled as container is refused rather than silently downgraded, specifically so no surface can claim isolation that is not happening — an earlier version of this product reported isolation it was not performing, and the refusal exists so that cannot recur. What follows for you: on a host-executor runner, a step runs with the privileges of the account that installed the runner. Put the runner on a machine you would be comfortable giving a contractor, not on an engineer’s primary laptop with production credentials in its keychain.

We cannot narrow the blast radius of your own credentials

Because we hold no repository credential, what the agent can reach is whatever the machine’s own logins can reach. We cannot scope it per-repository per-step, and we cannot revoke it — only you can. If you want that scoped down, scope the machine: a dedicated account with access to the repositories the agent is meant to touch, and nothing else.

Tool logins go stale, and that looks like failure

A gh login or a runtime subscription that expires shows up as work not happening. We surface this as tool health rather than leaving you to infer it from a run of unexplained failures, but the honest position is that the class of problem exists because the credentials are yours and their lifecycle is not ours to manage.

A locked laptop is a stopped agent

The runner needs a login session on macOS. A machine that reboots and sits at the FileVault prompt leaves the agent down until somebody unlocks it. This is the most common support call we expect, and it is a property of the deployment model rather than a bug we are about to fix.

The demo runner cannot open pull requests

If you are evaluating on the runner we operate rather than one of your own: it has no developer’s gh login and no runtime subscription, so it can show triage, briefing, dispatch, execution and verification — the whole loop up to a diff — and then stops. Watching a real pull request open needs a real runner on your hardware. We would rather you read that here than hit it at the last step of a trial.

Retention

See Retention. Zero data retention with our classification processor is not in place on day one, deliberately.