Can you call it end-to-end encrypted if the provider holds the keys?

'Encrypted' describes what happens to data. It does not tell you who can make that data readable again.

Consider two designs. In one, a storage service encrypts a file on its servers and manages the keys. That protects stored disks, but the service can decrypt the file when serving an authorized request. In the other, encryption happens before upload and the storage service never receives what it needs to recover plaintext. AWS documents this distinction for its server-side and client-side encryption options.
There is a harder case between those two: a server holds part of the material needed to open a file, but cannot open it alone. Does that count as end-to-end encryption? I think the useful questions are more specific.

Can the operator decrypt without a recipient?
Can it substitute a recipient?
Can it change the author’s rules? What happens when a recipient’s device is compromised?

I’m working through those questions in own project. Files carry

1. encrypted content,
2. authenticated chunks
3. a signed header
4. recipient key slots
5. access rules

The server participates in granting access, but its share alone is insufficient to derive the file key. That is a narrower claim than “the provider cannot affect access”: the server can deny service, and a server cooperating with a recipient is outside this protection boundary.

I also want access decisions to follow the file instead of relying on the folder or network where it happens to live.

NIST’s zero-trust architecture frames access around individual resources and least privilege, without granting trust simply because a request comes from a particular network.

Applying that idea to files raises practical questions about identity, short-lived access, offline use, and revocation. Revocation can restrict future access; it cannot erase plaintext someone has already received.

Those questions become sharper with AI agents. A pipeline may need one agent to read a document, another to transform it, and a third to publish a result. Giving the whole pipeline one shared credential is convenient, but makes it difficult to limit the damage from a mistaken or compromised step. The direction I’m exploring is scoped grants for specific files and actions, with delegation that can narrow rights. It still cannot make a model “unsee” text it was allowed to read.

The part available to try today is OpenCrate, the Rust core behind Close Crate, and OpenCrateSDK, a simpler one-recipient API for JSON, messages, and file bytes. The SDK has Rust examples and experimental source-built interfaces for Python, Java, and C++. Hosting and agent workflows are still in development. The public libraries are an early, unaudited preview.

let recipient = generate_recipient()?;
let public = recipient_public(&recipient);

let purpose = "example.invoice.v1";
let context = b"invoice:42";
let sealed = seal_bytes(&public, purpose, context, br#"{"total":42}"#)?;
let opened = open_bytes(&recipient, purpose, context, &sealed)?;

I’m interested in where others draw the boundary: would you let a service participate in short-lived access to encrypted files if it could not decrypt them alone? What evidence would you need before trusting that design in an agent pipeline?