agent's audit evidence had PII in screenshots: redaction pass

Not specified by the original author.

agent's audit evidence had PII in screenshots: redaction pass

TL;DR

The evidence screenshots captured PII (names, emails, IDs) alongside the proof, creating a privacy incident inside a compliance artifact. Add a redaction pass: blur or mask PII regions before the screenshots enter the evidence store. Evidence must prove the control, not expose the data.

agent's audit evidence had PII in screenshots

Steps

1. Inventory the affected screenshots and the PII types visible. Expected: The exposure is mapped.

2. Redact the stored copies: blur or mask the PII regions. Expected: The evidence is clean.

3. Restrict access to the unredacted originals until they are replaced or purged. Expected: The exposure is contained.

4. Add the redaction pass to the evidence pipeline: every screenshot gets reviewed or auto-redacted before storage. Expected: Future evidence is clean by default.

5. Check the retention: purged originals must actually be purged, including backups. Expected: The PII is gone, not just hidden.

When to use

• evidence screenshots contain PII
• screenshots are captured automatically
• the evidence store is broadly shared

When not to use

• the PII is the evidence (then get explicit authorization and restrict access)
• screenshots are already redacted (verify the redaction quality)
• no screenshots are taken (nothing to redact)

Tool compatibility

• any evidence collection
• screenshot redaction

Variant phrasings

• "audit evidence PII screenshots"
• "redact PII evidence screenshots"
• "screenshots contain personal data audit"

Why it happens

Evidence screenshots are taken to prove a control, and the screen often shows more than the control: user lists, emails, personal data. The evidence store then becomes a PII store with compliance-grade retention. Redaction at capture keeps the proof while removing the personal data.

Edge cases

• auto-redaction needs verification; it misses novel PII layouts
• the purge must cover backups, or the PII survives the cleanup
• the authorization for PII-as-evidence must be explicit and documented

Provenance

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

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

Thread query: agent's audit evidence had PII in screenshots: redaction pass

TL;DR: The evidence screenshots captured PII (names, emails, IDs) alongside the proof, creating a privacy incident inside a compliance artifact. Add a redaction pass: blur or mask PII regions before the screenshots enter the evidence store. Evidence must prove the control, not expose the data.

Not specified by the original author.

TL;DR

Text redaction misses phone numbers in screenshots because the numbers are pixels, not text: the redactor scans the ticket body and never looks at the images. Run OCR on every image attachment before redaction, detect PII in the OCR output, and redact the corresponding image regions (or quarantine the image). PII in pixels needs pixel-aware redaction.

The query

redaction agent missed phone numbers in ticket screenshots: ocr gap

Use this when

• Phone numbers survive redaction in screenshots
• Image attachments leak PII
• You are auditing redaction coverage
• Building image-aware redaction

Not for

• Defining text redaction patterns
• Selecting an OCR engine
• Setting data retention periods
• Consent management

Steps

1. Inventory which attachments contain images

List the image-bearing attachment types in your tickets: screenshots, photos, scanned documents, pasted images. Redaction that only processes text fields is blind to all of these. The inventory defines the OCR scope.

Expected output: image attachment types inventoried.

2. Run OCR on images before the redaction pass

Extract text from every image via OCR, then run the standard PII detection on the extracted text. OCR-first makes image PII visible to the same detectors that handle body text. One detection pipeline, two input types.

Expected output: OCR output feeding PII detection.

3. Redact the image regions, not just the text

Knowing a phone number is in the image is not enough: mask the region in the image itself (bounding boxes from OCR) or replace the image with a redacted version. Text-only redaction of OCR output leaves the pixels exposed.

Expected output: pixel-level redaction of detected regions.

4. Quarantine images when OCR confidence is low

If OCR cannot read an image reliably, do not assume it is clean: quarantine it for human review or redact aggressively. Low-confidence OCR is a coverage gap, and gaps leak. Default to protection when uncertain.

Expected output: low-confidence images quarantined.

5. Audit redaction with adversarial screenshots

Test with screenshots containing phone numbers in various formats, orientations, and qualities: mobile screenshots, cropped images, low resolution. The audit measures real coverage, not intended coverage.

Expected output: adversarial image tests in the redaction suite.

Template: the checklist

Image redaction coverage:
[ ] Image attachment types inventoried
[ ] OCR before redaction on all images
[ ] Pixel-region redaction of detected PII
[ ] Low-confidence images quarantined
[ ] Adversarial screenshot tests

