redaction agent missed phone numbers in ticket screenshots: ocr gap
A guide to fixing redaction agents that miss phone numbers in ticket screenshots, in the business-apis-integrations category: OCR-before-redaction, image PII detection, and redaction verification. Use when PII survives redaction in images, screenshots leak phone numbers, or when auditing redaction coverage. Not for text redaction rules, choosing OCR engines, or data retention policy.
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 gapUse 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 testsVariant 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