> ## Documentation Index
> Fetch the complete documentation index at: https://docs.strandai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security & data handling

> How Strand AI stores, encrypts, retains, and deletes your data, and our commitment never to train on it without your opt-in.

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](/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](#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.

<Note>
  **Our guarantee:** pre-de-identification bytes never persist in our long-term
  storage. They exist only transiently in an isolated, auto-expiring quarantine
  during processing, and the quarantine bucket lifecycle rule deletes any missed
  objects within 24 hours.
</Note>

### 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](/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.

<Note>
  Deletion happens over a **window** rather than instantly. A sample is permanently
  deleted 7 days after it expires, once it has passed through the Trash grace
  period, and remains restorable until then.
</Note>

### 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](/expiration#permissions)). 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.