Before you grant repository access, you deserve exact answers.
Echelar reads your repository and does its work in an isolated sandbox — this page lists exactly what it can and cannot touch. A person on your team approves every merge, every deployment, and every operating change. Everything an agent does is recorded, so you can check each of these claims against the record.
What agents can never do
These boundaries are architecture, not policy. An agent cannot break a rule when the tool to break it does not exist.
- Merge or deploy
- No merge or deploy capability exists. Every change comes back as a pull request, and a person on your team performs every merge and every deployment.
- Enable anything
- Agents can author Automations, Skills, and Agents — as drafts. Every draft lands disabled, and no tool exists that lets an agent enable one. Only an authorized person enables a draft, and it affects future Sessions only.
- Write code as the Reviewer
- The PR Reviewer is read-only. It reads the diff and files findings; it never edits code. When it requests changes, a person can start a separate fix Session — from the Reviews page, or automatically by adding the echelar label to the pull request — and the resulting commit goes back through review.
- Fix an incident without your go-ahead
- Incident work is recommendation-first. Echelar investigates, posts a cause and a recommendation, and waits for a person's confirmation before changing code.
- Move your Linear board on its own
- By default Echelar leaves issue states alone: progress streams as Agent Session activity on the issue, and the pull request attaches to it. If you want the board to move, you author that as an Automation and a person enables it.
Where code executes
Each Session runs in its own isolated sandbox with the repository checked out there for the duration of the work, and torn down when the Session ends. Data and access are scoped to your organization at every layer — one organization's Sessions, credentials, and records are never visible to another.
To be plain about the boundary: we do not claim execution stays entirely inside your infrastructure. Your code is present in Echelar's sandboxes while the work happens. If that boundary matters to your threat model, ask us about it directly.
Your credentials stay yours
You bring your own model keys. Echelar stores them encrypted, scoped to your organization, and uses them only for your organization's work.
GitHub access comes from your organization's own installation of the Echelar GitHub App, on the repositories you choose — nothing is pooled across customers. Access for a single task is short-lived and narrowed to that task: agents read. A write-capable token exists only for an automated fix Session, scoped to one repository and bound to one pull request's branch.
Access control
Each person belongs to your organization with a role — owner, admin, or member — and acts within it. Owners and admins decide what gets enabled, who joins, and which integrations exist.
Every record Echelar keeps is organization-scoped, and the isolation is enforced in the database itself — it does not depend on application code remembering to filter.
Everything leaves a trail
Every Automation fire writes an audit record with a match trace and the exact prompt it sent. Events that matched nothing are recorded at the event level, payload kept, so they can be replayed.
Every session shows its tool calls, its changed files, and the evidence it produced. When a result reaches review, the trail arrives with it.
What we don't claim
- We do not hold a SOC 2 certification today. When that changes, this page will say so plainly.
- CI verification certifies that the required checks passed at one exact commit. It is evidence about that commit — not a warranty that the software is correct.
- The demonstrations on this site use authored, labeled data on a fictional repository. They show real product behavior, not customer records.
- We welcome your security questionnaire. Send it early — before you connect anything.
Ask us the hard questions.
Bring your security team, your questionnaire, and your edge cases. You'll talk to the founder, and you'll get an exact answer or an honest “not yet.” Questions go to the founder, Mohamed Ettaibi, who reads every one.