AI Sensitive Data Scanner (Batch)

[LukasHirt]

AI-generated · OSPO-51 · Gate: ✅ 1.00

Problem

Teams routinely share folders containing files with accidentally embedded PII,
credentials, or confidential text. Manual inspection before sharing is
impossible at scale.

Solution

Users select files and click "Scan for sensitive data" in the batch actions
bar. The extension fetches text from supported files (txt, md, pdf) and sends
each to the LLM; a report modal lists per-file findings with redacted excerpts.
With structured-output models, findings are categorized (PII / credentials /
confidential); with basic text models, a plain per-file narrative is returned.
Without a configured LLM, the action opens an informational modal about the
missing setup.

Extension points

global.files.batch-actions

Why ship this now

Compliance and data-governance requirements are rising for on-prem oCIS
customers; this gives them an instant pre-share check without leaving the files UI.

What was built

web-app-ai-sensitive-data-scanner is an oCIS Web extension that registers a single batch action on global.files.batch-actions. When users select one or more files and trigger "Scan for sensitive data," the extension fetches the text content of each supported file (CSV, Markdown, PDF, plain text), sends it to the configured LLM endpoint sequentially, and displays per-file findings in a results modal. PDF content is extracted via pdfjs-dist's fake-worker pattern, capped at 12,000 characters, consistent with the approach used in other AI extensions in this repo.

The entry point (src/index.ts) registers the action via defineWebApplication, delegating file-type gating to src/utils/file-support.ts (isSupportedFile, defaulting to csv, md, pdf, txt). Scanning logic lives in src/composables/useScanner.ts: it builds a FileScanResult per resource with progressive state transitions (pending → scanning → done | error | skipped), validates the LLM endpoint origin against window.location.origin before attaching the Bearer token, and processes files one at a time with await rather than Promise.all to avoid rate-limit collisions. ScanResultsModal.vue drives both the unconfigured-LLM path (shows a setup prompt and suppresses the scan) and the live path, rendering structured findings with category icons (pii, credentials, confidential) or a plain pre-wrap narrative block when the LLM returns non-JSON text.

Two deliberate degradation tiers are supported: when the model returns valid JSON, findings are surfaced as categorized entries with redacted excerpts; when it returns prose, the raw response is stored as a narrative field and rendered verbatim. The same-origin check is a hard gate — cross-origin endpoints produce a per-file error without sending credentials. The batch action registers exclusively on global.files.batch-actions; dual-registration with global.files.context-actions was explicitly rejected during planning.

Unit tests cover all rendering states of ScanResultsModal.vue (unconfigured, global in-progress, per-file pending/scanning/skipped/error, narrative fallback, structured findings, and re-scan button visibility). An E2E scaffold (acceptance.spec.ts, ScannerPage.ts, playwright.config.ts, global-setup.ts) is committed but the acceptance tests themselves are out of scope for this PR — they require a live oCIS instance with an LLM sidecar and are not exercised in CI.

Gate

Check	Result
Hygiene	✅ ok
Build	✅ ok
Lint	✅ ok
Unit tests	✅ ok
E2E tests	✅ ok
Score	1.00

---

_{Effort: M · 🤖 Generated by extctl}

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.