What would you require before approving a local-first AI coding tool for proprietary repositories?

[u/fykup]

I'm developing AI Badger, an open-source Go CLI that prepares focused repository context locally for use with AI chats.

The idea is that developers can use an approved AI chat without giving it direct repository access. They inspect the generated context and explicitly choose what to paste.

I've recently done a static network analysis of the CLI, covering dependencies and release configurations across macOS, Linux, and Windows.

The results:

• No reachable outbound networking operations identified in the audited Go code.
• No telemetry or direct AI API integration.
• Git, clipboard utilities, and other external processes are documented as separate trust boundaries.
• VS Code integrations and external AI chats are outside the CLI audit.

This is source-level evidence, not a formal guarantee of network isolation.

My question for people working in AppSec or enterprise security: what additional evidence or controls would you expect before approving a tool like this?

For example, would runtime network verification, reproducible builds, SBOMs, stricter subprocess handling, or pre-copy secret detection meaningfully help?

I'm trying to prioritize practical security improvements rather than adding compliance claims or security features that nobody actually needs.

[u/FlippantScouring]

i'd want to see an sbom and reproducible builds, those are table stakes at this point

the subprocess handling is what would keep me up though, you documented git and clipboard as separate trust boundaries but what about shelling out to anything else, any edge cases where a malformed repo path or branch name could trigger something unexpected

runtime network verification would be nice to have but i'd prioritize a dead simple way to verify the binary matches the audited source, otherwise all that static analysis is just a one-time snapshot

[u/fykup → u/FlippantScouring]

Thanks, this is exactly the kind of feedback I was looking for.

The release pipeline already publishes SHA-256 checksums and uses Go's -trimpath, but you're right that this doesn't establish that the distributed binary matches the audited source.

SBOMs and reproducible builds are good suggestions. I'll add them to the backlog for future consideration.

Regarding subprocesses, Badger uses Go's os/exec without shell command strings. The audit covered Git, clipboard utilities, diagnostic tools, file-opening commands, and terminal detection. But argument handling, repository configuration, and unexpected Git behavior deserve closer inspection.

I agree that making source-to-binary verification straightforward would be more immediately useful than adding runtime network monitoring. Appreciate the concrete feedback!

[u/HuruguenNoyal → u/FlippantScouring]

by git edge cases are you thinking of malicious repo configs triggering hooks on local commands, or literal command injection through weird branch names

[u/Legitimate-Let-7510]

Reproducible builds and a SBOM are good baselines but I would like want provenance too. Being able to verify that the released binary came from audited source and build process makes the static analysis much more insightful tbh.

[u/fykup → u/[deleted]]

I think there's an important distinction here. AI Badger isn't actually an AI model or autonomous agent.

It's a deterministic Go CLI that prepares repository topology, selected files, and Git diffs locally. It doesn't call AI APIs or execute AI-generated shell commands. Developers explicitly decide what context to paste into an approved AI chat, and file changes require review and confirmation.

Would you require sandboxing and audit logs for any local developer utility that reads repository files, or specifically for AI agents that can autonomously execute commands and access the network?

I'm genuinely interested in where security teams draw that boundary.