Confidential File Sharing for Business: What Generic Cloud Links Actually Get Wrong

Most businesses share sensitive documents the same way they share lunch menus: a cloud link, maybe a password, maybe not even that. Confidential file sharing for business requires something structurally different. Not a better password. Not a stricter policy memo. A different architecture, where the provider itself cannot read what you send, where access is logged immutably, and where the file can be destroyed after the fact, by you, completely. This piece explains what that looks like in practice, where the common tools fall short, and how we built SelinaSEND to close the gaps we kept seeing in our own workflows.

Key Takeaways

• Most cloud file-sharing breaches trace back to misconfiguration and overpermissioned links, not sophisticated attacks. The link itself is the leak.
• Standard cloud encryption (TLS in transit, AES-256 at rest) does not prevent the provider from reading your files. Zero-knowledge encryption, where only sender and recipient hold usable keys, is a distinct and stronger property.
• The newer, less visible risk: once a recipient opens your confidential file, its contents can end up pasted into a public AI tool. Roughly 27% of enterprise employees have done exactly this with confidential data.
• Audit trails matter as much as encryption. 61% of organizations lack evidence-quality documentation of who accessed what and when.
• SelinaSEND applies zero-knowledge encryption to every file uploaded and sent through it. We cannot read your files. By design.

Why is confidential file sharing still broken in 2026?

Because the default tooling was built for collaboration, not confidentiality. Collaboration tools optimize for ease of access. Confidentiality demands the opposite: controlled, auditable, revocable access with a strong bias toward denial.

The failure modes are not exotic. Cloud storage security experts consistently find that the most common vulnerabilities are human-driven: weak passwords, disabled MFA, overpermissioned links, misconfigured sharing settings. A significant share of cloud data exposures come down to a shared link left open to "anyone with the link." No attacker required. Just a default setting nobody changed.

Email is worse. Sending files as email attachments creates uncontrolled copies and breaks whatever audit trail existed. The file lives in the sender's outbox, the recipient's inbox, their backup, their forwarded-to colleague's inbox, and possibly a compliance archive somewhere. You have no visibility into any of it after you hit send.

This is the environment most businesses operate in when they need to share a term sheet, a medical record, an M&A draft, or outside counsel's privileged analysis. The tools are fine for sharing slide decks. They are not fine for this.

What does "encrypted" actually mean when your provider holds the keys?

Almost every cloud provider will tell you your files are encrypted. They are not lying, exactly. But the claim is less than it sounds.

Most enterprise file-sharing tools encrypt data in transit (TLS) and at rest (AES-256), but the provider itself manages the encryption keys. This means the provider can, technically, decrypt and read your data. A subpoena, a rogue employee, a breach of the provider's internal systems: any of these can expose your plaintext files even though they were "encrypted."

Zero-knowledge encryption is a different architecture. Only the sender and recipient devices ever hold plaintext or usable keys. The provider is structurally incapable of accessing the data. Not policy-incapable. Structurally. The math prevents it.

This distinction matters specifically when you are sharing with outside counsel, auditors, M&A counterparties, or regulators. These are exactly the scenarios where the stakes of a provider-side exposure are highest, and exactly the scenarios where most businesses reach for a generic cloud link because it is convenient.

The rationale for combining zero-trust principles with end-to-end encryption is straightforward: the old idea of a defensible network perimeter no longer holds. Your files cross organizational boundaries every time you share them externally. The encryption has to travel with the file, not stop at your provider's edge.

How does SelinaSEND handle confidential file sharing differently?

A file uploaded fresh into SelinaSEND is zero-knowledge encrypted. We cannot read it. We do not hold usable keys. The file is encrypted client-side before it reaches our infrastructure, and only the intended recipient can decrypt it.

This is a per-path claim, and we are precise about it. A file uploaded into SelinaSEND gets the zero-knowledge property. A standalone note written outside the AI gets it too. Chat messages and conversations are encrypted in transit and at rest, but they were processed by a frontier model during creation, so they were never zero-knowledge. A file sent from SelinaVault is encrypted at rest, under a key you control, and cryptographically erasable, but it is not zero-knowledge in the same sense. We make these distinctions because they are true, and because vague encryption claims are how the industry got into this mess.

Beyond encryption, SelinaSEND gives you controls that generic cloud links do not:

