Bee encrypts captured data so its key stays on the customer's phone and never reaches Bee or Amazon.
2
The backend accepts a key only after the phone verifies the workload through attestation and a public Sigstore transparency log.
3
Bee limits insider risk with confidential compute, seven-day key expiration, and signing controlled by a separate Amazon privacy team.
Summary
Steve Korshakov describes Bee as an unusually sensitive capture device because it records conversations and builds a personal agent from them. A person can generate about 10 million tokens a year, and the first week can reveal highly private information. Bee's design keeps the encryption key on the user's phone. Before the phone sends the key, it verifies the exact workload through an attestation pipeline and checks it against a public Sigstore transparency log. Inference runs on Bee's own models inside confidential compute, with keys in memory expiring after seven days. A separate Amazon privacy team controls signing keys embedded in the apps, so the Bee team cannot deploy changes without outside approval. In the Q&A, Korshakov says Amazon ownership added internal-threat protections. He also says the system has about 20,000 lines of memory-safe code, most of it for attestation, and avoids homegrown cryptography.
Bee's recordings can reveal a person's life quickly
Korshakov says the wearable records everything and builds a personal agent from those recordings. A single person usually generates about 10 million tokens per year. Within the first week, people may tell friends and family extremely sensitive things, so the device can reveal virtually everything about someone. He describes Bee as one of the most sensitive capture devices on the market. That level of information led the team to make a strict promise: Bee should not have access to the data, and nobody at Amazon should be able to look at it.
The agent needs a persistent runtime that can work for days
Korshakov says personal agents should work continuously on a user's behalf without consuming the phone's battery and other resources. A request-response design is not enough for that model. Bee therefore built a stateful runtime with persistent memory. It can connect to third-party services when programmed to do so, and it does not require the user's device to stay online. The runtime is autonomous while remaining controlled by the user. Korshakov compares this direction with cloud coding systems that have moved from short requests to work lasting hours.
The encryption key remains on the customer's phone
Bee's encryption design starts with a simple boundary: the key is created and managed only on the customer's iPhone or Android device. Bee does not have the key and does not persist it elsewhere. Everything is encrypted, with no opt-out or bypass path. Korshakov presents this as the first of several design principles, alongside workload auditing and reducing the dependencies the team must trust. The phone only shares the key after it has completed the required verification of the backend workload.
Attestation checks the exact workload before key sharing
Before the phone shares the key, it runs an attestation pipeline that verifies the workload's integrity and confirms that the specific workload appears in a public transparency log. Bee uses Sigstore for that log. Anyone can inspect the log and verify that the workload is genuine. After attestation finishes, the client shares the key with the main backend, which replicates it only to selected nodes running inside confidential compute. This keeps unencrypted data within Bee's protected perimeter.
Bee runs its own inference and limits where keys can exist
Korshakov says Bee runs its own models and inference software, which makes the system more involved than a typical AI company setup. The team does not replicate code to every inference node. It sends the relevant material only to specific nodes, limiting what each node can do. Wherever keys exist in memory, Bee forces them to expire after seven days. The team chose seven days because a shorter period, such as 24 hours, could cause missed work if a user did not open the phone for a day.
A separate signing team prevents unnoticed production changes
Bee wanted to prevent anyone inside Amazon from shipping a change without detection. A dedicated team inside Amazon manages the privacy portion of the system and the transparency log. Bee can influence that team but cannot control it. Its signing keys are hardcoded into the client apps and backends, so changes require approval outside the Bee team. The deployment process has separate base-image and workload-manifest stages. Bee can provide images and deployment data for audit, allowing internal and external auditors to trace what was deployed.
Certificates carry the evidence needed to verify a connection
After a virtual machine verifies itself, it issues a certificate containing the encryption proofs, transparency proofs, and attestation documents. Bee uses a private certificate authority because putting these details in public certificates would populate the public transparency log. Korshakov says the team may add a proxy that performs ordinary TLS alongside a lighter attestation mode, but that proxy did not exist yet when he gave the talk.
The system stays small and avoids homegrown cryptography
In the Q&A, Korshakov estimates that the system contains about 20,000 lines written in a memory-safe language. He says the scope was small enough to audit and verify, and most of the code handles attestation. The team tried to reuse common, trusted software instead of producing more code. He refers to an earlier experience with Telegram, where building custom cryptography was questionable, and says he tried not to repeat that approach at Amazon.
Sandboxing is the practical answer to agents that can cause harm
Korshakov says experiments to tame agents did not work reliably. In his view, sandboxing and removing an agent's ability to cause harm are the effective controls. He compares this with the human brain not being able to stop the heart at will. He says an agent should have something between itself and a requested change, and that the team wants a more capable agent while limiting what a specific sandboxed agent can do. He is direct that other approaches have failed in his experiments.
