Security
AI developer tools and the data boundary
The privacy discussion around developer tools is often reduced to a single decision: may the team use AI? That category is too broad for a useful answer. One tool may search entirely locally, another may send selected changes to a model, and another may retain sensitive conversation history on the workstation. These activities carry different risks. Combining them under one label makes it harder to define either a meaningful permission or an appropriate restriction.
Examine the specific operation
In my open-source project commitell, Git changes become commits with either model-written messages or deterministic messages generated locally. Offline mode produces a conservative message from local file status without sending a model request. A dry run shows the plan without changing Git or publishing anything. These choices make distinct data decisions visible within the same tool rather than treating every use as one undifferentiated AI workflow.
The word offline still needs to refer to a particular step. Generating a commit message locally does not prevent a later publication from sending the commit to a remote repository. The selected files are part of that decision too. Ask not only whether a tool has an offline mode, but which later actions can still transfer information to other systems and whether those actions require separate approval.
A scanner helps, but it does not guarantee
commitell scans locally for likely secrets before flagged content goes to a model provider. In non-interactive use, a suspected secret causes the operation to fail closed unless explicitly overridden. This is a specific control at a specific boundary. It is not a complete secret-management system, and it cannot determine every piece of business information that your organisation regards as confidential independently of recognisable credentials.
Contract wording, an unreleased product feature or an internal rationale can be sensitive without looking like a password. A clean scan should therefore not become automatic approval for all the content. The responsible process must decide what may be transmitted in the first place. Technical detection supports that decision; it does not assume the organisational or legal responsibility for making it, nor does it establish that the recipient is appropriate.
Local data still needs protection
In my open-source project ichnora, decisions and working context are stored locally within a project scope for coding agents. Retrieval requires neither model calls nor a fallback network service. Collection and automatic recall are off by default, and historical import requires preview and confirmation. That makes retention an explicit choice rather than an unnoticed side effect of every session in which an engineer uses an assistant.
Nevertheless, a transcript can remain sensitive after recognised credential patterns have been redacted. Local storage does not mean other processes running as the same user are technically excluded. Application policy for a local communication channel is not isolation between those processes. Procurement should therefore consider local access rights, retention and deletion as well as external cloud providers. Avoiding a network transfer removes one question without answering all the others.
Research and model access cross different boundaries
My experimental open-source project tentaflake-research provides a separate service for public web research and saved evidence. Provider credentials do not sit with the client. Jobs, budgets and provenance are handled by the service. Paid providers and optional capabilities require operator configuration. None of this establishes complete isolation or comprehensive protection against manipulative material retrieved from external sources. Those limits remain part of an honest description of the system.
The separation helps make the questions more precise. Which query goes to which search provider? What is retrieved and stored locally? Which parts of the evidence are subsequently given to a model? Public sources do not automatically make the organisation's search intent harmless. A query can disclose confidential plans even when the requested information is publicly available. Research therefore deserves an explicit data-flow assessment rather than a blanket assumption of safety.
Policy must match the actual provider
For OpenRouter requests, commitell states particular privacy requirements; other providers have their own terms. Regional routing is not a data-protection certification. A retention setting does not automatically answer every question about metadata or account-wide rules either. A technical option should carry only the promise supported by the provider and configuration actually in use, rather than a broader assurance inferred from a convenient label in the interface.
I would anchor procurement in a simple account of the data flow: input, recipient, timing, retained copies and responsible owner. Include a local alternative when transmission cannot be approved, together with an honest description of its limitations. Not every tool needs to be suitable for every category of data. A narrower, understandable boundary is often more responsible than a comprehensive promise whose conditions nobody can clearly explain.
Questions for your team or vendor
- Which source material, changes or conversation history leave the workstation during each specific action?
- Which later steps can publish data even when the preceding processing happened offline?
- Which confidential content cannot be recognised by the secret scanner, and who approves its transmission?
- What is retained locally, for how long, and who can access it under the same user account?
- Which provider terms actually apply to content, metadata, retention and regional processing?
- What local alternative is available when a model or research request cannot be authorised?