Security & data handling

This page describes how Strand AI handles the data you send us: what we store, how it is protected, how long we keep it, and how it is deleted. For the mechanics of setting expiration windows and restoring from Trash, see Sample expiration.

​

What we store

When you use Strand AI, we store two kinds of sample data on your behalf:

• Uploaded samples: the slide images you upload for prediction.
• Marker predictions: the per-marker outputs we generate from your samples, including the image pyramids served back to you.

We also keep operational records (see Logs are retained separately below) that are distinct from your sample data.

​

Slide de-identification at upload

Whole-slide images often carry patient-identifying information inside the file. It most commonly lives in the embedded label image (a photo of the physical slide label, which may show a barcode, accession number, or handwritten patient ID), the macro image (a low-resolution overview that can capture the label edge), and scanner-written metadata fields. Strand AI removes these automatically at ingest.

​

What we strip

On upload we strip:

• the label image,
• the macro image, and
• known PHI-bearing metadata fields.

We remove the entire embedded label and macro images wholesale. We do not scan, OCR, or attempt to read them; whatever the label shows (a barcode, a handwritten patient ID, or nothing at all) is gone because the whole image is removed at the file-format level. The pixel data of the slide itself (the tissue image used for every prediction) is untouched. We overwrite the metadata blocks in place. The tissue image is not re-encoded.

​

How it works

Pre-de-identification bytes are never written to our long-term storage. A new upload lands first in an isolated quarantine bucket with locked-down access controls, kept separate from the permanent data bucket. The de-identification step runs there; only the de-identified copy is written to permanent storage, and the original is deleted as soon as that copy is verified. As a backstop, the quarantine bucket lifecycle rule deletes objects within 24 hours, so a pre-de-identification file cannot persist beyond that cleanup window even if a step fails.

​

Validation

De-identification runs as a verified gate. Before the original is deleted, we re-open the de-identified copy and confirm that it opens cleanly, that the full-resolution image reads correctly, that no label or macro image remains, and that the known PHI metadata fields are cleared. If validation fails, the de-identified copy is not stored, the original is preserved within the quarantine window, and we alert our team. Your slide is never stored or served until it passes. Failed de-identification and preprocessing jobs are surfaced within seconds, so samples do not sit in an indeterminate processing state.

​

Supported formats

De-identification is available today for Aperio SVS (.svs). Support for additional formats (generic and OME-TIFF, Hamamatsu NDPI, and 3DHistech MRXS) is rolling out, with Akoya QPTIFF and Zeiss CZI to follow.

​

What we do not strip

Our approach targets the embedded metadata artifacts described above, which is where patient information accidentally enters WSI files in normal scanning workflows. We do not currently OCR or redact the tissue image itself. If a slide has patient identifiers baked into the tissue region, please crop or re-scan it with clean tissue before uploading. We also do not alter the filename you upload. Filenames are preserved in your storage path for your own reference. If a filename itself contains patient-identifying information, removing it is your responsibility: rename the file before uploading, or upload under a de-identified name.

​

Encryption

Your data is encrypted in transit and at rest. Strand AI runs on enterprise-grade cloud infrastructure with encryption applied to stored objects and database records, and TLS protecting data moving between you and our services.

​

Retention & deletion

Retention is under your control. Expiration is opt-in: samples never expire until an owner or admin sets a policy (see Sample expiration for how to configure it). When a sample expires, it moves to Trash, where it is held for 7 days. During that window you can restore it. After the window closes, the sample and its marker predictions are permanently deleted 7 days after expiry. Both the stored objects and the corresponding database records are removed.

​

Logs are retained separately

Your sample data (uploads and the predictions derived from them) is deleted according to your retention policy as described above. Operational and audit logs are kept separately and are retained beyond your sample data for security, billing, and compliance purposes. These logs do not contain your slide images or prediction outputs; billing history is preserved even after the underlying samples are deleted.

​

Access control & audit logging

Access to samples is scoped to your organization and governed by role-based permissions (see the permissions table in Sample expiration). Retention actions (automatic archival on expiry and permanent deletion after the grace window) are audit-logged, recording what was deleted and when.

​

We do not train on your data

We do not use your data to train our models. If that ever changes, we will notify you in advance, and any such use will be opt-in.