Before Release, Who Reviews

In the spring of 2023, engineers in Samsung's semiconductor division did three things with ChatGPT. One pasted the error source code of a device measurement database download program, asking for a fix; one pasted code for identifying defective equipment, asking for optimization; one pasted a meeting transcript, asking it to write minutes. This is CIO Dive's retelling of The Economist Korea's report; this article has not verified the original Korean text.

Put together, none of the three looked like "leaking"; each looked like "working." This is what makes boundary problems hard: leaking and working are the same action. The context that lets the model help is exactly what should not go out.

The rest of the story is well known: ban, in-house development, partitioned openness. I want to write the part the story skips. For partitioned openness to hold, someone must answer four questions. Which texts belong in the category that cannot go out (classification); what the ones that can go out should be rewritten into (rewriting); who judges whether the rewriting is sufficient (auditing); and if the judge itself errs, who detects that.

The first three questions have existing engineering approaches. The fourth, I have found no one measuring in isolation.

In "R&D in the AI Native Era", I devoted a section to escapegate: a verification demo where intranet requests that need an external coding agent to work first pass through a "transliteration agent" for classification, desensitization, rewriting, and adversarial auditing before being released. This piece does not retell its five steps; instead, it uses escapegate as a target, walking through the four questions against external evidence, including where the evidence contradicts it.

The initial reaction was swift and crude. According to CIO Dive, Samsung first limited single-submission upload capacity to 1024 bytes. On May 2, TechCrunch reported an internal memo: company devices, and personal devices connected to the intranet, were banned from using tools like ChatGPT, Bing, and Bard, effective May 1, described as "temporary." One reason was that data stored on external servers is hard to retrieve and delete; in the company's April internal survey, about 65% of respondents considered such tools a security risk.

After the ban came in-house development. On November 8, 2023, Samsung released Gauss at its AI Forum; Gauss Code was a code model, and the coding assistant code.i based on it was first used internally.

In June 2026, the direction reversed. CIO.com reported on June 12 that the DX division had officially integrated ChatGPT, Gemini, and Claude into internal work systems, with about 2,500 employees participating in validation before launch. On the semiconductor side (DS), Korea JoongAng Daily's same-day report said it had already been using Claude internally, opened ChatGPT on June 12, and would introduce Gemini within the year. In the same article, SK hynix's CEO said at a town hall that Microsoft 365 and Copilot were under review, ChatGPT Enterprise was being evaluated, and external AI would be gradually introduced in areas "not involving national core technology"; the report explained this refers to government-designated technologies with national security and economic value.

None of these reports described the technical means used to draw the line. CIO.com only mentioned building a security framework, with no details. So the comparison below is my analogy, not the companies' statements: SK hynix's "except national core technology" corresponds to L3 in escapegate's classification—this category does not leave the intranet. Whether partitioned openness can hold depends on whether this line can be written explicitly enough for a machine to execute.

Bans don't make demand disappear either. IBM's 2025 Cost of a Data Breach report says one-fifth of organizations reported leaks caused by shadow AI; in such leaks, intellectual property was compromised in 40% of cases, versus a global average of 33%. An IBM consultant's article on Think cites the 2026 edition, claiming the share of security incidents involving unapproved AI rose from 20% to 43%; this article has not verified those numbers in the original report. They do not prove bans are ineffective; they only show that "unapproved" and "unused" are two different things. The same holds on the individual side: turning off the training switch does not reach retention, feedback, or memory; see What Is Left After You Turn Off Training.

In June 2025, Simon Willison proposed the "lethal trifecta": when an agent can simultaneously access private data, encounter untrusted content, and communicate externally, an attacker can hide instructions in the untrusted content to exfiltrate private data. His conclusion was blunt: to be safe, avoid this combination entirely; of guardrail products claiming to block such attacks, he said he was "deeply suspicious," reasoning that in web security, a 95% block rate is a failing grade.

Meta's "rule of two" in October 2025 is the engineering version of the same idea: in a single session, an agent may satisfy at most two of three conditions—process untrusted input [A], access sensitive systems or private data [B], change state or communicate externally [C]. Needing all three means the agent must not run autonomously; it requires at least supervision, which can take the form of human approval or other reliable verification. Meta itself emphasized that this rule is insufficient: it does not cover attacker leverage, spam, agent errors and hallucinations, and users blindly clicking confirm can also defeat compliant designs.

