◧
Per-task sandbox
Every run gets a fresh, isolated environment. It is created for one task, has no access to any other task's state, and is destroyed when the run finishes.
Security
An agent is only as safe as its blast radius
The useful question about an autonomous engineer isn't whether it can be wrong — it will be, the same as any engineer. It's what the worst outcome of being wrong actually is. Here, it's a pull request nobody merges.
How a run is contained
⚿
Short-lived, scoped tokens
Git access uses a GitHub App installation token minted for the run and scoped to the repositories you selected. It expires on its own; nothing long-lived sits in the sandbox.
◎
Read-only where writing isn't needed
Cloud access is list, describe, get, and read-logs. PostHog and Figma are read-only. Vercel is read-only — Elisha can see a failed deployment, not create one.
⇥
Nothing merges itself
There is no code path in the worker that merges a pull request or pushes to a default branch. Human review is not a policy you can switch off; it's the only way a change lands.
▤
Encrypted credentials
Access and refresh tokens are encrypted at rest with a managed key and scoped to one organization. Disconnecting an integration deletes the stored grant.
◈
An auditable trail
Every run records what it was asked, what it decided, which files it changed, and which checks ran. The pull request carries the same summary in public.
Risk flags ride along, they don't block
Elisha keeps a checked-in table of risk categories — deleting records, touching auth, anything that reads as irreversible. A match doesn't freeze the task. It attaches a heads-up to the pull request and to the message announcing it, so the reviewer knows what to look at closely.
This is deliberate, and it replaced an earlier design that did block. Blocking guarded a step that couldn't cause the harm it named, and it guarded it on a prediction of what a change might touch. The review that matters already exists one step later, at the diff — where you can see what the change actually touched.
The table only grows when a person edits it, and it names risky things specifically: deleting records, not the word “delete”. A flag that appears on every card gets read as decoration.
Reporting a vulnerability
Email security@elisha.dev. We'll acknowledge within one business day. Please don't open a public issue for anything exploitable.
Data handling
What we collect and why is written out in the Privacy Policy. Customers processing personal data in the EU or UK should read the Data Processing Addendum, and the full list of third parties that ever touch customer data is on the sub-processors page.
Have a security question we haven't answered?
We'd rather answer it before you sign up than after. security@elisha.dev.