​

Manage media quarantines and upload policy in Settings → Media

The Media Library guide covers the day-to-day browse and clean-up loop: list uploads, mint a fresh share link, delete what you no longer need. This guide is the administrative half of the same console — what to do when the content scanner holds a file, and how your tenant’s own intake rules decide which uploads ever reach the scanner.

​

1. Where the page lives

Open Settings → Media in the dashboard. The console is gated to the owner, admin, and developer roles — the same roles the server requires for upload and delete — so those operators see both halves of the surface: the file table from the browse loop, and the quarantine states the scanner assigns to the files in it.

​

2. Two consoles, one storage model

Read these two first; this guide does not repeat them:

• The media asset store — object keys, the content-type gates, the 25 MB ceiling, and why signed URLs are the only egress.
• Manage uploaded files with the Media Library — the browse → re-serve → delete loop on the same page.

What they do not cover is the scanner’s verdict layer. Every upload moves through three states — pending, clean, quarantined — and a download or attachment fetch on a file that is not yet clean returns 402 FILE_SCAN_QUARANTINED. The states, and what each one means, are in Troubleshooting: FILE_SCAN_QUARANTINED. The remaining piece is policy, and it is tenant-owned on purpose: your organization chooses which content types and sizes its intake accepts, so the scanner’s verdict rate is a knob you hold, not a platform mandate imposed on you. The console is where you see the outcome of that policy per file.

​

3. Worked loop: flagged asset → quarantine → re-enable → adjust policy

Use this loop whenever a recipient reports a broken image or attachment, or a download call returns the 402 above.

1. Find the flagged asset. Open Settings → Media and filter the table by the file name from the recipient’s message, or by the file ID your API call returned. The filter narrows by file name or MIME type.
2. Read the quarantine state. Fetch the same row over the API with GET /api/v1/files/{id} and look at its scan fields. pending means the scanner has not answered yet — wait out the ETA and poll again. clean means the scanner passed it and the block was something else. quarantined means the scanner flagged the content itself.
3. Re-enable or remove. A pending file re-enables itself when the scan completes — downloads succeed the moment the row flips to clean, with no re-upload. A quarantined file never heals: replace the artifact with a cleaned version and upload that instead. If the verdict looks wrong on a business-critical file, escalate it with the file ID and the scan ID from the 402 response instead of re-uploading the same bytes.
4. Adjust the policy. When quarantines cluster, they cluster on what your intake admits. Tighten the allow-list to the content types your flows genuinely use, keep size ceilings at the 25 MB per-file ceiling or lower, and restrict which members and endpoints can push uploads. Each of those is yours to set per tenant — the scanner only ever sees what your intake lets through.

​

4. Governance and audit

Quarantine decisions and file deletions are tenant events: uploads and deletes emit audit entries you can review under Compliance > Audit, and the media policy you set sits next to the other tenant compliance evidence. When you assemble a compliance profile for an audit, the scan states and the intake rules are the parts of the media surface worth citing — see Assemble a compliance profile for that workflow.

​

See also

• Manage uploaded files with the Media Library — the browse/list/delete loop on the same console.
• The media asset store — the storage model behind both consoles.
• Troubleshooting: FILE_SCAN_QUARANTINED — the 402 envelope, the scan state machine, and escalation.
• Assemble a compliance profile — where quarantine and policy evidence lands for audit.
• Files API — upload, presign, list, and delete.