AI coding assistants are getting incredibly good. Tools like Claude Code, Cursor, and Windsurf can explain unfamiliar code, navigate large codebases, generate boilerplate, and often solve problems faster than a traditional web search.
But there is a problem that many engineering teams are quietly struggling with: How do you use cloud-based AI tools without exposing proprietary source code?
Imagine asking an AI assistant to help refactor a critical module. To get a useful answer, you need to provide context. That context may contain:
- Proprietary algorithms
- Customer-specific workflows
- Internal APIs
- Database schemas
- Business rules accumulated over years
- Naming conventions that reveal how your systems work
For many organizations, that risk is enough to stop the conversation before it even starts. In many cases, the concern exists even when the AI provider offers enterprise-grade guarantees, private deployments, or strong privacy commitments.
As a software manager working with large proprietary codebases, I kept running into the same dilemma:
- Developers wanted the productivity gains of AI-assisted development.
- The company wanted to protect its intellectual property.
Both positions were perfectly reasonable. The challenge was finding a middle ground.
What If Sensitive Code Never Left the Network?
Instead of asking whether AI coding assistants should be allowed, I started asking a different question: «What if the sensitive parts of the code never left the network in the first place?» Could developers still benefit from AI assistance if the model only saw a sanitized version of the code?
That idea eventually became Kiri.
The Core Idea
Kiri is an open-source, on-premises proxy that sits between AI coding tools and cloud LLM providers.
Before a request reaches the model, Kiri intercepts it locally, identifies proprietary implementation details, and replaces sensitive information with placeholders. The sanitized request is then forwarded to the AI provider, and the response is returned to the developer.
For example, instead of sending your raw business logic:
// Before Kiri
public static decimal CalculateDiscount(Order order) {
var tier = _tiers[order.Customer.Tier];
return Math.Min(tier.Base + order.TotalUnits * tier.PerUnit, tier.Cap);
}
The external model receives:
// After Kiri
public static decimal CalculateDiscount(Order order) {
// [PROTECTED: implementation is confidential]
}
The overall structure of the problem remains understandable, while the implementation details do not. The goal is not perfect secrecy. The goal is reducing the amount of sensitive information that leaves the organization while preserving enough context for the AI assistant to remain useful.
The Hard Part Wasn't Building the Proxy
The most interesting challenge turned out to be something else entirely: How much information can you remove before the AI stops being useful?
Remove too little and you risk exposing information you care about. Remove too much and the model can no longer understand the problem. Finding that balance turned into a series of experiments.
In some scenarios, the model remained surprisingly useful even after aggressive redaction. In others, removing key information quickly degraded the quality of the answers. What I learned is that privacy is not a binary choice between "send everything" and "send nothing." There is a large and mostly unexplored design space in between.
Why Not Just Use Enterprise AI?
This is a reasonable question. Many AI providers already offer enterprise agreements, private deployments, and data-retention guarantees. For some organizations, that is probably enough.
For others, legal requirements, internal policies, customer contracts, regulatory concerns, or simple risk aversion still make external code sharing difficult. Kiri is not intended to replace enterprise offerings. It is an attempt to explore another option.
Measuring Instead of Guessing
One unexpected result of the project was the benchmark itself. I quickly realized that discussions about AI privacy often become theoretical. Everyone has opinions, but very few teams have a way to quantify the trade-off.
One thing I wanted from the beginning was a way to measure the impact instead of endlessly debating it. Most privacy tools make claims; Kiri lets you measure.
The project includes a benchmark tool that can run directly against your own repository. Rather than trusting my assumptions, you can test the approach on your own codebase and see what happens.
The benchmark helps answer questions such as:
- How much code is being redacted?
- Which identifiers remain visible?
- How aggressive should the redaction strategy be?
- How much structural context is still preserved?
I found this far more useful than theoretical discussions about AI privacy because every codebase is different. A strategy that works well for one project may be completely inappropriate for another.
Why Open Source?
I released Kiri as an open-source project because I suspect many teams are facing the same dilemma. Developers want the benefits of AI-assisted development, while security, legal, and engineering leadership want stronger guarantees around intellectual property.
Those goals are often presented as mutually exclusive, but I'm not convinced they are.
Questions for the Community
I'm genuinely curious how other organizations are approaching this problem today:
- Are AI coding assistants completely banned?
- Are you relying on enterprise agreements?
- Are you running local models?
- Are you building internal gateways?
- Are you taking a completely different approach?
I'd love to hear what has worked for you — and what hasn't.
Try It Yourself
If you're curious, don't take my word for it. Run the benchmark against your own repository and see how much information can be removed before the AI starts losing context. The results surprised me more than once.
Kiri is fully open source under the MIT license and includes documentation, examples, and the repository benchmark tool.
- 📂 GitHub: PaoloMassignan/kiri
- 🌐 Project Page: [kiri]https://paolomassignan.github.io/kiri/)
Top comments (0)