Should organisations keep code search and embeddings local when using AI development tools?

Why This Matters for Security Teams

Code search and embeddings are not just productivity features. They are a data exposure path. When an AI tool indexes a repository, it may copy source fragments, comments, tests, and secrets-adjacent context into a retrieval layer that is outside the control boundary. For sensitive codebases, that changes the question from “Can the model answer?” to “Where did the code go?”

The risk is especially relevant for organisations handling proprietary software, regulated data, or air-gapped environments. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need to control information processing and external service dependencies, while NHIMG analysis of the DeepSeek breach shows how quickly sensitive records can become exposed when data handling boundaries are weak. NHIMG research also notes that 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases in The State of Secrets in AppSec.

Security teams often assume the model prompt is the only thing being shared, but retrieval pipelines can create a second, less visible copy of the code. In practice, many security teams encounter data leakage only after an external service has already indexed the repository, rather than through intentional review of the toolchain.

How It Works in Practice

The default pattern for sensitive environments is local search plus local embeddings. That means code stays on the developer machine, on an approved workstation, or within a controlled internal environment. The AI tool can still perform semantic retrieval, but the embedding model, vector store, and search index remain under organisational control. This is the cleanest option when source code, credentials, or internal architecture patterns should never leave the boundary.

Operationally, the decision should be tied to data classification and environment type. If code is highly sensitive, choose on-device or self-hosted embedding generation, encrypt the vector store, and apply retention limits to indexed material. If external retrieval is unavoidable, the toolchain should prove what leaves the boundary, how long it persists, and who can access it. That aligns with the least-privilege posture reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls and with NHIMG’s warning in The State of Secrets in AppSec that fragmented secrets handling and slow remediation materially increase exposure.

• Keep embeddings local for repositories that contain proprietary logic, regulated data, or embedded secrets.
• Use approved internal vector stores rather than external retrieval services when confidentiality matters.
• Limit what gets indexed by excluding generated files, build artifacts, credential files, and private test fixtures.
• Apply short retention and periodic reindexing so stale code snapshots do not persist indefinitely.
• Document whether the AI tool is operating as a local assistant or as a data processor outside the trust boundary.

These controls tend to break down in large monorepos with mixed sensitivity and legacy developer tooling because indexing scope becomes inconsistent across teams and workstations.

Common Variations and Edge Cases

Tighter local processing often increases developer friction, compute overhead, and support burden, so organisations have to balance confidentiality against usability and maintenance cost.

There is no universal standard for this yet. Current guidance suggests a tiered model: local-by-default for sensitive code, centralised governance for approved exceptions, and explicit review for any cloud-backed search service. For less sensitive open-source work, remote embeddings may be acceptable if the provider contract and logging model are clear. For regulated environments, however, the safer choice is usually to avoid sending code fragments to third-party embedding APIs altogether.

Edge cases matter. If the tool only indexes symbols or metadata, risk may be lower but not absent. If the repository contains secrets, the priority is not search performance but eliminating the chance that sensitive material is copied into a durable external store. NHIMG’s DeepSeek breach analysis is a useful reminder that exposure can happen through systems that were meant to be helpful, not hostile. The practical rule is simple: when the codebase is sensitive, treat retrieval infrastructure as part of the security boundary, not a convenience layer.

Related resources from NHI Mgmt Group

• What breaks when organisations keep treating code review as the primary security control for AI assisted development?
• When should organisations block MCP tools in AI development environments?
• Should organisations allow AI tools that can generate attack code?
• How should organisations govern browser-accessible AI development tools?