# Privacy-Preserving Intelligence

Steve Korshakov, Bee (acq. Amazon) | AI Engineer World's Fair 2026 | 15:53

Source: https://www.youtube.com/watch?v=IvE8n-ylFYY
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/privacy-preserving-intelligence
Published: 2026-07-20
Tags: agent-skills, agents, deployment, privacy, security

## TL;DR
- Bee encrypts captured data so its key stays on the customer's phone and never reaches Bee or Amazon.
- The backend accepts a key only after the phone verifies the workload through attestation and a public Sigstore transparency log.
- 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.

## Key ideas
### Bee's recordings can reveal a person's life quickly
[00:01](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=1s)
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
[01:32](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=92s)
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
[03:46](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=226s)
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
[05:04](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=304s)
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
[05:53](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=353s)
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
[07:07](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=427s)
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
[09:39](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=579s)
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
[12:12](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=732s)
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
[14:08](https://www.youtube.com/watch?v=IvE8n-ylFYY&t=848s)
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.

## Notable quotes
- "A single person usually captures about 10 million tokens per year." (00:39)
- "Our mission was to not have access to any of this data and not being able to look at it anyone at Amazon." (01:30)
- "We hardcode their signing keys inside of our client apps and our back ends so we can't really control them." (07:58)
- "It's just like about 20k lines on memory safe language." (12:13)
- "Nothing works except like sandboxing and just not giving them a way to hurt themselves." (14:08)

## Tools & references mentioned
- Amazon
- Bee
- Sigstore
- EC2
- Telegram
- OpenClaw

## Who should watch
- You are building an AI product that stores continuous personal context and need a concrete encryption and key-management boundary.
- Your service runs inside a large cloud company and must defend customer data from your own employees or deployment process.
- You are designing autonomous agents and want to hear a practitioner's case for persistent runtimes, attestation, and sandboxing.

## Related talks

- [Personal, Local, Private AI Agents](https://aietalks.com/talks/personal-local-private-ai-agents) (Soumith Chintala, Meta, 20:32)
- [Privacy First Enterprise AI: Building AI Agents that Never Leave Your Security Boundary](https://aietalks.com/talks/privacy-first-enterprise-ai-building-ai-agents-that-never-leave-your-security) (Steven Moon, Aech AI Inc., 07:10)
- [IT Admin for the AI Workforce](https://aietalks.com/talks/it-admin-for-the-ai-workforce) (Sarthak Aggarwal, Decawork, 16:17)
- [GPU-less, Trust-less, Limit-less: Reimagining the Confidential AI Cloud](https://aietalks.com/talks/gpu-less-trust-less-limit-less-reimagining-the-confidential-ai-cloud) (Mike Bursell, Super Protocol, 43:41)
- [I Gave an AI Agent the Keys to My Life: Here's What Happened](https://aietalks.com/talks/i-gave-an-ai-agent-the-keys-to-my-life-heres-what-happened) (Radek Sienkiewicz, OpenClaw, 19:34)