• Links expire. You set the window. After expiry, the file is inaccessible.
• Access is logged. You see who accessed the file and when.
• You can revoke access after the fact. The file is cryptographically erasable. Delete means gone. Actually gone.

Non-content operational metadata is kept for a short retention window, not indefinitely. We do not claim zero retention. We do claim that the content itself is under your control, not ours.

Why do audit trails matter as much as encryption?

Because regulators and cyber-insurance underwriters do not just want to know that a file was encrypted. They want evidence of who accessed it, when, and whether that access was authorized.

One industry forecast found that 61% of organizations lack audit trails detailed enough to serve as evidence-quality documentation, and 57% lack centralized gateways to track where sensitive data actually flows. If you are in a regulated industry (healthcare, finance, legal), this is not a nice-to-have gap. It is a compliance failure waiting for an audit.

Generic cloud links are particularly bad here. A link shared via Slack, forwarded via email, opened on a personal device: none of these events are logged by the file-sharing platform in a way that constitutes an audit trail. You know the file was accessed. You do not know by whom, on what device, or whether it was downloaded, screenshotted, or pasted somewhere else.

SelinaSEND logs access immutably. This is not a security feature in the traditional sense. It is a compliance product. When your auditor asks "who had access to this document and when did they open it," you can answer with data, not a shrug.

What is the shadow AI risk to shared confidential files?

This is the risk vector that most confidential file sharing discussions still ignore, and it is growing faster than the traditional ones.

The scenario: you share a confidential file with an outside party using a secure link. They download it. They open it. They paste a section into a public AI chatbot to summarize it, or to draft a response, or to translate it. Your confidential data is now in a third-party system you never authorized, with retention policies you do not control.

This is not hypothetical. About 27% of enterprise employees have entered confidential company data into public AI tools, and roughly 11% of everything pasted into chatbot-style tools contains sensitive or confidential material. One 2026 AI security report found that a single popular AI chatbot generated more than 410 million data-loss-prevention policy violations in 2025 alone, each representing sensitive data attempting to leave an organization.

A 2026 World Economic Forum survey found that CEOs now rank data leaks from generative AI as their top security concern at 30%, up sharply from 22% the prior year. The concern is justified.

This reframes confidential file sharing as an ongoing custody problem, not a one-time transfer problem. The encryption of the file in transit is necessary but not sufficient. What happens to the document's contents after the recipient opens it is now the larger risk surface.

There is no pure technology solution to a recipient pasting your data into a public tool. But there are architectural choices that reduce the blast radius: expiring links that limit the window of exposure, view-only modes that make copy-paste harder (not impossible, harder), watermarking that creates accountability, and audit trails that at least tell you the file was accessed so you can narrow the timeline if something leaks.

What is the "vendor aggregation" problem in file sharing?

Several 2026 incidents illustrate a pattern where sensitive data gets funneled into shared aggregator platforms, so that a single intrusion exposes many downstream organizations at once. Your law firm uses one file-sharing platform. Your accounting firm uses the same one. Your M&A advisor uses it too. A breach of that single platform exposes confidential data from all of their clients simultaneously.

Reports in early 2026 described credential-theft attacks against self-hosted file-sharing platforms, where attackers used stolen credentials rather than exploiting software flaws. The platform itself was not breached via a vulnerability. The credentials were the vulnerability.

Zero-knowledge encryption mitigates this structurally. If the platform cannot decrypt the files it hosts, then a breach of the platform (whether through stolen credentials, an insider, or a software flaw) does not expose plaintext. The attacker gets ciphertext. This is meaningfully different from the standard model where the platform holds the keys and a breach means full exposure.

How should you evaluate a confidential file sharing tool?

Five questions. Ask them in this order.

1. Who holds the encryption keys? If the provider manages the keys, they can read your files. If the keys are generated and held client-side only, they cannot. This is the single most important architectural question. Everything else is secondary.
2. Does the link expire, and can you revoke access after sharing? A link that lives forever is a liability that grows over time. You need time-bounded access and the ability to kill a link after the fact.
3. Is there an immutable access log? Not "we track downloads." An immutable, timestamped record of every access event that you can export and hand to an auditor.
4. What happens when you delete? Is the file actually purged, or is it soft-deleted and retained on backup tapes for months? Cryptographic erasure (destroying the key so the ciphertext becomes permanently unreadable) is the strongest form of deletion.
5. Is zero-knowledge the default, or an opt-in add-on? Several providers now apply zero-knowledge encryption to every file by default, while others only offer it as a paid upgrade. If it is not the default, your users will forget to enable it on the one file that matters most.

