Content Inspection

Every file written to an app's storage is scanned for malware and for personal data, and the result is attached to the object as a badge in the workspace dashboard. Scanning is a reporting feature: files stay instantly readable to the app, and the scan is a background fact about the object. This chapter covers the trigger, the scanners, and where the results land.

#The Trigger

Files reach storage in two ways: through the platform's brokered file routes, and directly from a browser using a presigned upload grant. In the second path, no platform pod ever sees the bytes, so the trigger cannot live in application code. It lives in S3.

Every app-file bucket in every region emits an object-created notification to that region's SNS topic. Each topic delivers into one central file-scan queue, using raw message delivery. A worker processor drains the queue, adapts the raw S3 event into a routable message, and records a pending scan row per object keyed on the object's physical identity: region, bucket, key. From that point, every object has a row, whether or not a scanner can do anything with it.

Because the queue carries real work, the worker fleet scales on its depth like every other queue. See Scale and Reliability.

#The Scanners

Scanning runs on a standalone content-inspection tier on the trusted cluster: two Deployments, one for antivirus and one for PII, each with its own Service. Both sit deliberately outside the platform's deploy rollout, so an app deploy never restarts a scanner or fails because of one.

Antivirus. ClamAV runs as a daemon with its signature database baked into the image, so a fresh pod is scannable immediately and the updater fetches only deltas after boot. The worker streams the object's bytes to the daemon over its stream protocol and reads the verdict. A signature-freshness check reads the daemon's engine and database version. Two replicas behind a disruption budget keep one available through signature reloads and node drains.

PII. Microsoft Presidio's analyzer runs as a service with an English NLP model. The worker extracts text from the object using a deliberately lightweight, local, free extraction method: a ranged read for text-like files, a parser for common binary document formats, and a skip for images and image-only PDFs. The text is analyzed against a curated set of entity classes: the identifiers and credentials that could expose someone's personal data. Noisy classes are excluded, and low-confidence matches are dropped. The result is aggregated to counts per entity type; the text itself is never stored.

Extraction here is separate from the ingest-grade extraction used for data sources, which routes binary formats to a document model. Public-bucket keys hash their owner and cannot be attributed to a workspace, so a paid model call per uploaded file would have no one to bill and is not made.

#Results

Each scan row carries an AV status and a PII status: pending, clean, flagged, error, or skipped, with the entity counts for PII. The workspace's file dashboard shows a badge per file and per store. The dashboard's manage routes refuse to hand out URLs or previews for an object whose AV status is flagged. The serving data plane does not gate on scan rows; the app's own reads and its users' reads are never blocked by the scanner.