Security

Last updated 1 September 2026

What SendFrame actually does, in the words we can defend. Where a control is narrower than it sounds, this page says so — a security page that names its own limits is the one worth believing.

Recipients are verified, not guessed

Every recipient gets their own link and confirms their email address with a one-time code before anything renders. There are no public links.

We know who viewed because they verified their email, not because we tracked their IP. We never store raw viewer IP addresses — only a city-level location derived at request time, and a coarse device class.

What we check before a document leaves

SendFrame flags credentials, internal URLs, colleague names, personal data, hidden text and prompt-injection phrasing in what you are about to send, and shows you exactly what your recipient will see.

Detection is pattern-based over text we can reach. It does not read images, it does not understand context, and it cannot know that a project codename is confidential. The sender is still the decision-maker; our job is to make the decision informed rather than blind.

Redaction removes, it does not cover

High-severity findings are removed from what the recipient receives before the link goes out. The bytes we serve do not contain them. The original is never modified — redaction is metadata, and the served rendering is derived, so a mis-flag destroys nothing.

For PowerPoint and PDF the honest word is withheld rather than redacted: there is no text-level edit available for a rendered page, so a page still carrying a flagged finding is not shown at all and the recipient sees a labeled placeholder saying so.

You do not have to take that on trust. GET /api/v1/shares/:id/delivered returns exactly what a verified recipient receives, produced by the same function the viewer calls — so your security team can grep the bytes themselves.

Malware

Uploads are scanned against known malware signatures (ClamAV) before conversion, and a file that matches is refused — it is never delivered to a recipient.

Signature scanning matches known artifacts, not malicious behavior, which is narrower than most readers assume: it catches files that already are something cataloged, including inside archives, and it does not reason about what a file does. When the scanner is unavailable we report the file as unscanned rather than as clean, and we do not block the send — an outage of ours must not present as an accusation about your file.

Samples are never sent anywhere. Scanning happens on infrastructure we run. We do not submit files to VirusTotal or any multi-scanner, and we will not.

Isolation between customers

Row-level security in Postgres, enforced by the database rather than the application, with FORCE ROW LEVEL SECURITY so it binds the owner too. Artifact content is served from a different registrable domain from the application, so a bypass in customer-supplied HTML cannot reach a sender's session.

Every bearer token — recipient links, API keys, session cookies — is stored as a SHA-256 hash. We cannot show you an API key after it is created because we do not have it.

What we do not claim

We are not SOC 2 certified. The goal is that a future audit is paperwork rather than a rebuild, which is a statement about our engineering and not about our compliance status.

We do not claim to detect malicious content, and we do not claim that nothing sensitive can leave. Both would be promises about every file that has ever existed, and the first miss would make everything else on this page suspect.

Questions, or a data request: support@getsendframe.com.