A sandboxed agent environment for every tenant

A sandboxed agent environment is defined by what is absent

Sandboxing usually means building a cage around a machine that has everything on it. We do the opposite: the workstation never receives production data, long-lived keys, or another customer’s code, so there is very little on it worth reaching in the first place.

What it does have is scoped to one tenant and one run: the credentials expire with the run, and the machine only ever holds the customer it was bound to.

One workstation per tenant, never shared

The workstation is a machine TaskShipyard runs, not one in your own cloud account. It binds to one tenant the moment it claims work and stays that tenant’s for the rest of its life. Two customers never share a workstation, a checkout, or a database, and a workstation that finishes a feature keeps it until the work lands.

• One repository checkout, on one branch, for one feature
• A local database reset from your migrations at the start of the run
• An isolated cloud stage per workstation, deployed into your own AWS account through a role you grant
• One-hour, dev-scoped credentials (never production)

Credentials that expire on their own

The agent gets a GitHub token restricted to the one repository the run touches, one-hour credentials from the role you granted (limited to your development account), and nothing that outlives the run. The only thing that talks to our control plane is a per-run token scoped to that run alone. The agent itself cannot reach it.

What autonomous coding agents can and cannot reach

It can read and write the branch, run your stack, query its own database and deploy its own cloud stage. It cannot deploy to production, cannot see another tenant, and cannot keep any of it once the run is over.

Questions we get asked

Where does my source code live during a run?

On the workstation, which is TaskShipyard infrastructure rather than your own cloud account. It holds a checkout of the one repository the run touches, it is bound to your tenant alone, and no other customer ever lands on it. What leaves is the pull request you were going to push anyway.

What happens to the machine after the run?

It stays yours. The workstation holds the preview, stops when it goes idle so it costs nothing, and wakes for your next run. It is never handed to another customer, and it is destroyed when your account no longer needs it.

Can the agent deploy to production?

No. Runs are pinned to a per-workstation development stage, and production deploys are a separate, human-triggered path.