> ## Documentation Index > Fetch the complete documentation index at: https://docs.zas.red/llms.txt > Use this file to discover all available pages before exploring further. # Encryption > Zas encrypts on your device before anything is uploaded. This page states exactly what that protects, and the one case where it does not. Zas encrypts your content on your device, before it leaves. The Zas servers never receive the plain file. This page also states the limit of that protection. We would rather you read it here than discover it later. ## Where encryption happens On the device you are sending from. In the browser this runs in a background worker, so a large file does not freeze the page. The server receives encrypted chunks. It cannot open them. ## An agent encrypts on your machine too A [coding agent](/en/agents/index) runs the same encryption code as the app, on the machine where it runs. Sending through an agent does not move encryption to a server. An agent never derives your account key. You grant it one channel at a time, and each grant hands it that channel's key, sealed with a public key the agent made on your machine. An agent can only open the channels you granted. What a grant covers, and how to take one back. ## Where the key comes from Your key is derived from your sign-in. There is no password to choose and no recovery phrase to write down. A **separate key service** does the derivation, so the main Zas service never handles your key material directly. An operator who controls that key service and has account identifiers could reconstruct keys. Zas therefore does **not** call this design end-to-end encryption, and you should not treat it as such. This is the honest version. Your content is encrypted at all times, nobody reads what you send, and there is no list of who has what. It is not the same promise as a messenger where only the two devices hold the keys. ## Share links are different A public share link carries its key in the part of the web address after the `#`. Browsers never send that part to a server. Zas therefore cannot read a shared item, even though it is serving it. Anyone who has the full link can open the item. That is the whole design: the link is the key. How to make one, and how to take it back. ## Covered notes When you paste something that looks like a password, Zas covers it so it does not sit on screen in the open. That check runs on the sending device, before encryption. Nothing about it is sent anywhere. ## Repeated chunks on the older storage path Zas has two storage paths. On the older one, the file system can recognize that an encrypted chunk repeats. It cannot read the chunk, but it can tell that the same encrypted block has been seen before. The newer storage path does not do this. Accounts are moving to it. ## Passkeys You can add a passkey to your account for sign-in and for sensitive actions. A passkey lives in your device or password manager and cannot be phished the way a code can. Google, Apple, and passkeys. ## What to read next The list of what Zas records about each item and each account.