# Controlled release — source dossier and claim boundaries

**Research ID K05 · Checked 2026-09-21 · Supports [C5](/blog/private-context-public-output).** Primary literature plus original conditional design analysis. No runtime reproduction, private-source processing, security result or customer validation.

**Public copy prepared 2026-10-22.** Pins re-checked: arXiv 2503.18813v2 (CaMeL, 24 June 2025; §3 Threat Model, §5 CaMeL Design, §9.2 De-classification and user fatigue present) and arXiv 2506.08837v3 (Design Patterns, 27 June 2025; §§3–5 present); the companion fixture SHA-256 recomputed locally and unchanged. Not re-checked: the papers' body text beyond section presence and dates.

## Bibliography and provenance

### K05-1 — CaMeL

Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis and Florian Tramèr. *Defeating Prompt Injections by Design*. arXiv:2503.18813v2, **June 24, 2025**; first submitted March 24, 2025. [Versioned text](https://arxiv.org/html/2503.18813v2), [revision record](https://arxiv.org/abs/2503.18813v2). Primary research. Checked September 21, 2026; inspected §§3, 5, 6.2, 7 and 9.

Direct observations: policy checks occur at tool calls; trusted prompt/memory assumptions and declassification limitations are explicit. See the article's compact source summary. Confidence: high for the documented design; no independent evaluation here. Source does not validate our artifact workflow. Refresh before claiming implementation coverage, numeric performance or a newer correction.

### K05-2 — Design patterns

Luca Beurer-Kellner, Beat Buesser, Ana-Maria Creţu, Edoardo Debenedetti, Daniel Dobos, Daniel Fabian, Marc Fischer, David Froelicher, Kathrin Grosse, Daniel Naeff, Ezinwanne Ozoani, Andrew Paverd, Florian Tramèr and Václav Volhejn. *Design Patterns for Securing LLM Agents against Prompt Injections*. arXiv:2506.08837v3, **June 27, 2025**; first submitted June 10, 2025. [Versioned text](https://arxiv.org/html/2506.08837v3), [revision record](https://arxiv.org/abs/2506.08837v3). Primary design analysis. Checked September 21, 2026; inspected §§3–5, particularly data restrictions and coding-task tradeoffs.

Direct observation: the paper compares isolation patterns and applications, with conditional assumptions. It does not supply a measured ranking of the three designs in our article. Confidence: high for the framing; deployment suitability unvalidated. Several authors overlap with K05-1; these are not independent replications. Refresh if an empirical comparison or correction changes the design choice.

## Original analysis and assumptions register

| ID / claim | Basis: observed versus inferred | Confidence / limitation | Decision affected / refresh trigger |
|---|---|---|---|
| K05-A: the small reviewed artifact is the starting recommendation | Original inference for one fictional compatibility note; no measured superiority | Moderate engineering judgment; low evidence about operating cost | Compare with manual baseline when a real authorized workflow exists |
| K05-B: this task needs private information | Fixture expressly places the new facts only in the internal change record | True by fixture construction; says nothing about prevalence | Remove private access if actual public material is sufficient |
| K05-C: two facts are releasable | Fictional release policy, not a research finding or model classification | No real authorization | Requires actual accountable release owner before adapting to real data |
| K05-D: smaller package reduces review burden | Hypothesis; could instead require costly source reconstruction | Unvalidated; do not claim time saved | Observe reviewer time, corrections and missing context |
| K05-E: exact-envelope enforcement prevents substituted operations | Conditional requirement of proposed publisher, not implemented capability | Requires inspection of adapter, identity, state, serialization and all output paths | Do not publish if enforcement/receipt coverage is unknown |
| K05-F: provenance enforcement could suit repeated workflows | Architectural option, no product or business commitment | Cost and utility unknown | Revisit only after repeated measured boundary/review burden |

## Editorial claim review

- The SDK, all private inputs and policy are explicitly fictional. The companion's digest is calculated from a local fixture; no approval, attack or deployment occurred.
- Public body, destination, operation and metadata are separate. A digest is not authorization and cannot judge semantic disclosure.
- Human error, implicit identity disclosure, model-provider handling, telemetry, timeouts and concurrent destination changes remain explicit limits.
- Article contributes a permitted-release design; C1's access/authority distinction supplies context rather than another retelling of the GitHub incident.
- The simple artifact is an alternative to a larger implementation, not an instruction to build one. Evaluator and commercial format stay unchanged.
- Acceptance cases state required observations, never completed results. Source papers do not support a current-product guarantee, a market-demand claim or a measured production benefit.

## Next evidence that desk research cannot provide

Use the [worked record](/resources/controlled-release-record.md) on an authorized synthetic workflow. Observe whether an engineer can locate the release decision, establish reviewer authority, distinguish integrity from disclosure review and reconcile uncertain delivery. Then measure how much private context real review requires. More generic prompt-injection papers cannot establish those workflow-specific facts.