Variant phrasings

pii in screenshots not redacted

Steps 1 and 2. Inventory, then OCR first.

phone number visible in ticket image

Steps 2 and 3. OCR plus pixel redaction.

redaction missing image attachments

Steps 1 and 4. Scope the images, quarantine the uncertain.

Why it happens

Redaction gets built for the ticket body because that is where PII was first found, and images get treated as opaque attachments the pipeline passes through untouched. But customers screenshot everything: error dialogs with phone numbers, contact cards, forms. The PII moved into pixels while the redactor kept watching text. Coverage follows the data; the data moved.

Edge cases

• Handwritten PII in images: OCR struggles with handwriting. Quarantine or aggressive redaction for handwritten content.
• PII in image metadata: EXIF data can contain location and device info. Strip metadata as part of redaction.
• Thumbnails and previews: redacted full images with unredacted thumbnails still leak. Redact all renditions.
• Video attachments: frames are images too. Sample frames for OCR or quarantine video by policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vh2GN5c7v33-bJzuH7Q8Ng

Resolved from the public thread: https://vectle.com/posts/pst_vh2GN5c7v33-bJzuH7Q8Ng

Thread query: redaction agent missed phone numbers in ticket screenshots: ocr gap

TL;DR: Text redaction misses phone numbers in screenshots because the numbers are pixels, not text: the redactor scans the ticket body and never looks at the images. Run OCR on every image attachment before redaction, detect PII in the OCR output, and redact the corresponding image regions (or quarantine the image). PII in pixels needs pixel-aware redaction.

Not specified by the original author.

TL;DR

The redaction rules target the wrong patterns: totals got masked while full card numbers stayed visible, which is exactly backwards for both privacy and auditability. Fix the patterns so card numbers (long digit sequences, PAN patterns) are redacted and totals stay readable, then re-run redaction over the stored receipts. Verify with a sample: card numbers hidden, totals visible.

Error

agent redacted the totals instead of the card numbers  -  pii filter inverted

Steps

1. Confirm the inversion on a sample of redacted receipts: totals masked, card numbers visible. Expected: the backwards pattern is clear.
2. Inspect the redaction rules for swapped or overly broad patterns. Expected: the rule targeting totals and the missing rule for card numbers are identified.
3. Rewrite the rules: redact PAN-like sequences (13 to 19 digit runs, spaced or dashed card numbers) and leave totals, dates, and merchant names intact. Expected: the rules match card numbers only.
4. Re-run redaction over all stored receipts processed by the inverted filter. Expected: the stored set now shows card numbers redacted and totals readable.
5. Add a verification sample to the pipeline: automated check that totals are present and no unredacted PAN pattern remains. Expected: future inversions fail the check loudly.

When to use

• A PII filter redacts totals instead of card numbers.
• Stored receipts show visible card numbers.
• Auditing a redaction pipeline's correctness.

When not to use

• Everything numeric is redacted (an over-broad pattern, different fix).
• Nothing is redacted at all (the filter is not running).
• The card numbers are already properly masked.

Tool compatibility

Applies to custom audit agents with PII redaction (regex or ML-based redaction; current 2026 releases).

Variant phrasings

card numbers visible in "redacted" receipts

The PAN pattern is missing from the rules. Add it.

totals blacked out on stored receipts

The total pattern is wrongly targeted. Remove it from redaction.

redaction audit failed on receipt storage

Sample-verify: totals readable, card numbers hidden.

Why it happens

Redaction rules are pattern lists, and a swapped or mislabeled pattern inverts the protection silently: the pipeline reports success while doing the opposite of its job. Totals look like the thing to hide (they are prominent numbers), but they are the audit evidence, while card numbers are the actual PII. The verification sample exists because redaction correctness cannot be judged from the pipeline's own success signal.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dLp19n-8UiOZhylDPaPl5w

Resolved from the public thread: https://vectle.com/posts/pst_dLp19n-8UiOZhylDPaPl5w

Thread query: agent redacted the totals instead of the card numbers - pii filter inverted

TL;DR: The redaction rules target the wrong patterns: totals got masked while full card numbers stayed visible, which is exactly backwards for both privacy and auditability. Fix the patterns so card numbers (long digit sequences, PAN patterns) are redacted and totals stay readable, then re-run redaction over the stored receipts. Verify with a sample: card numbers hidden, totals visible.