Content-Based Detection for Source Code and Technical IP Without Labels

Source code and proprietary technical content almost never carry a formal classification tag, and that single fact leaves most metadata-driven detection systems blind to the bulk of an organization's most valuable intellectual property from the start. Code gets written, committed, shared, and passed around in its native format. Nobody stops to tag a file before opening a pull request, pasting a snippet into Slack, or sharing an IDE session with a teammate.

The technical material at risk goes well past.py or.java files, too. Architecture diagrams, model weights, API schemas, build scripts, configuration files, and internal documentation rarely pass through anything resembling a classification workflow, yet all of it counts as IP worth protecting. The 2026 Verizon Data Breach Investigations Report found that source code is the single most common data type submitted to external AI models, which puts the highest-volume leak channel and the lowest-label-density content in the exact same place.

The channels have multiplied faster than the controls built to watch them. Screenshot pastes, ticket comments, AI prompts, MCP tool calls, browser extensions, and embedded IDE sessions now carry sensitive technical content routinely, and legacy DLP tooling was never built to inspect most of these surfaces. Agentic AI workflows push the problem further still: an AI agent executing tool calls can move technical content through local stdio and delegated runtime behavior at a pace no human reviewer can keep up with, and none of that content arrives with a label attached.

None of this is a niche failure mode. It's the default condition of how technical work happens, and it means any detection strategy that starts from "check the tag" has already lost before the first file moves. Detection has to work from something else: what the content actually is, not what someone remembered to call it.

What content-based detection reads when there is no label

Source code and technical IP carry structural, syntactic, and semantic properties that identify them without any label at all, and content-based detection is built to read those properties directly. Code has a grammar of its own: function declarations, import statements, class hierarchies, indentation conventions, build directives. That grammar is recognizable on its own terms, independent of file extension or any metadata sitting alongside it.

Programming languages also carry distinctive token patterns. A fragment of Go, Python, or VHDL reads as linguistically distinct from ordinary prose even after it's pasted into a chat message or dropped into an AI prompt. Variable names, function names, and inline comments carry meaning too, and that meaning is often enough to tell a generic tutorial snippet apart from proprietary implementation logic.

What makes these properties useful for detection is that they survive transformation. Technical content that gets copied, paraphrased, or reformatted still holds onto structural fingerprints, including a function signature pasted into a PDF, a config block embedded inside a screenshot, or a schema fragment sitting in a Slack thread. Heimdal Security's technical DLP overview describes deep content analysis as purpose-built to catch policy violations buried inside multi-layered files, a.docx attached to a.csv or.xls, and that same logic applies directly to how technical content ends up embedded in formats that were never meant to hold code.

That durability is the whole point. If structure, syntax, and semantics hold up even when a file's container, format, or wrapper changes, detection built on those properties can follow the content wherever it goes, which is what fingerprinting and semantic analysis are designed to exploit.

Fingerprinting, semantic analysis, structural recognition, and OCR each catch what the others miss

No single content-based technique covers every way technical IP moves, and the space between techniques is where real exfiltration happens. Effective detection layers several methods on purpose rather than betting on one.

Document and code fingerprinting works by generating a hash or structural signature from a known sensitive file, so any derivative, even a partial copy or a reformatted version, that matches the signature trips the detection. It's strong at catching exact or near-exact copies: a proprietary library function pasted into a personal repository, a schema file attached to an outbound email. Its limitation is that it needs a corpus of known-sensitive content to check against, so novel code or documents that haven't yet entered the reference set slip through untouched. AI-based data lineage extends this logic by tracking how a file evolves, from a Word document to a PDF, from a Slack message to an email to an AI prompt, mapping the transformation itself rather than only matching static hashes.

Semantic and ML-based analysis works differently: it classifies content by what it means and how it's used, not just how it looks, which is what catches novel or obfuscated material that fingerprinting misses. AI-driven classification models detect unstructured data that rules-based systems overlook, with far fewer false positives than static pattern matching. Applied to source code, a semantic model can recognize a block of text as proprietary model-training logic even after it's been reformatted, had its variable names swapped, or had its comments stripped out. It also catches the case where an employee rewrites a proprietary algorithm in slightly different form before handing it to an external AI tool.

Structural pattern recognition takes a third angle, identifying content by its grammar rather than its exact tokens: import blocks, class definitions, API endpoint declarations, Makefile syntax, Dockerfile conventions. It works across languages and formats without needing a known reference file, which makes it useful when the file type itself is disguised or missing, a.txt file that happens to contain Go, a chat message carrying a SQL schema. Modern content-aware platforms extend this across messages, attachments, screenshots, PDFs, spreadsheets, ZIP files, and AI interactions, and structural recognition is what makes detection possible across that mixed bag of formats.

Then there's the analog gap. OCR extracts text from screenshots, scanned documents, and image files, closing off a channel that static rules leave wide open. A developer who screenshots proprietary code on the way out the door, or who photographs a whiteboard covered in an architecture diagram, produces content that a text-pattern scanner simply cannot read without OCR sitting in front of it. Content-aware platforms that inspect images and screenshots using OCR now treat that as a baseline expectation rather than an advanced add-on. The same gap appears in the physical side-channel cases, where content leaves through a photograph or a handwritten note rather than a digital transfer, and no purely digital scanner was ever going to catch it.

Each technique fails differently. Fingerprinting misses anything novel. Semantic analysis lives or dies on model quality. Structural recognition can be fooled by deliberate obfuscation. OCR runs into accuracy limits on low-resolution images. Layered together, though, the blind spot of one method sits inside the coverage area of another, and that overlap is what closes the gap.

Content detection in real exfiltration cases: successes and failures

