Your code should stay on your machine because every copy of a repository outside your control is a copy you must inventory, protect, contract for, and eventually delete. Local-first AI development means the orchestration software, the repository, the worktrees the agents work in, and the plans, memory, and logs they produce all live on the developer's computer. The only data that leaves are the prompts and diffs sent to the LLM API your team chose, and the git operations to GitHub. Ivy Tendril is built this way. This article explains what that means in practice and answers the questions a security or compliance lead will ask.
What local-first means here
Ivy Tendril is a desktop application for macOS, Windows, and Linux, built by Ivy Interactive AB in Stockholm. It runs on the developer's machine, or headless on a server you control with tendril --web. When it orchestrates a coding agent such as Claude Code, Codex CLI, Copilot CLI, Gemini CLI, or OpenCode, the agent process also runs locally, in a git worktree on the local disk.
Four facts follow from this.
- The repository is never uploaded. Tendril works with the checkout that is already on disk. Worktrees for parallel plans are created when execution starts and removed after merge.
- Network calls go to two places. The LLM API your team configured, and GitHub for issues and pull requests. Tendril does not proxy your traffic through Ivy's servers, and Ivy does not train on your code.
- Plans, memory, and logs are local files. Every plan, every promptware memory entry, and every execution log is on a disk you control.
- Credentials stay with you. You bring your own API keys. They are sent only to the provider that issued them.
Hosted agents compared with Ivy Tendril
A hosted coding agent runs in a vendor's cloud environment. To do its work, it clones your repository into that environment, runs commands there, and stores the session, including your code and the agent's output, on the vendor's infrastructure. This is a workable design for some teams, but it changes what a security review has to cover. The table compares where each kind of data goes.
| Data | Hosted agent | Ivy Tendril |
|---|---|---|
| Source code | Cloned into the vendor's environment; retention set by the vendor | Stays on the developer's machine or your own server |
| Prompts and diffs | Sent to the vendor, then to the model provider the vendor selected | Sent directly to the model provider your team selected |
| Execution logs | Stored by the vendor; access governed by the vendor's policies | Local files, readable and deletable by you |
| Plans and agent memory | Stored by the vendor | Local files under your control |
| API credentials | Held by the vendor, often under the vendor's own provider account | Your own keys, configured locally |
| GitHub access | The vendor's app or token | Your GitHub credentials, used from your machine |
The practical difference is the number of parties. With a hosted agent, your source code has at least two processors: the agent vendor and the model provider. With Tendril, it has one: the model provider, and only for the portions of the code that appear in prompts. A comparison with one hosted agent is in Ivy Tendril vs Devin.
The questions a security team asks
Where does the code go?
The repository stays on disk. The parts of it that leave are the file contents, diffs, and instructions the agent includes in prompts to the model provider. That traffic goes from the developer's machine to the provider's HTTPS endpoint. No copy is made on Ivy's infrastructure. You can confirm this by inspecting outbound connections from the Tendril process on a machine behind an egress firewall: the destinations are the provider's API and GitHub.
Who can read the logs?
Whoever has access to the disk, and no one else. Execution logs, plan history, and promptware memory are files. They can be included in a backup, indexed by an internal audit tool, or deleted to satisfy a retention policy, without asking a vendor. For an incident review, the logs show every command the agent ran and every file it changed, per plan and per job.
Which subprocessors are involved?
For the desktop application: the model provider you chose, and GitHub. Ivy is not a processor of your source code, because it never receives it. Your data processing agreement with the model provider covers the prompts and diffs. Confirm each provider's terms on training and retention for API traffic; they differ between providers and change over time. For team features on Pro and Enterprise, any additional services are stated in the agreement for that plan, and on-prem Enterprise hosting keeps them inside your own network.
Can we pick an EU provider?
Yes. Tendril is bring-your-own-keys, and the model provider is a configuration setting. The documented providers at the time of writing include Anthropic, OpenAI, Google, OpenRouter, Vercel AI Gateway, Cloudflare, Scaleway, NVIDIA, Opper, Z.ai, and the EU providers Berget and evroc. A team that needs EU data residency for GDPR reasons can route prompts to Berget or evroc and never send code to a US endpoint. The workflow does not change with the provider. Because the agent and model can be chosen per plan, a team can also use an EU provider for a repository that contains personal data and a different provider for the rest.
Can we self-host?
The desktop application already runs entirely on hardware you control, and tendril --web runs it headless on a server in your network. Enterprise adds on-prem hosting of the team features, SSO/SAML, multi-tenant setup, verification imports from CI, enterprise analytics, and support. Pricing for Pro ($59 per user per month) and Enterprise is on the pricing page.
Compliance considerations
Local-first does not make compliance automatic, but it reduces the scope of each question. Some examples, in general terms and at the time of writing:
- GDPR. If the repository contains personal data, the model provider is the processor to contract with, and choosing an EU provider addresses residency. Tendril itself does not process the data on Ivy's behalf.
- SOC 2 and ISO 27001. Auditors ask for evidence of access control and change management around production code. Local plans, logs, and the two human sign-offs, on the plan and on the diff, give a per-change record of who approved what, stored where your other evidence is stored.
- EU AI Act. Obligations depend on how a system is classified and used. A local, per-change record of what the agent was instructed to do, what it did, and who approved the result is useful evidence for the human oversight and record-keeping duties that apply to some uses. Consult counsel for your specific case.
How to start
Install the desktop application, add an API key for a provider your security team has approved, and run a plan on a non-sensitive repository first.
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
On Windows, use irm https://cdn.ivy.app/install-tendril.ps1 | iex. Ask your network team to record the outbound destinations from the Tendril process during the pilot; the list should contain the provider's API and GitHub. Tendril is free and source-available under the Functional Source License (FSL-1.1-ALv2), so the code that handles your repository can be read before it runs.
Frequently asked questions
Does Ivy ever see our code?
No. Tendril does not proxy traffic through Ivy's servers, and Ivy does not train on your code. The desktop application makes network calls only to the model provider you configured and to GitHub.
Can we use a model we host ourselves?
Provider support is documented per provider. The documented options at the time of writing include direct providers and gateways such as OpenRouter, Vercel AI Gateway, and Cloudflare. Check the model provider documentation for the current list.
What does the license allow?
Tendril is source-available under FSL-1.1-ALv2, which permits use and modification for your own purposes, with limits on offering it as a competing service. Read the license text for the exact terms.