Placing escapegate into this framework (the mapping is mine, not Meta's): the intranet agent holds [B] and [C]; the external agent reads untrusted web pages and dependencies [A] and can execute network calls [C], but cannot see private data, satisfying the rule of two. The trouble is the return path. The external agent's output returns to the intranet as untrusted input [A], while the intranet agent itself has [B] and [C]. All three legs reconverge here; the rule's answer is no autonomy—supervision is required. Inbound scanning (for keys and dependency risks) plus human review constitute that supervision.

"Private data doesn't go out" is harder to enforce than it looks. The three cases below share a common trait: the exit was not the chat box.

In May 2025, Invariant Labs demonstrated an attack. An attacker files an issue with a prompt injection in a public repo; the repo owner tells the agent to "look at open issues"; the agent reads the injection, pulls content from the owner's private repo into context, and opens a PR in the public repo to post it. The leaked items in the demo were project names, moving plans, and salaries, using Claude 4 Opus in Claude Desktop. The authors considered this not a defect in the GitHub MCP server code itself, but an architectural problem at the agent system level, noting that while each tool call requires confirmation by default, many users select "Always Allow."

In April 2026's Comment and Control, per VentureBeat's April 21 retelling: researchers placed an instruction in a PR title; Claude Code Security Review action, Gemini CLI Action, and GitHub Copilot Agent all complied, posting their API keys as PR comments. Anthropic rated it CVSS 9.4 (Critical), bounty $100; Google paid $1,337; GitHub $500. All three quietly fixed it; per VentureBeat, no CVE was issued at the time.

In September 2026's PixelLeak, Help Net Security's September 30 retelling of Glow Labs' research: over 13,000 internal screenshots were scattered across 900+ repos, involving developers from 300+ organizations, 93% under employees' personal accounts. Contents included utility customer bill screens from a large manufacturer, treasury management consoles from a financial institution, and screenshots of unreleased features. The cause was mundane: GitHub's PR image upload only works in the browser; command-line agents, wanting reviewers to see screenshots, created public repos themselves. Glow Labs reproduced this with Claude Code. Affected organizations were not named, and the report included no vendor response.

In all three cases, no one pasted sensitive text into an external chat box. The exits were tools in the agent's hand: opening PRs, posting comments, creating repos. The two most common controls in the next section's taxonomy—paste blocking and prompt scanning—watch a different path. That is my reading.

The implication for escapegate: it governs the text sent to the external agent, but is largely powerless over "what the external agent does with its tools." It relies on the external agent not seeing the real intranet; the most it can leak is the text that was released. Thus the entire system's weight rests on the decision of "which text to release."

First, how others do it. Below, apart from academic work, all are vendors' own documents describing their own products.

Purview's encryption labels deserve a closer look. The documentation states that content encrypted by Purview cannot be decrypted by other AI applications, so even if a user pastes it in, the AI cannot process it. This is the cleanest form of "blocking": fail-closed at the data layer, with the most thorough cost—the model cannot read it, so it cannot help. This is the topic of § 06.

NVIDIA's July tutorial makes "local model plus external policy" quite concrete: pre-deployment NeMo Guardrails directly reject files tagged as human-only (authentication, payment, cryptography, etc.); post-deployment CI validation and commit tracing, then monitoring defect escape rates—if above baseline for two consecutive weeks, tighten policy or pause rollout. One line resonates with me: the model is not the control plane. But this is a vendor tutorial, not a customer case study, and it does not compare the code capabilities of a 7B model against frontier models, at least in the parts I read. I have not verified third-party data on the capability cost of keeping code on the intranet.

On this taxonomy, most products fall at the two ends. One end is blocking—hit and block, no rewriting. The other end is trust—plaintext reaches the counterparty, with contractual guarantees of non-retention and non-training. In between is another category: release after rewriting, with fallback to the intranet if release fails. Academia has work here; I have not verified a mature product in this slot. escapegate stands here.

This category has one more question that someone must answer compared to the two ends: is the rewrite sufficient? Blocking's judgment is "what was hit"; trust's judgment is "do you trust this vendor"; neither needs to answer what the rewritten text still leaks. Once you commit to rewriting, you are accountable for the residual leakage. The auditor role is created by that commitment.

On September 14, 2026, a preprint appeared on arXiv: DR-SL (Wen Hu et al., not peer-reviewed). Its approach: sensitive items are extracted locally and "dehydrated"; only dehydrated text is sent to the cloud model; results are "rehydrated" on return. Before release, the text passes through a chain: a local dual-branch validator (one branch tests whether the dehydrated text alone can answer for hidden attributes, the other checks whether dehydrated text plus sensitive set can losslessly reconstruct the original), a deterministic "hard-wire" erasure, an external strong-attacker re-test, and finally a human fallback. Instances that fail are marked INFEASIBLE, auto-release is denied, and they go to human review.

Placing the two systems' components side by side:

Every row matches. There are two more component-level close relatives. Preεmpt is an NDSS 2026 paper that applies format-preserving encryption to format-dependent tokens and metric differential privacy to numerical values, but it limits itself to sensitive information inferable from a single token, not handling contextual inference. AURA studies how agents with web search can re-identify individuals by piecing together weak contextual clues, evaluating on interview transcripts, not code or design data. It supports a finding in escapegate: structure-preserving transforms on numerical tables cannot prevent an audit agent from guessing the industry, because column names and table shape are themselves clues. My finding is an instance of the same phenomenon, not an independent proof.

So novelty must be dialed down. The differences I can claim are only two: the vertical domain (103-item chip scenario annotation set, plus the "structure itself is asset" judgment category), and the inbound half of the closed loop. For the second, I have not verified whether DR-SL's full text contains a corresponding design; for the first, DR-SL's "full task coupling" worst case is adjacent to it, but I am unsure where the boundary lies.

More valuable than the component comparison are the numbers DR-SL honestly reports:

• On the worst-case benchmark (every quasi-identifier is task-relevant), the local gate released 70 of 160 test instances; the external strong attacker still extracted about 0.43–0.49 leakage from those 70. The paper's conclusion: local passage only proves "this evaluator found nothing," not that nothing can be found.
• After adding deterministic hard-wire erasure, literal leakage across 160 instances dropped to 0.000; the same step dropped exact-value utility to 0.000, with an effective auto-release rate of 0%, all going to human. The paper is clear: 0.000 holds only for strict literal scoring and declared attribute probes, not for zero semantic leakage.
• On the mixed-coupling benchmark (120 instances), 67.5% of instances were auto-released by semantic metric with measured literal leakage of zero; the strict metric shown alongside in paper Table 10 is 24.2%.
• The external attacker is a fixed model plus fixed probe templates; the paper does not report results against an adaptively optimized attacker for this system.
• All data is synthetic; none of the four domains includes chips.
• The authors' own caveat: theoretical bounds can certify how much was leaked, never safety ("certify leakage, never safety"); release safety relies on empirical calibration, hard-wiring, and human review.

Viewed together, the symmetry is clear. In DR-SL's worst case, "erase everything" buys 0.000 at the cost of utility also going to zero; escapegate's L3 buys zero leakage by "never leaving the intranet," leaving utility for the internal private model. Both paths say the same thing: context that the task cannot do without, once released, is leakage.

For the numbers on the escapegate page, first what they are. The 103 requests are an evaluation set I built for chip design scenarios, with precise entity annotations, so recall and precision can be computed, not just whether classification was correct. Under the "no business blacklist" condition, after adding Chinese NER, entity detection recall rose from 0.226 to 0.959 and precision from 0.464 to 0.942; over-desensitization rate dropped from 8.9% to 0.0%; classification accuracy on the golden set rose from 0.592 to 0.854, on the semiconductor v1 set from 0.735 to 0.974; consistency rate for classifying the same request three times rose from 0.952 to 0.981.

Now what they are not:

• Static. The page states all numbers come from a synthetic evaluation dataset; real detection rates and false positives "can only be given by real requests on a customer's intranet."
• Recall is an average; leakage depends on the worst case. 0.959 means about 4.1% of annotated entities were missed. Among that 4.1%, any could be a project codename—missing one in a single request is enough.
• Stable does not mean correct. A consistency rate of 0.981 means the system rarely contradicts itself; a classifier that consistently errs wrong would have equally high consistency.
• Zero is only a lower bound. The denominator determines what an over-desensitization rate of 0.0% means. With zero occurrences in N observations, the 95% confidence upper bound is approximately 3/N (rule of three); if the denominator is 103 requests, the upper bound is about 2.9%.
• The opponent did not move. The paper The Attacker Moves Second (Nasr, Carlini, Tramèr et al.) used gradient descent, reinforcement learning, random search, and human-guided adaptive attacks to bypass 12 recent jailbreak and prompt injection defenses, with most attack success rates exceeding 90%, even though those defenses originally reported numbers near zero. This paper tested jailbreak and prompt injection defenses, not de-identification; what transfers is the lesson about evaluation methodology: good numbers tuned on a static attack set can be completely different against an attacker who knows the rules.

Two evaluation use cases on the escapegate page (rewritten with generic placeholders), placed side by side, illustrate this contradiction.

The first is an STDF parsing script failing on a file exported from a test machine. The request contains the ATE machine ID, product code, and lot number, but no test patterns or trim tables—test program assets. After codename substitution, it becomes a generic STDF parsing problem; the external agent does not see those three identifiers themselves. Classified as L2, desensitized and released; the external agent completes the task.

The second is an eFuse security configuration register initialization code, asking whether the root key slot lock order is correct, and whether the JTAG unlock challenge should come after OTP read completion. To answer this, the model must see the lock order and register semantics—which are the asset itself. Classified as L3, intercepted immediately, routed back to the internal private model.

The difference is whether the identifiers are part of the question. In the first request, identifiers are incidental; removing them does not affect the answer. In the second, the thing being asked is the thing being protected. "Answerability" and "inferability" are the same context, viewed from opposite ends: the model relies on it to answer; the attacker relies on it to infer.

Two alternative approaches on the page are empirical measurements of this contradiction. Structure-preserving transforms on numerical tables protect the values themselves but do not reduce the audit agent's ability to guess the industry. Multi-MaaS visibility splitting is indeed harder to reverse-infer—the audit confidence drops by 0.146—but only 25% of tasks can be split. DR-SL's worst case is the paper version of the same phenomenon: every quasi-identifier is task-relevant, so nothing can be released.

Once a task is tightly coupled, there are only four ways out, each with a cost:

This table has a corollary: the proportion of tightly coupled tasks in real requests determines whether this system is a release system or a router that directs requests to an internal model. If L3 is the majority, the gateway is essentially a router; if a minority, it is a release system. This proportion is the first number the shadow mode should measure.

This entire section is my reading of the regulations, not legal advice.

First, ITAR's technical data is defined by function. 22 CFR 120.33 defines it as information required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance, or modification of defense articles; paragraph (b) excludes basic science, math, and engineering concepts taught in schools, publicly available information, basic marketing materials, and high-level system descriptions. My reading: the definition turns on the information's use, not whose name is on it—removing a customer name does not remove it from the definition. The exclusions leave a narrow path for "rewriting into a generic question," but how wide that path is, the text does not say; I have found no official interpretation targeting LLM prompts.

Second, the end-to-end encryption safe harbor has a condition. 22 CFR 120.54 requires that decryption means not be provided to any third party; EAR has a corresponding provision, see 15 CFR 734.18(a)(5). Sending plaintext technical data to a cloud model requires the model to read it; I find no usable room in this safe harbor. It runs in the same direction as Purview's "the model cannot decrypt": cannot decrypt, therefore safe, and therefore useless.

Third, EAR's classification of PDKs. UC San Diego's Research Compliance Office (page noted as updated October 9) PDK guidance states: PDKs on the control list fall under 3E001 or 3E991, those not meeting parameters are EAR99; both categories of PDK require a Technology Control Plan (TCP) with access restrictions; 3E001 has licensing requirements for all non-US persons except Canada, 3E991 only for Cuba, Iran, Syria, North Korea; PDKs are often foundry-proprietary and may be bound by NDA; using EDA software with a controlled PDK typically constitutes a release requiring a license; some open-source PDKs are in the public domain. This is a university's compliance statement, not a BIS document. escapegate classifying "PDK rule values" as L3 aligns with it.

As for AI, the authorities have not yet spoken. A December 2025 Just Security article (two authors from the Law Reform Institute) says DDTC and BIS have yet to issue authoritative guidance on this. That piece discusses whether model outputs count as technical data exports, arguing that closed-source model developers and deployers are most likely to be deemed "exporters"—the opposite direction from prompt outbound transmission; I cite it only to establish the "no guidance" point. Whether foundry NDAs contain AI-specific clauses, or how TSMC and similar companies regulate internally, this article has not verified.

The consequence of having no guidance is very practical: companies must write their own Technology Control Plans and prove their controls are effective. In my view, release logs, hard rules, and spot-check records will serve as evidence for those plans.

escapegate's audit agent plays this role: an independent vendor account's agent, acting as an "external snooper," reads the desensitized text, tries to reverse-infer the industry, company, and business, and gives a confidence score; the confidence score is weighted with rule hit count and consistency signals (aggregated across sessions) to determine release, human review, or rewrite rejection. The page itself notes that the scoring formula and consistency signals have known limitations. It is the heaviest judgment in the entire chain, and also the least independently tested. I can think of at least four failure modes.

First, local auditing can miss things. DR-SL's 70/160: instances passed by the local gate, where the external attacker still extracted 0.43–0.49. The paper also notes one reason: the local evaluator, encountering enumerable residual values, answered "unknown."

Second, the attacker is fixed. The lesson from § 05 applies again: DR-SL's external attacker is a fixed model plus fixed templates; escapegate's audit agent is also a fixed prompt. Against an adaptive adversary, average detection rate does not equal safety.

Third, auditor and audited may share the same origin. The page states that the public demo collapses classification, auditing, red-teaming, and external agent into the same model API, losing the "cross-vendor visibility decomposition" diversity of the original design. Whether same-family models have correlated blind spots, I have not tested—this is an assumption. But "verifier and generator sharing blind spots" is a problem every design that uses a model to audit a model must face.

Fourth, auditing itself may be an outbound transmission. Per the page description, the audit agent uses an independent vendor account; it reads text after rewriting but before release, including candidates that are ultimately rejected and sent for rewriting. If these texts are never released, they have already been seen by an external account. DR-SL's handling of this is to place the external re-test in the same trust category as the destination cloud, adding no new party. This point I derived from the design description; it depends on the audit agent's actual deployment (see pending verification at end).

So who audits the auditor? No "higher auditor" can terminate this problem—the auditor's auditor would also miss things. What can be done is to stack several qualitatively different checks whose failure modes are uncorrelated:

1. Deterministic hard rules before any LLM. L3 short-circuits; credential interception does not depend on any model's judgment. DR-SL also has a "hard wire."
2. Known-answer calibration. Mix synthetic, watermarked sensitive items (fabricated lot numbers, fabricated project codenames) at known ratios into copies of shadow traffic, and count how many the audit agent misses. This is one of the few ways to directly measure the auditor's false negative rate.
3. Rule-aware adaptive red team. Give the attacker the audit prompt, rules, and thresholds, and have them construct inputs that "pass audit yet leak." The passing standard is not average detection rate, but finding zero instances.
4. Human spot-checks of released samples. Two people judge independently; zero findings are read by the upper bound. Simultaneously monitor human fatigue: Meta called out blind confirmation; in Invariant's case, many users selected Always Allow. There is an upper limit on review rates; beyond it, review becomes rubber-stamping.

None of these four layers is a new invention, and together they still cannot answer "is it safe?"; they only answer "under these attack types, how quickly can we discover we were wrong." The DR-SL authors are saying essentially the same thing: release safety relies on empirical calibration, hard-wiring, and human review.

The escapegate page describes the next step as "intranet shadow mode": first record only, do not release externally, quantify with real requests, then decide whether to open the external route. Easy to write; hard to design. Below is my proposal; it has not been run.

Run the full pipeline, weld the exit shut. Classification, desensitization, and auditing all run; release decisions are produced as usual; the external route is closed. This is not my invention: Purview's documentation also suggests running DLP policies in simulation mode first, to see the impact on users before going live.

Shadow logs are the new most sensitive dataset. They simultaneously store original text, rewritten text, and audit results. Keep them on the intranet with separate access permissions and short retention periods; do not let them become the next leak source.

Measure three numbers first.

• Classification distribution: what proportion of real requests fall into L0 through L3. This determines whether it is a release system or a router.
• Post-release residual: for requests classified as "releasable," sample them and have two humans (not the audit agent) independently judge what the rewritten text still leaks. Zero findings must be read by the upper bound, 3/N; 300 zero-leakage observations are needed to claim below 1%.
• Answerability: for the same batch of released samples, have the internal private model answer from the original and rewritten text respectively, and compare answers. DR-SL measures utility using the same approach: answer questions with both original and dehydrated text, then compare.

Test the auditor separately. Use § 08's planted set to measure the false negative rate; report it independently, do not mix it into release metrics.

Open in phases, each with exit conditions and circuit breakers.

What shadow mode cannot measure. First, user behavior: knowing a gateway exists, people will phrase things differently; shadow-period distribution may not match post-launch distribution. Second, adaptive attackers: this requires separate red-teaming. Third, the return path: shadow mode does not release externally, so it cannot observe what the external agent's output might bring back; inbound scanning must be drilled separately.

• No real intranet traffic. escapegate's numbers come from a synthetic evaluation set; DR-SL's do too. What real requests look like, I do not know.
• Of the four audit failure modes, only the first two have external data support. The third and fourth are derived from the design description, not empirically tested.
• Shadow mode is a design, not a result. Phases, sample sizes, and planted-set methodology have not been validated.
• Regulations are my reading. There is no authoritative DDTC or BIS guidance on AI; I have also not verified foundry NDA texts.
• Evidence has moisture. Purview, Cloudflare, OpenAI, Anthropic, NVIDIA, and Siemens documents all describe their own products; PixelLeak and Comment and Control are second-hand retellings of researcher disclosures, and affected organizations in the former were not named; DR-SL is a preprint; Samsung's three leaks were retold by CIO Dive from Korean media, and this article has not verified the original Korean text.