LindiYour product never leaves your repo.
Lindi edits the code you already have, on a branch, and asks for a review. The questions a security reviewer asks are mostly answered by that one sentence — the rest is below, and so is what we do not claim yet.
Most of the answer is the shape of it.
A tool that keeps a copy of your product spends its life defending that copy. Lindi does not keep one.
- Your repository
A branch, and a pull request.
Lindi works on a branch of your repository and opens a pull request against it. It does not push to main. What merges, and when, is decided by your review — on every plan.
- No second copy
There is no other store of your product.
The canvas edits the components already in your codebase. There is no separate design-file database holding a copy of your screens — which means there is no second place for it to leak from, drift in, or need deleting.
- Your review
Nothing lands without a reviewer.
A change made by a designer, and a change made by the agent, arrive the same way: a diff, a description, a request for review. Your merge rules are the only rules.
Who may edit, and who only looks.
- Workspace roles
One role per person, resolved server-side.
Every user holds exactly one role, and their permissions come only from that role’s grants — read fresh from the database on the server, never trusted from the client.
- File access
Owner, editor, viewer.
Sharing is per file. A viewer sees and cannot change. Someone who wants to edit raises a request, and an owner approves or declines it — access is granted deliberately, not by link.
- Attribution
Every change has a name on it.
Design edits and merges sit in one record, in order, attributed — including changes the agent made, which carry the name of the person who asked for them.
It can be switched off, and it cannot merge itself.
The two questions every organisation asks about an AI feature, answered in the product rather than in a policy document.
- The switch
An admin can turn the agent off.
AI access is a policy on your organisation, not a per-user preference. It can be disabled for a team, a workspace, or the whole organisation, and the setting is versioned so a change is visible.
- Its reach
The file that is open. Nothing else.
In Build and Code the agent works on the file you have open and the branch it is on. It has no route to your other repositories, and no way to merge its own work.
- Its output
A diff you read before you keep it.
Every change the agent makes is shown as a diff on the branch, with Keep and Undo, before anything leaves. If you never keep it, nothing happened.
Our cloud, or yours.
- Managed
Our cloud.
The default: we run it, you sign in with email and password or with Google, and your work lives on branches of your own repositories.
- Whitelabel
On-prem, or your cloud.
For teams whose product cannot leave the building. The same canvas, hosted where you say, trained on your conventions, with tools removed or added to fit how you work.
Lindi is pre-release. Here is what that means.
We have not completed a SOC 2 or ISO audit, and we are not going to put a badge on this page before we have. Everything above describes how the product is built — the branch, the review, the roles, the switch — not an audited guarantee about how it is operated. Those are different claims and they deserve different words.
If you are evaluating Lindi for a team where that distinction matters, ask us directly. You will get a straight answer about where we are, what is in progress, and what we cannot do yet — and if the honest answer is “not yet, for you”, we would rather say it now than in month three.
Run it on your terms.
Lindi is pre-release. Get in line, or talk to us about hosting it where your product lives.