A sandboxed agent environment for every tenant
The safest machine to give an autonomous agent is one that holds almost nothing. A TaskShipyard dev seat has your repository, a disposable database and credentials that expire in an hour.
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 seat 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 a single run — and it is thrown away afterwards.
One dev seat per tenant, never shared
A machine binds to one tenant when it claims work and keeps serving that tenant while it is warm. Two customers never share a seat, a checkout, or a database, and a seat 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 seat, so runs cannot trample each other
- 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, cloud credentials 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
- Does my source code leave my AWS account?
- The seat runs in your own account, and the checkout lives there. What leaves is the pull request you were going to push anyway.
- What happens to the machine after the run?
- It is released back to the pool and reset by the next run that lands on it. Nothing from your run persists on it.
- Can the agent deploy to production?
- No. Runs are pinned to a per-seat development stage, and production deploys are a separate, human-triggered path.