Who is accountable when an AI assistant surfaces private code from a cached repository?

Why This Matters for Security Teams

When an AI assistant resurfaces private code from a cached repository, the issue is rarely a single misconfiguration. It usually reflects a control gap across source control, indexing, retrieval, and the assistant layer itself. That means ownership is shared, but accountability still needs a primary decision-maker. The practical question is not whether the code was once private, but whether cached copies were governed as sensitive data across every system that could replay them.

This is why security teams should treat the event as an access-governance failure, not just a content leak. The same pattern shows up in incidents like the DeepSeek breach and the GitLocker GitHub extortion campaign, where exposure can move from one layer to another faster than human review can keep up. The NIST Cybersecurity Framework 2.0 is useful here because it frames governance, asset visibility, and response as connected responsibilities rather than isolated controls.

In practice, many security teams encounter the blast radius only after an assistant has already answered with material that was never meant to be retrievable in the first place.

How It Works in Practice

Accountability usually follows the control plane that made the exposure possible. The repository owner is responsible for classifying and protecting the source material. The platform owner is responsible for caching, indexing, retention, and deletion behavior. The team operating retrieval or agent tooling is responsible for how search, embeddings, and prompt-time access checks are enforced. If any one of those layers keeps stale data, the AI assistant can surface it even after the original repository was fixed.

Operationally, this means teams need to ask four questions:

• Was the repository copied into a cache, vector store, or search index with its own retention rules?
• Could the assistant retrieve data based on similarity or prior embeddings without checking current authorization?
• Was the private code protected by the same access policy in the downstream system as in the source system?
• Was deletion propagated everywhere, or only removed from the original repository?

This is where current guidance suggests using NIST CSF style governance alongside explicit data-lineage tracking. NHIMG research on the state of secrets in AppSec shows why this matters: leaked secrets remain hard to remediate, and AI systems can reproduce sensitive patterns from codebases. That makes the retrieval layer a real security boundary, not just a convenience feature.

Where this guidance breaks down is in distributed developer platforms that sync code into multiple caches, because deletion and access revocation often do not propagate uniformly across those replicas.

Common Variations and Edge Cases

Tighter retrieval controls often increase latency and engineering overhead, so organisations have to balance user experience against the risk of resurfacing private code. There is no universal standard for this yet, especially when assistants span code search, ticketing, and chat histories. That means some teams will adopt strict deny-by-default retrieval, while others will allow broader recall for productivity and rely on post-hoc monitoring.

The main edge cases are usually operational, not theoretical. A repository may be private, but its cached fragments can remain in:

• search indexes that were not rebuilt after access changes
• embedding stores that outlive the source repository
• support transcripts or agent memory layers that retain snippets
• third-party indexing services with their own retention and deletion timelines

Best practice is evolving toward context-aware authorization at retrieval time, plus explicit lifecycle rules for cached code and secrets. That approach helps separate who owns the source from who is accountable for downstream exposure. The Emerald Whale breach is a reminder that once sensitive material is replicated into another system, the exposure pattern can change faster than the original control owner expects.

For security leaders, the practical answer is that accountability should be assigned to the platform owner for the cache, with shared remediation obligations across the repository and retrieval teams.

Related resources from NHI Mgmt Group

• Who is accountable when untrusted project configuration changes what an AI assistant sees?
• Who is accountable when an AI agent in CI/CD exposes secrets or pushes unauthorized code?
• Who is accountable when an AI chatbot surfaces unsafe or internal information?
• Who is accountable when AI tool use happens through unmanaged browser sessions?