Private context, public output: where should the release decision live?

For engineers designing an agent that reads private material and publishes something derived from it, and the release owners asked to sign off on what leaves.

An agent needs to write a public compatibility note for an SDK. The implementation details are private. Some of those details must become public for anyone to use the release. The SDK, private notes and release decision below are fictional; no integration or defense has been tested.

“Never let private data leave” prevents the task. “Summarize it without secrets” leaves the release decision inside the same model that reads the private material. The useful question is narrower: which information may cross this boundary, who can authorize it, and what prevents a different artifact from crossing instead?

This is where an access review becomes a release design. Giving an agent permission to read the implementation does not settle what it may publish. But withholding all access does not produce the compatibility note either.

One task, two releasable facts

Consider a fictional Example SDK 2.4. Its internal change record contains five items:

1. The configuration key changes from timeout_ms to request_timeout_ms.
2. The default remains 30,000 milliseconds.
3. A private customer's integration motivated the change.
4. An internal benchmark contains unreleased performance figures.
5. A proposed launch date has not been approved for announcement.

The release owner permits the first two facts to appear in the public compatibility note. The other three remain internal. That permission is part of our example, not a capability we assume the model can infer from the document.

A successful note tells a developer what to change and what default to expect. It does not name the customer, reproduce the benchmark, announce a date or invent a broader compatibility guarantee.

Our exact candidate artifact is deliberately small. The worked release record specifies its destination and operation. Neither file records a real approval or deployment.

A summary is a transformation, not permission

Suppose the agent removes customer names but writes: “This fixes the timeout problem reported by our only regional bank customer.” The identity may still be inferable. Suppose it rounds the internal benchmark numbers. That is still a release of performance information. Removing citations or changing the wording does not establish permission to disclose the underlying facts.

For this design, derived text stays internal until the release decision says otherwise. This conservative rule can overrestrict harmless text. That is precisely why the workflow needs an explicit way to authorize a limited release.

CaMeL offers a research example of separating control from data and checking tool calls against policies using tracked provenance. Its threat model assumes a trusted user prompt and uncompromised memory. It discusses declassification and user fatigue, and excludes some text-only deception from its protection goals. These are conditions on the research, not guarantees for our proposed workflow. Debenedetti et al., 2025, §§3, 5 and 9 (opens in a new tab)

We take a narrower design lesson: a label matters when something outside the model enforces it. A transcript saying “private” is not that enforcement.

Three ways to arrange the work

The first option is appropriate if existing public documentation answers the question. Here it does not. The private change record is the source of the new compatibility information.

The third may be appropriate for repeated work across many sources and destinations. It is also a substantial integration commitment. The Design Patterns paper treats isolation as several architectures with different assumptions and tradeoffs; it does not provide a universal winner for private-to-public tasks. Beurer-Kellner et al., 2025, §§3–5 (opens in a new tab)

For one compatibility note, start with the second option. This is an engineering recommendation to test, not a measured ranking.

Put the decision at a small, inspectable boundary

The proposed flow is:

Private change record + untrusted issue text
                  |
          internal drafting stage
          no publishing credential
                  |
       candidate note remains internal
                  |
       authorized release-owner review
       exact content + destination + operation
                  |
         fixed publication artifact
                  |
       constrained publishing operation
       receipt checked against the decision

The reviewer examines both the candidate and enough private evidence to establish its accuracy and release eligibility. A model's assertion that the note is safe does not substitute for that decision.

The next stage receives the fixed artifact, not the entire drafting conversation. It does not regenerate the note from the private sources. For this small task, it can be a deterministic publisher rather than another agent. If a person publishes manually, that person's copy step and resulting page still need checking.

In our example, the operation creates one page at a predetermined public documentation location. The title, body and page metadata form the reviewed package. The publisher receives neither the private benchmark nor a general instruction to “finish the release.”

The boundary must cover every relevant output path. A drafting stage that cannot publish but sends its whole prompt to an unapproved logging service has already crossed another boundary. The model endpoint, logs, caches and review workspace therefore need their own authorized handling. This article does not establish that any particular service meets those requirements.

Bind the permission to the thing that leaves

The release decision says what may leave. The approval analysis examines how a tool integration preserves that decision through edits and execution.

The decision should identify an immutable artifact or exact bytes, the destination, the operation and the authorized reviewer. It also needs a validity condition: for example, the release remains eligible and the target page has not changed since review.

A digest can detect a change to the reviewed bytes. It cannot decide that the bytes are appropriate, identify an authorized reviewer, or stop the publisher from sending something else. Those responsibilities belong to the surrounding system.

If the note changes after review, stop and obtain a new decision. If the destination changes from documentation to an external issue, stop. If the publisher adds an attachment or generated metadata, the reviewed package is incomplete. If a request times out after transmission, inspect its receipt or destination state before retrying; absence of a response is not evidence that nothing happened.

The permitted operation is narrower than general write access. A credential may technically allow many writes while the release decision permits one. Keeping those two facts separate makes the integration review useful.

Preserve usefulness in the acceptance criteria

Rejecting every candidate would satisfy a crude “no private disclosure” measure. It would also fail this task. Conversely, publishing a correct key rename together with an internal customer note would complete the visible documentation change while violating the release constraint.

A future test needs to observe both outcomes on the same attempt:

• Can a reader determine the required key rename and unchanged default?
• Did only the permitted package reach the permitted destination?
• What review, correction or manual recovery was required?
• Do receipts and inspected outputs support that conclusion, or is the outcome unknown?

The companion record includes proposed cases for an ordinary release, a paraphrased customer disclosure, an unsupported compatibility claim, a changed destination and an ambiguous retry. It records expected behavior, not test results. Cost, latency and reviewer effort remain unmeasured.

A useful counterexample would be a legitimate note that routinely requires so much private context to review that the small handoff stops being small. Repeated blocked releases, lengthy reconstruction or frequent post-review changes would justify reconsidering the design. They would not justify quietly treating every generated summary as public.

Keep the release decision visible

Our recommendation for this bounded task is a reviewed artifact with a constrained publishing step. It limits what the final stage needs to know and gives the reviewer a concrete decision.

That may be too manual for a high-volume documentation operation. Before adopting broader provenance enforcement, measure the repeated burden and identify the transformations it must cover. The more ambitious architecture should answer an observed need.

Security here is not the absence of useful disclosure. The task requires disclosure. The design succeeds only if it makes the permitted disclosure possible while preserving the boundary around everything else.

---

Use the example: worked release record and proposed acceptance cases. Source dossier: bibliography, claim boundaries and refresh triggers. This article makes no current-product efficacy claim and reports no completed release experiment.