Cloud OCR fallback (zero retention)

The four guarantees

• The image is never written to disk by Northbeams. Our cloud OCR endpoint reads the bytes into one in-memory buffer, hands them to AWS Bedrock, and drops the buffer when the response returns. No filesystem write. No Vercel Blob. No R2. No Firestore. No Sentry attachment.
• AWS Bedrock and Anthropic retain nothing, by contract. Bedrock runs Anthropic models with zero data retention by default. We do not enable CloudWatch request/response body logging. The image exists in vendor memory only long enough to produce the response.
• Every cloud OCR call creates an audit-log entry. Your workspace admin sees the call: timestamp, user, image size, SHA-256 hash, engine, and how much text came back. The bytes never appear in the audit log.
• Covered by AWS's standard BAA for HIPAA workloads. Healthcare workspaces that need OCR on handwritten clinical notes or scanned faxes can opt in without a separate vendor BAA.

How a single upload travels

1. The user drags a screenshot into ChatGPT in their browser. The Northbeams extension intercepts it.
2. The extension reads the image bytes locally. They never leave the browser at this step.
3. The extension tries Tesseract.js (on-device OCR) first. If the result is confident, the image bytes are discarded right there. No cloud call is made.
4. If Tesseract returns low confidence (typical on dark-mode code screenshots, low-contrast UI captures, or handwriting), and the workspace admin has enabled cloud OCR fallback, the extension forwards the bytes to monitor.northbeams.com/api/extension/ocr. TLS in transit.
5. Our endpoint validates the workspace tier and per-org consent again, hashes the bytes (SHA-256, for the audit log only), and calls AWS Bedrock's Anthropic Haiku model. The bytes live in one Uint8Array; nothing else references them.
6. Bedrock returns the extracted text. Our endpoint writes the audit-log entry (hash, size, engine, text length), drops the bytes, and returns the text to the extension.
7. The extension runs the same on-device classifier on the returned text. If a finding fires, an incident lands on your dashboard with the "Cloud OCR used" engine label.

What is logged

• SHA-256 hex of the image bytes (so an admin can correlate a specific audit entry to a specific upload event without storing the image itself).
• The image's byte size and media type.
• The OCR engine identifier (currently bedrock-haiku-4-5).
• Bedrock-reported token usage (for your cost trend dashboards).
• The length of the extracted text (so you can spot calls that returned nothing useful).
• The user who triggered the call, server-verified from their extension key.

What is NOT logged: the image bytes themselves. The extracted text itself (it lives only on the resulting incident document, redacted by the classifier the same way typed prompts are).

Defaults and consent

Cloud OCR fallback is off by default on every workspace, even on Sentinel and Fleet plans.

An admin must explicitly toggle it on under Settings → Workspace. We will not call the cloud OCR vendor without that consent. The /api/extension/ocr endpoint re-checks the workspace tier AND the per-org toggle on every request, so a client misconfiguration cannot bypass it.

Audit log

Every cloud OCR call surfaces in Enforcement log. Workspace admins can review which uploads transited through the OCR vendor, by user and by time window.