## TL;DR
Internal notes leak into public replies when the drafting agent treats the whole ticket as source material without distinguishing audience. Separate internal and public content at the data level, run a pre-send guard that checks every reply against the internal-note store, and make the public reply composer unable to see internal notes at all. The strongest guard is architectural: the composer never receives what it must not send.

## The query

```text
support agent leaking internal notes into public reply: redaction guard
```

## Use this when

- Internal notes appear in customer replies
- Agents paste internal context into public responses
- You are building reply guardrails
- Auditing reply safety

## Not for

- Internal note-taking practices
- Role-based access control design
- DLP product selection
- Email security

## Steps

### 1. Tag every ticket entry by audience at creation

Internal notes, public replies, and private agent messages get an explicit audience tag when written. Audience is a property of the content, not a guess at send time. Backfill tags on historical data where feasible.

Expected output: audience-tagged ticket history.

### 2. Keep internal notes out of the reply composer's context

The drafting agent's context includes public history and ticket fields, not internal notes. If the composer never sees internal notes, it cannot leak them. This is the architectural fix; everything else is a backstop.

Expected output: composer context excludes internal notes by construction.

### 3. Run a pre-send similarity guard

Before sending, compare the draft against internal notes for verbatim or near-verbatim overlap. Flag matches for human review. The guard catches the cases where internal context legitimately informed the draft but should not be quoted.

Expected output: overlap flagged before send, never after.

### 4. Require explicit human approval on flagged drafts

A flagged draft does not send until a human clears it. The human sees what matched and decides: rephrase or confirm safe. Approval is per draft, not a blanket bypass.

Expected output: flagged drafts held for human decision.

### 5. Audit sent replies for leaks

Sample sent replies and check against internal notes. Track the leak rate. A non-zero rate means the guards are leaking; investigate the bypass path rather than adding more guards blindly.

Expected output: a leak-rate metric with investigation on misses.

## Template: the checklist

```text
Internal note leak prevention:
[ ] Ticket entries audience-tagged at creation
[ ] Reply composer context excludes internal notes
[ ] Pre-send similarity guard against internal notes
[ ] Flagged drafts require human approval
[ ] Sent replies sampled for leak rate
```

## Variant phrasings

### internal note sent to customer

Steps 1 and 2. Tag the content, blind the composer.

### agent pasted private note in reply

Steps 3 and 4. Guard plus human approval.

### preventing data leaks in ai replies

Full sequence as the defense-in-depth design.

## Why it happens

Agents are helpful: given internal context, they use it, including phrasing that was never meant for customers. The leak is not malice; it is the model doing its job with too much context. Audience separation at the data level is the fix because it removes the temptation structurally.

## Edge cases

- Summaries of internal threads: a public summary of an internal discussion is legitimate but must be rewritten, not quoted. The guard should flag quotes, allow paraphrase.
- Merged tickets: internal notes from the merged ticket carry their tags. Verify tags survive merges.
- Agent-to-agent handoffs: internal context must flow to the next agent but never to the customer. Two channels, strict separation.
- Legal holds: some internal notes must be preserved exactly. Redaction guards must not delete source notes, only block them from replies.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GQf9R_MaIYja63jGT2Nn5Q