A bug class that hides in plain sight: encrypt-before-embed

Here is something we learned building this. When you process a file for sharing, there is a subtle ordering dependency between encryption and any metadata embedding (thumbnails, previews, search indexes). If you generate a preview or embed metadata before you encrypt, that preview exists in plaintext on the server, even if the file itself is later encrypted. The zero-knowledge property is broken, silently, by a processing pipeline that runs in the wrong order.

We call this class of bug "encrypt-before-embed" internally, though the name is slightly misleading (it is really "embed-before-encrypt," which is the broken version). It is easy to introduce. A developer adds a thumbnail generator to improve the UI. It runs server-side. It processes the file before encryption. Now your zero-knowledge file-sharing product has plaintext thumbnails sitting in a cache somewhere.

The fix is architectural: encryption must be the first operation, performed client-side, before the file ever leaves the user's device. No server-side processing of plaintext. No previews generated from unencrypted content. This constrains what you can do with the UI (you cannot show a rich preview of a file you have never seen in plaintext), but the constraint is the point. We chose to accept the UI limitation rather than compromise the encryption guarantee.

This is the kind of thing that separates products built by people who think about threat models from products where encryption was added as a feature checkbox. It does not show up on a comparison table. It does not have a marketing name. It just determines whether your "zero-knowledge" product is actually zero-knowledge or is leaking plaintext through a side channel nobody audited.

What about Selina's AI features and confidentiality?

Selina is a privacy-focused AI assistant that remembers you across conversations. It runs on a stack of frontier models, routed per task. Memory is adaptive and encrypted at rest. Your Selina account is protected, not encrypted in the end-to-end sense, because the distinction matters.

SelinaSEND is the file-sharing path. Files uploaded fresh into SelinaSEND are zero-knowledge encrypted. This is the strongest honest claim in the product. We built it because we needed it ourselves: sharing sensitive documents with outside parties (legal, accounting, investors) where the contents are nobody's business but the sender's and recipient's.

Memory is not end-to-end encrypted. A slice of each request reaches a frontier provider at inference. We state this because the alternative, letting you assume everything is zero-knowledge, would be dishonest. The file-sharing path and the AI path have different encryption properties because they have different architectures. We label them accordingly.

What does "delete means gone" actually require?

More than most people think.

Standard deletion in most cloud platforms is a database flag. The file is marked as deleted. It may persist in backups, replicas, CDN caches, and disaster-recovery snapshots for weeks or months. "Deleted" means "hidden from the UI," not "purged from all storage."

Cryptographic erasure works differently. The file remains as ciphertext on storage, but the encryption key is destroyed. Without the key, the ciphertext is computationally indistinguishable from random noise. The file is gone in every meaningful sense, even if the bits persist on a disk somewhere. No key, no file.

This matters in legal contexts. If you are sharing documents under NDA and the engagement ends, you may need to certify that you have destroyed all copies. With a standard cloud link, that certification is aspirational at best. With cryptographic erasure, it is a provable technical fact: the key was destroyed at timestamp X, and no entity (including us) can recover it.

A federal court order tied to a lawsuit against an AI vendor recently required indefinite retention of chat logs. Sensitive data pasted into that chatbot could be preserved by a third party indefinitely, with no way for the originating company to delete it. This is the kind of loss-of-control scenario that cryptographic erasure prevents at the architectural level, if the data never enters a system without that capability in the first place.

Where does this leave you?

If you are sharing confidential documents with outside parties using generic cloud links, you are relying on a system where the provider can read your files, links may never expire, audit trails are incomplete or absent, and deletion is cosmetic. The risk is not theoretical. It is structural. The defaults are wrong for this use case, and policy cannot fix an architecture problem.

Confidential file sharing requires zero-knowledge encryption (where the provider cannot access plaintext), time-bounded and revocable access, immutable audit logging, and cryptographic erasure. These are not premium features. They are baseline requirements for any file that would cause real damage if exposed.

We built SelinaSEND because the alternatives kept failing this test. Not because they were bad products. Because they were built for a different problem.

Start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io