An engineering team wants to buy access to an AI coding assistant that needs to read the whole repository to be any good. The tool goes into procurement review, and security asks the one question that decides everything: where does our code go. The vendor's answer is well rehearsed. A full copy of the codebase syncs to our cloud. We will sign your data processing agreement. Everything is encrypted at rest and in transit. We hold a SOC 2 report. For most categories of enterprise software, that answer is enough to get a signature, and the deal moves forward the same week.
For a specific, recurring set of buyers, it is not enough, and the deal stalls in review, sometimes for months, sometimes permanently. Nobody doubts the vendor's honesty. The problem is that the vendor answered a question about behavior, do you trust us once we have your code, when the real question was whether a full copy of the company's proprietary source should exist on infrastructure it does not control at all. No amount of reassurance about behavior after that point resolves a concern that starts before it.
This piece is about that gap: who gets stuck at it, why the standard privacy playbook built for personal data does not fully transfer to source code, and the architectural alternative a small number of tools, including one this piece will name plainly near the end, have started building. Parse the code where it already sits, and send only a derived, source-free artifact off premises, so the question a security team has to answer stops being about trust in an organization and starts being about the contents of a specific, inspectable object.
The objection that stalls procurement
The buyers who get stuck are not a random cross-section of the market. Three groups show up over and over.
Regulated industries, banks, insurers, healthcare systems, already run every new vendor through a data-handling review, and "send us your source code" reads on that review the same way "send us your customers' medical records" would: a category of data the company has specific, sometimes regulatory, reasons never to hand to a third party in bulk. Defense-adjacent companies face a sharper version of the same problem, covered in more detail below, where the constraint is not a policy choice but export control law with no exception for good intentions. And consultancies, agencies, and software vendors who hold other companies' code under NDA face a version of the objection that is not even theirs to waive: the confidentiality obligation runs to a client who was never consulted about the AI vendor at all.
None of this is hypothetical caution. In April 2023, engineers at Samsung's Device Solutions division pasted proprietary source code for semiconductor equipment diagnostics into ChatGPT at least three times within about three weeks, along with a recording of an internal meeting; by May, Samsung had banned ChatGPT and other generative AI tools company-wide (Forbes). Around the same time, Apple restricted internal use of GitHub Copilot specifically, citing the risk that confidential code or product plans could leak through the tool, and Goldman Sachs, Citigroup, and other major banks placed similar restrictions on employee ChatGPT use (Fortune). A 2023 Cyberhaven analysis of 1.6 million knowledge workers found that 11 percent of the data employees pasted into ChatGPT was confidential, with source code among the categories most commonly exposed (Cyberhaven). These are not edge cases. They are what happens by default when the easiest way to get value from an AI coding tool is to paste in the thing it needs to see.
Source code is a harder problem than personal data
Most enterprise privacy practice, including the checklist a company runs for how its AI agents handle customer data, was built for personal data under laws like GDPR. Source code is a different category of sensitive information, and the legal mechanism that protects it works in the opposite direction, which is why the standard playbook does not fully transfer.
Personal data protection is close to unconditional. GDPR gives a data subject rights over their information regardless of how carefully the controller behaved before a breach; the obligations exist because the data describes a person, full stop. Trade secret protection is conditional. Both the EU Trade Secrets Directive and the US Defend Trade Secrets Act of 2016 define a trade secret as information that is secret, has commercial value because it is secret, and has been kept secret through reasonable steps taken by the person who controls it. Miss that third condition and a court can find the trade secret status was never established, no matter how valuable the code actually was. That turns "where did our source code go, and under what controls" from a security nicety into a live question about whether a company can still call its own code a trade secret at all. A signed vendor contract is one control among several a company would need to point to later. It is not, by itself, the clean answer a court wants when nobody can say with precision who else has read the code since it left the building.
There is a second, quieter overlap with personal data law, and it cuts the other way. Most real codebases contain at least some personal data whether or not anyone intended it to be there: names and emails in test fixtures, customer identifiers in seed data, a colleague's name in a code comment, a support engineer's login sitting in a config file three years after they left the company. GDPR's definition of personal data is broad enough to catch all of it, since Article 4(1) covers any information relating to an identified or identifiable natural person, so a codebase upload can trigger data protection obligations that have nothing to do with the code being proprietary, and everything to do with what somebody left in a fixtures folder. A single source code upload can be a personal data event and a trade secret event at the same time, governed by two different bodies of law with two different tests for whether the disclosure was acceptable.
Defense-adjacent companies face a sharper version of the trade secret problem, because the law removes the room for good-faith judgment calls that trade secret doctrine still leaves open. Source code that qualifies as technical data under ITAR, the International Traffic in Arms Regulations, meaning information related to the design, development, production, or maintenance of a defense article, cannot be released to a foreign person without a license, and the release does not need to cross a border to count. Under 22 CFR 120.50, transferring technical data to a foreign person inside the United States is itself defined as an export, a deemed export, with no requirement that the transfer was intentional or that the recipient understood what they were looking at. A cloud AI pipeline that routes the data through infrastructure, support staff, or subcontracted reviewers outside the contractor's direct control makes it hard to certify that no deemed export occurred, because the contractor usually has no visibility into the nationality of everyone who could touch that pipeline. Contractors handling Controlled Unclassified Information (CUI) carry a related, more procedural version of the same requirement: NIST SP 800-171 and the Cybersecurity Maturity Model Certification (CMMC) program expect any cloud service that touches CUI to hold a FedRAMP Moderate authorization or an equivalent, a bar most general-purpose AI coding tools do not clear.
Why a DPA and encryption at rest do not close the gap
The vendor's standard answer to all of this is well rehearsed, because it is the correct answer for almost every other category of SaaS data. Sign a data processing agreement, the contract GDPR Article 28 requires whenever a processor handles data on a controller's behalf. Encrypt everything at rest and in transit, in line with the security of processing obligations in Article 32. Hold an ISO/IEC 27001 certification or a SOC 2 report to show the security program is real, not asserted. For a CRM record or a support ticket, that combination is generally sufficient, and it is why most enterprise software gets bought without anyone escalating.
It runs into three specific problems once the data in question is an entire proprietary codebase rather than a database row.
The first is that encryption at rest answers a threat model that is not the one anyone is actually worried about. It protects against someone stealing a disk or an unauthorized process reading raw storage. It says nothing about the vendor's own service, because the entire point of an AI code-understanding product is to read and reason about the code, which means decrypting it and holding it in memory somewhere the vendor's own systems, staff, and support tooling can, in principle, reach. Encryption at rest is a real control. It is just not a control against the risk the security team is actually pricing: exposure inside the vendor's own operating environment, not a stolen hard drive.
The second is that a DPA is a contract, not an architecture. It creates liability and audit rights if something goes wrong after the fact. It does not make the something-going-wrong structurally impossible before the fact, and it typically authorizes a list of subprocessors, other cloud infrastructure, logging and observability vendors, sometimes the underlying model provider itself, so agreeing to the DPA usually means agreeing to trust an entire chain of companies the security team will never get to review individually. The guarantee is only as strong as the weakest subprocessor on that list. GDPR Article 44 requires transfers of personal data outside the EU to meet the Regulation's Chapter 5 conditions, and the Schrems II ruling, which struck down the EU-US Privacy Shield in 2020 and layered extra conditions onto the standard contractual clauses most DPAs still lean on for exactly that purpose, is a reminder of how quickly a paper transfer mechanism can stop being sufficient on its own.
The third problem is specific to the consultancy and agency case, and general privacy guidance tends to miss it entirely. When the code under review belongs to a client, held under an NDA rather than owned outright, the decision to disclose it to a third-party AI vendor is often not the reviewing company's decision to make, regardless of how good that vendor's DPA is. The confidentiality obligation runs to the client. A signature on a vendor's data processing agreement does not discharge an obligation owed to somebody who was never a party to it and was never asked.
None of this makes the DPA dishonest or the encryption pointless, and it does not mean the vendor is acting in bad faith. It means the standard package answers a real, well-understood question, is this data handled responsibly once it is here, and the security team is asking a different, prior question: should a full copy of this data exist here at all. Tightening the contract language on the first question does not answer the second one.
Parse locally, transmit only the shape
There is a way to answer the second question directly instead of arguing around it: do not send the codebase in the first place.
The pattern looks like this. The parsing and analysis a code-understanding tool needs to do, walking the file tree, resolving imports, building a call graph, computing complexity and risk scores, runs on infrastructure the company already controls: the developer's own machine, or a self-hosted runner inside the company's own network. Nothing about that step requires a copy of the source to leave the building. Only the output of that step, a derived, source-free artifact, structural relationships and scores rather than source text, travels to whatever server needs to store it, sync it across a team, or apply further scoring.
"Source-free" is doing precise work in that sentence, and it is worth being exact about what it means. It means the artifact carries structural facts (this function calls that one, this module imports that package, this file sits at the center of forty other files and touching it has a wide blast radius) and derived numbers (a risk score, a complexity score, a hash that changes when the underlying file changes), and it does not carry the literal text of the source files that produced those facts. The distinction is not obfuscation. An obfuscated file is still, technically, the file, transformed in a way that could in principle be undone. A source-free artifact was never the file to begin with. It is a different, much smaller object, built by reading the file, that describes the file's shape rather than reproducing its content.
This is the same move GDPR Article 5(1)(c) makes for personal data, applied to a different category of sensitive information. The data minimisation principle says a system should hold only what it needs for its purpose, not everything it could plausibly access. A code-understanding agent's actual purpose is reasoning about structure: what depends on what, what an edit is likely to break, what the shape of the system looks like. It was never a requirement of that purpose that the agent also permanently possess the literal implementation. Building the boundary into the architecture, so the parsing step is where the company's own infrastructure ends and only the derived artifact crosses into the vendor's, does the same job encryption at rest was being asked to do, except it does the job by removing the sensitive category from the exchange instead of promising to protect it once it arrives.
That is also what changes the shape of the procurement conversation. The security team is no longer being asked to extend trust to an organization it does not control, its staff, its subprocessors, its incident history, on the strength of a contract. It is being asked a narrower and genuinely answerable question: here is exactly what is in the artifact that leaves the building, is this specific, inspectable thing acceptable to disclose. That question has a concrete answer a reviewer can actually check, instead of a promise a reviewer has to decide whether to believe.
What a source-free artifact can and cannot represent
Answering that narrower question honestly means being precise about both sides of it, what the artifact shows and what it withholds, rather than asserting that a graph is automatically safe just because it is not source code.
What it can represent is genuinely useful, which is the reason to build a tool this way instead of simply declining to build it. A dependency and call graph: what imports what, what calls what, which modules sit upstream of which others. Blast-radius metadata: if this function changes, how many other places in the system are structurally downstream of it. Complexity and risk scores computed from the shape of the code rather than its content. Hashes and fingerprints that let a system detect that a file changed, and roughly how much, without ever storing what it changed into. Taken together, that is enough to give an AI coding agent something close to persistent memory of a project's architecture, which is a real capability gap in a model that otherwise starts from zero context every session.
What it cannot represent is the part of the codebase that is actually proprietary in the sense a competitor would pay for. A graph edge that says checkout.js calls calculatePrice() does not say what pricing logic lives inside calculatePrice(). A risk score attached to a fraud-detection module does not say what the fraud rules are. The literal strings, the tuned thresholds, the exact algorithm, the comments explaining a decision, the credentials and configuration values sitting in the repository: none of it is in a structural graph, because none of it is structure. This is also the honest answer to whether the artifact can be reversed back into the source: there is no decryption step that turns a call graph back into the function bodies it was built from, not because the transformation is cryptographically strong, but because the information was never captured in the first place. Nothing decodes what was never encoded.
The honest caveat, worth stating plainly rather than glossing over, is that shape is not perfectly meaningless. An unusual dependency structure, a module named the way a fraud-detection or targeting system tends to be named, a graph with an unmistakable shape for a well-known class of algorithm, could tell a sufficiently informed observer something about what a system does, even without a single line of implementation in view. Source-free architecture reduces the disclosure surface by an order of magnitude or more. It does not reduce it to zero, and treating it as a blanket exemption from disclosure risk would repeat the overclaiming this piece has argued against in the vendor's original pitch. What it does change is the category of thing a security team has to reason about: not an entire codebase sitting on infrastructure it does not control, but a specific, boundedly small set of structural facts it can actually look at and decide about.
The architecture question replaces the trust question
None of the buyers this piece opened with, the bank, the defense contractor, the consultancy holding a client's code under NDA, were ever going to be won over by a better-worded contract. A contract is a promise about behavior. What a security review actually tests is whether the sensitive category of data can leave the building at all, and a promise, however carefully drafted, does not change the answer to that question. An architecture that never moves the source code in the first place does.
One live example of this pattern is Spiderbrain, built by Perform Digital. Spiderbrain builds a deterministic, source-free context graph, a "brain," of a software project, so an AI coding agent gets persistent memory and structural reasoning across sessions instead of a flat context window that resets every time. The parsing that builds the graph runs locally, on the developer's own machine; what reaches Spiderbrain's EU-based servers for scoring is the source-free map, structure and scores, not the source files themselves, and the code never leaves the device it was parsed on. The graph is deterministic, the same codebase produces the same brain every time, and roughly 350 automated checks run green against it on every release, which functions as built-in auditability. It speaks the Model Context Protocol and works with more than ten MCP clients, including Claude, Claude Code, Cursor, Continue, Cody, and Zed, and the graph itself carries a real dependency and call graph with blast-radius analysis, the structural capability described above, not the underlying implementation. Spiderbrain's public brain registry, which hosts pre-built brains for public repositories, is a useful contrast rather than a contradiction: public code has no privacy question to begin with, which is exactly why local parsing matters specifically for the private, proprietary codebases this piece has been about. For more on how the graph itself gets built, see how the deterministic graph is built.
This does not make source-free architecture a universal answer. Plenty of AI coding tools have a legitimate reason to need the literal source: a code review assistant that quotes the exact lines it is commenting on, for instance, and for those tools the DPA-and-encryption conversation is still the right one to have. But for the specific job of giving an AI agent durable, structural understanding of a codebase, the source text was never actually required, and once that is true, sending it stops being a convenience and starts being an unnecessary liability. The security review that opened this piece does not have to end in a no, and it does not have to end in a leap of faith either. It can end in a specific, checkable answer to a specific, checkable question: here is exactly what leaves the building, and here is why that is all it needs to.
Council summary
This post argues that "upload your codebase so an AI can understand it" is not an irrational objection but a structurally correct one for a specific set of buyers, regulated industries, defense contractors bound by ITAR and CMMC, and any team holding client code under NDA, because source code is governed by trade secret law that conditions protection on the owner's own diligence, unlike data protection law that protects regardless of it. It walks through why the standard vendor package of a DPA and encryption at rest answers a narrower question, is the data handled responsibly once it arrives, than the one security teams are actually asking, should a copy exist here at all, and lays out the alternative directly: parse the code where it already lives and transmit only a source-free artifact, structural relationships, scores, and hashes, that was never the source text to begin with rather than an encrypted version of it. It is honest that this narrows disclosure risk rather than eliminating it outright. The reader's takeaway is concrete: for the categories of code where this objection actually blocks a deal, the fix was never a better contract. It is not moving the sensitive data in the first place.
Comments