The Compiled-Artifact Leak

It is tempting to treat "the compiled-artifact leak" as a uniquely AI-shaped problem. It mostly isn't. The honest framing — and the one I now ship with — is that this problem splits into two classes of unequal weight, and conflating them leads to overbuilt controls for one and underbuilt controls for the other.

The problem, two classes

About 80% of the leak surface is a configuration problem. A compiled artifact reveals something it shouldn't because the access-rights model was set up to permit it — the same way a calendar set to show free/busy can reveal that a sensitive meeting is happening at all. The fix is permissions, applied correctly, with the right inheritance rules. Not new machinery; old discipline.

About 20% is genuinely compiler-emergent. Even with a perfect permissions configuration, an LLM-produced artifact can — through the shape of its prose, not its substance — encode something about a higher-sensitivity source that the permissions model didn't catch. And the compiler can produce new implicit facts by combining lower-sensitivity sources in ways the permissions model couldn't tag in advance.

These two classes need different controls. Most of the noise around LLM-compilation leaks comes from applying compiler-emergent worry to cases that were actually configuration mistakes.

The larger share: configuration

This is the category that looks scary but is solvable.

A weekly digest mentions a leadership meeting happened — when the existence of the meeting was itself sensitive. A "recent activity" summary references a document by name when the document's existence was private. A customer dossier aggregates conversations from a segment that shouldn't have been readable as a set. In every one of these cases, something was tagged at a sensitivity too loose for what it actually was, and the compilation dutifully reflected the tagging.

The permissions model closes this class in four ways:

Minimum necessary at capture. The knowledge layer stores extracted facts, not copies of source records. What isn't extracted cannot be leaked by compilation. The compiler's context is narrower by construction.

Sensitivity inheritance. Every compiled artifact inherits the maximum sensitivity of its sources (see sensitivity-gradient). A digest compiled from one leadership note and three team-wide notes is a leadership artifact, full stop. If you don't want the digest visible at team-wide, the fix is to either tag the leadership source as leadership (which the inheritance rule honours) or exclude it from the digest's candidate set. This is the calendar-permissions equivalent: if the existence of the meeting is sensitive, the calendar has to be configured to hide busy, not just hide title.

The filter-first invariant at query time. A user who should not see a sensitive source also should not see a compilation that inherits that source's sensitivity. The filter-first architecture ensures the model never sees a compilation at a sensitivity the querying user isn't cleared for.

Citations back to source. Every compiled artifact is traceable to the raw inputs that produced it. Citations do not prevent leaks; they make incidents investigable and sensitivity misconfigurations correctable at source.

Applied well, these four close essentially all of the "compiled artifact leaked something" incidents I have actually seen in operating systems. They are not LLM-specific; they are permissions design applied to generated artifacts instead of stored ones.

The smaller share: compiler-emergent

This is the category that is actually new with LLM compilation, and it is the smaller part.

Linguistic echo. A compiled artifact at a permitted sensitivity can encode — through tone, vocabulary, topical shape — something about a higher-sensitivity source that the permissions model didn't tag. The model was shown only team-wide sources, composed a summary, and the style of the summary (technical precision on a topic that is rarely discussed at this level) hints at a parallel leadership conversation. No permission was violated in content; something was transmitted in form.

Emergent combination. The LLM can combine facts from multiple lower-sensitivity sources into an implicit fact that wasn't in any source individually. Two unremarkable team-wide observations — the customer missed their last two reviews and the sales lead cleared their calendar Thursday — can be combined into an inference about an account status that neither source states and that nobody tagged at any sensitivity because the combined fact didn't exist before compilation. A calendar cannot do this; independent meetings do not synthesise.

Both channels are real. They are also narrow: I have seen linguistic-echo incidents exactly twice in operating systems, and emergent-combination incidents perhaps three times, all of them small enough to catch in review. They are not the dominant risk.

The mitigations I run for this residual are conservative and admittedly partial:

• Review discipline. Compiled artifacts that span tiers are read before they are surfaced, by the operator, for tone and inference — not just content. This is slow and doesn't scale; it is the honest state.
• Style-normalisation prompts. The compiler is instructed to write at the sensitivity of the output tier, not the maximum of the inputs — so a team-wide summary reads like other team-wide summaries, not like a stylistic cousin of a leadership note. This closes some linguistic-echo cases; I do not have a measurement of how many.
• Client-hosted models for regulated deployments. When the residual surface matters more than the operational cost — regulated industries, high-sensitivity client work — I move the compilation inside the client's own cloud boundary. This doesn't close the compiler-emergent channel technically; it bounds its blast radius.

Where this changes the posture

The useful reframe: when an incident looks like a "compiled-artifact leak," the first question is not "did the LLM do something novel?" but "is this a permissions configuration we should have caught?" Four out of five times, the answer is yes — and the fix is to tighten the sensitivity tagging upstream, not to add new LLM-specific machinery.

The one in five that is genuinely compiler-emergent is real, narrower than the rhetoric around LLM compilation suggests, and the mitigations for it are partial and operator-dependent. That is the honest position, and it's better than treating the whole class as unsolved.