Documented exfiltration cases follow a consistent shape: the content moved without tripping any label-based control, and detection either worked because content-aware methods were watching, or failed because they weren't.

Take the Linwei Ding case involving Google's trade secrets. Ding allegedly uploaded a large volume of confidential files from Google's network to a personal cloud account over roughly a year. The method was unusual: he copied data from Google source files into the Apple Notes app on a Google-issued MacBook, then converted those notes into PDF files and uploaded them to a personal Google Cloud account, sidestepping conventional file-transfer controls entirely by routing everything through a trusted first-party application. The content, though, remained structurally identifiable as proprietary source code no matter what container it sat inside. A system reading the content itself, rather than file metadata or transfer protocol, could in principle have flagged that structural signature regardless of the Apple Notes wrapper. The exfiltration path deliberately steered clear of every surface legacy DLP watches: no email, no USB, no flagged upload. The content itself never changedc26.

Valeo's lawsuit against a former employee tells a related story. The suit alleges the employee granted his personal email account access to Valeo's systems and then downloaded source code without authorization. That downloaded material was identifiable by structure and syntax no matter how it was moved, and a content-aware system watching what was accessed and transferred, rather than only who had permission to access it, could have flagged the download.

The Yahoo AdLearn case, filed in 2022, shows a different failure point. A Yahoo research scientist downloaded a substantial trove of trade secrets related to the AdLearn product before moving to competitor The Trade Desk, leading to lawsuits for intellectual property theft. Here, the volume of the download is what a behavioral layer would have caught; content detection's job is confirming that the material taken was genuinely proprietary technical IP rather than routine research output. Neither signal alone tells the full story. Volume without content confirmation is just a large transfer; content confirmation without volume context is just a file that happens to be code.

The Samsung physical side-channel case pushes the boundary further. Prosecutors estimated significant economic damage, and experts suggested the technological gap created by the leak amounted to years of R&D advantage handed to a competitor. Content captured through physical means, photographing a screen, copying down handwritten notes, bypasses every digital content inspection tool unless OCR or camera-based controls are actively in place. Content-based detection has a hard boundary at that analog gap, and no software-only approach closes it completely.

Then there's the accidental exposure of the Claude Code npm package, which involves no malicious actor at all. Anthropic accidentally shipped a source map file inside a publicly available npm package that pointed back to Claude Code's full source code, hosted on Anthropic's own cloud storage, exposing the complete TypeScript codebase behind its agentic coding tool across the terminal, IDE extensions, desktop app, and browser. Nothing about that content was labeled sensitive, yet its structural and semantic properties would have identified it as proprietary source code to any content-aware system watching for it. It's a negligence case, not a theft case, and content-based detection works the same regardless of intent because it reads structural and semantic properties rather than motive.

Across these cases, the common thread holds. The IP moved in a form that kept its structural and semantic properties intact even as labels, file types, and transfer channels changed around it. But the cases also mark where content detection alone runs out of road: when volume, timing, or access pattern carries the real signal, as in the Yahoo case, or when the content exits through a physical channel, as with Samsung, content analysis needs behavioral and contextual backup to close the loop.

Content detection without behavioral context produces a false positive problem that defeats itself

A content-based system that fires on every instance of code syntax or technical structure, without knowing who is moving it, where, or in what pattern, ends up recreating the alert fatigue it was supposed to eliminate.

Developers move source code constantly, and legitimately: commits, pull requests, code reviews, snippets shared with a colleague, a debugging question posted to Stack Overflow. At the content layer, every one of these looks identical to exfiltration. A survey of information security leaders found a majority describe their teams as overwhelmed by benign DLP alerts, with roughly half of all DLP alerts turning out to be false positives, and analysts in legacy deployments spending close to half their investigation time on events that never warranted a second look. When that much of the queue is noise, triage gets faster and shallower by necessity, and the real exfiltration event lands in a queue that's already been trained to expect nothing.

Content detection on its own cannot tell a senior engineer sharing a utility function with a contractor apart from that same engineer sending a proprietary model architecture to a personal account the week before resigning. The action at the content layer is identical in both cases. Context is what makes content-based inspection enforceable at all: without it, the same action reads as normal work or as a policy violation depending entirely on who did it, when, and where.

None of this is an argument against content detection. Behavior-only tools can flag that something anomalous happened without ever confirming what was actually taken. Neither approach is sufficient by itself, and that's the case for combining them rather than picking one over the other.

How data lineage connects content signals to behavioral patterns

Data lineage, the record of how content was created, who touched it, how it transformed, and where it eventually went, gives content-based detection the context it needs to tell real risk apart from normal work.

Lineage answers questions content analysis alone can't reach on its own. Was this access normal for this person, and did it happen at an unusual hour? Did the same content turn up in three different outbound destinations inside a short window? Did the access follow a resignation, a rough performance review, or a new job announcement? AI-based data lineage tracks how files evolve, from a source file to a PDF, from an internal tool to an AI prompt, mapping the user actions and transformations that came before any given event so the system understands the sequence that led up to it.

Two actions that look identical to a pattern-matching model can mean entirely different things once the system understands the lineage behind them. A developer sharing a function snippet with a teammate reads as routine work. The same developer sending that same fragment to a personal Gmail account two weeks before their notice period reads as something else entirely, and the content-layer signal is identical in both cases; the lineage is what separates them.

The stakes for getting this right are not small. The ENISA Threat Landscape 2025 found that data exfiltration accounted for nearly a third of observed incident impacts, and lineage-based approaches address the gap that encrypted or disguised transfers leave open, because they track provenance rather than relying on visibility into the transfer itself. Content tells a system what moved. Lineage tells it whether that movement fits the pattern of the person and the moment. Together, they turn a structural match into a detection someone can actually act on.