Document Review

Human-gated document anonymization for the moments PII pseudonymization alone isn't enough — contracts, HR files, legal review. The AI gets a review handle, a human releases in the browser, only the anonymized text egresses.

The shape of the flow

An AI client that needs to work with the content of a document asks the gateway for a review, not for the document itself. The gateway:

Fetches the document server-side (using the calling user's own Drive connection — no shared credential).
Extracts the text. For a scanned PDF with no text layer, an opt-in local OCR pass runs inside the gateway's trust boundary (see below).
Detects sensitive terms: company legal-form anchors, tenant vocabulary, validated structured entities (emails, IDs, phone numbers, addresses).
Parks the raw text and the detected terms behind an encrypted, TTL-bound review handle.
Returns to the AI only the handle, the detection counts, and a browser review link for the user — never the document text, never the detected terms.

The user opens the review link in the browser, sees the redactions the gateway is about to apply, adjusts anything they want, and clicks release. From that moment the AI can call fetch_reviewed to receive the anonymized text — once. Before release the same call returns PENDING_REVIEW.

The document content and the detected terms never enter the AI conversation channel. What the AI can see is the anonymized text the human explicitly released, and nothing more.

Tools the AI client sees

Tool	What it does
`document_review_write_actions`	`prepare_review`: start a review from a Drive `file_id`. `cancel_review`: discard a pending handle.
`document_review_read_actions`	`review_status`: state of a handle (`pending_review` / `released` / `rejected`) plus detection counts. `fetch_reviewed`: the anonymized text after human release — returned once, only once, and only after release.

The tools are hidden by default. The operator opts in via Services → Document Review. Once active, they appear in the AI client's tool list like any other service.

Why the AI does not receive the text directly

PII pseudonymization (covered on the compliance page) already substitutes names / emails / IDs at the field level for regular tool calls. That is enough for the everyday case — a Jira issue, a Slack message, a calendar event. Whole documents are different:

A contract's structure carries meaning: which clause got redlined, whose signature block is missing, which annex is referenced. Field-level pseudonymization can't preserve that structure and simultaneously anonymize every reference.
Legal-form anchors ("…GmbH", "…Inc.", "…LLC") and tenant vocabulary are context-specific — what needs to be scrubbed on one deployment leaks perfectly innocuously on another.
The human reading the document is often the only reliable classifier for what is sensitive in that specific document. A regex pass over "let the model do the work" is exactly the failure mode this feature avoids.

The design consequence: the AI never gets the document at all until a human has explicitly said the anonymized version is safe to release.

Detection: what the gateway looks for

Three categories of sensitive terms are surfaced to the human reviewer:

Legal-form anchors — company suffixes (GmbH, AG, Inc., LLC, Ltd., …) and the tokens around them; the human decides whether to keep the company name in the anonymized text or strip it.
Tenant vocabulary — operator-configured protected-term lists (customer names, project codenames, internal system identifiers). Configured at General → Document Review.
Validated structured entities — emails, phone numbers, IDs, addresses; validated (not just regex-matched) so a random 10-digit number isn't over-flagged.

Detection is proposed to the human, not enforced silently. The review page shows every hit, in context, with the option to accept, adjust, or reject each.

OCR for scanned PDFs

A scanned PDF has no text layer. Without OCR the extraction returns nothing and the review can't happen. Two rules:

Off by default. A prepare_review on a scanned PDF returns SCANNED_PDF_OCR_AVAILABLE; the AI has to ask the user, and the user has to pass allow_ocr: true explicitly on the retry. No silent OCR.
Runs inside the gateway. When enabled, OCR runs against a local engine inside the gateway's trust boundary — the document does not travel to a third-party OCR service, it stays in the same perimeter as the pseudonym mapping.

A page cap applies to the OCR pass; a document over that cap fails closed rather than partially OCR'd (a partial extract is worse than no extract, because the human wouldn't know which sensitive terms are hidden in the missing pages).

Storage and TTL

The parked text and the detection results are encrypted at rest with a per-handle key and evicted on a bounded TTL (default 24h). Nothing about the document survives that window in gateway storage. If the human hasn't released within the TTL, the handle simply expires and the AI has to start a new review.

Setup

Sidebar → General → Document Review. The panel exposes:

Feature toggle — off by default; flip it to activate the tools.
Protected-term lists — tenant vocabulary (customer names, project codenames, internal identifiers) the reviewer should see flagged. Adjust anytime.
OCR settings — the page cap for scanned PDFs, and a status indicator for whether the local OCR engine is available.
Active handles — live view of pending reviews with subject, requester, TTL, and revoke.

The service also has to be enabled once on the Services page (like every gateway-native tool: hidden by default until the operator opts in).

What this is not

Not a replacement for field-level PII pseudonymization. The two work together: pseudonymization handles the everyday tool traffic; document review handles the "whole document with structure" case.
Not automatic. The whole point is the human review gate. There is no "auto-release" or "trust the model" mode.
Not a token vault for the source system. The document is fetched using the calling user's own Drive connection — the gateway holds no shared "super-reader" credential for Drive.
Not multi-source today. Google Drive is the source of the initial version; additional source services land as concrete use cases arrive.

Compliance — PII pseudonymization, audit log, the throughput view; document review sits alongside these as the "whole document" case.
Context Map — sibling gateway-native governance feature (same design shape: hidden by default, operator-opt-in, admin-configured, AI-facing tool).
Audit Log — every prepare_review, human release, cancellation, TTL expiry lands here.
Access Model — roles decide who can act on Drive at all; document review inherits that.