AI agents have become incredibly useful across many industries by their ability to reach inboxes, documents, and financial information, then search, summarize, or act on what they find. But that access creates a data-in-use problem: conventional encryption protects information in storage and transit, but an agent generally needs it decrypted in memory while processing it, where sensitive material can be exposed to application code, logs and debugging systems, infrastructure operators, or a compromised host.
Conan Yu’s work offers one practical response to that problem. He is co-founder of Rena Labs, which develops infrastructure for confidential AI training and inference using trusted execution environments (TEEs), hardware-isolated environments designed to limit the surrounding host’s access while code and data are processed.
Over roughly two years, Yu has worked across hardware and cloud TEE deployments, privacy-preserving financial-data analysis, and private AI inference. He argues that AI privacy should depend on verifiable controls showing where data is processed and which code handles it, not privacy policies alone.
When a useful agent becomes a privileged system
Yu first encountered this concern while building an agent that collected messages, interpreted their context, and prepared replies for a user to approve. Its usefulness came from its access, which raised a harder question: could the service process private information without trusting every developer, administrator, and infrastructure operator behind it?
“When an agent connects to your email or messages,” Yu says, “the company running it may be able to see the same information. Permissions and policies help, but they do not show users what happens while the data is being processed.”
That distinction has to do mostly with technical capability. Permissions control which applications receive information and privacy policies tackle the desired or intended use, but neither gives a user evidence of who or what can reach a running workload.
And since agents can now connect to calendars, documents, social platforms, financial accounts, and health records, it’s imperative that their security model cover permission to access data, the code that handles it, and administrators of its infrastructure.
The central question, Yu suggests, begins after the data arrives: what happens at the computation stage, and how can that data be protected?
How TEE protects data during computation
Yu worked across Intel TDX, AMD SEV, confidential GPU environments, and multiple clouds on an abstraction layer that hides hardware and cloud differences behind a familiar deployment interface. This, he claims, is essential for teams to protect existing workloads even if they’re not specialists in each individual platform.
That work centered on the data-in-use problem: decrypted memory can expose information to unsafe code, logs, debuggers, compromised hosts, or privileged operators.
He therefore focused on trusted execution environments, which are hardware-isolated areas where code and data run beyond ordinary access by the host, operating system, hypervisor, and administrators.
For the cross-provider workloads Yu was trying to support, isolation was only half the deployment problem. Before releasing sensitive data, credentials, or keys, a client or key service also needed evidence that the workload it would receive was running in an approved TEE. This was achievable by remote attestation, which provides that evidence through signed information regarding the environment and measured software.
His engineering evaluation compared TEEs with a myriad of other systems like zero-knowledge proofs, fully homomorphic encryption, multiparty computation, and end-to-end encryption, weighing latency, computational cost, scale, workload design, and deployment. He remains confident that TEEs are highly efficient, saying, “While TEEs aren’t the only option, I focus on them because teams can use them for many existing workloads without taking on impractical latency or rebuilding the whole application.”
Yu’s work on the abstraction layer reflected that practical choice: make isolation and attestation usable across existing workloads without forcing every team to become an expert in the underlying hardware.
A useful result without shared secrets
Yu also applied deployable TEEs to financial oversight, where protection had to fit a working data pipeline. A principal might need to assess whether a trading firm meets agreed liquidity, spread, volume, or risk requirements, but access to complete order-book data would make the firm susceptible to having their entire proprietary strategy revealed. Full disclosure would expose too much, but withholding it would leave the principal without a meaningful assessment.
Yu’s three-party model addressed this conflict by keeping contributions separate.
The data provider supplied an encrypted API credential or feed; the service provider supplied the approved pipeline and analysis logic. Once remote attestation gave a verifier evidence of the workload in an approved environment, the credential or key could be released under policy. Finally, the protected workload evaluated agreed indicators or anomalies, with the client receiving only a limited KPI assessment or anomaly signal.
“Each party should get only what it needs,” he says. “One supplies the data, another supplies the analysis, and the client receives the result. The raw data and the proprietary algorithm stay private.”
The separation defined what each party couldn’t see. The client didn’t receive raw trading data, the data provider didn’t receive the proprietary detection logic, and the operator was restricted from inspecting protected inputs, intermediate results, and outputs intended only for the client.
Privacy claims need a threat model
Finally, Yu points out that TEE protection has defined boundaries: it cannot repair vulnerable code, prevent sensitive outputs, secure compromised clients, guarantee availability, or eliminate hardware and side-channel risks. It’s also, like most systems, potentially susceptible to having data exposed through logging or debugging systems.
Remote attestation has similar limits: its value depends on measurement, verification, freshness, and the resulting policy. It supports a particular claim about an environment and workload, but doesn’t prove bug-free code or complete system security.
The same trust questions apply to general agents trusted with messages, documents, and other private information. The way Yu sees it, agents should reach what he calls their “Telegram moment,” meaning having strict privacy policies that are enforced in code, with technical evidence of where and how it processes data and how said data can be accessed.
In his words, “Users should be able to check where their information is processed and what code is handling it. They should not have to take the provider’s word for it.”
The way he sees it, companies that would implement these solutions should ask: What is decrypted? Who administers the host and workload? What does attestation measure and who verifies it? What leaves the TEE, and which attacks are excluded? Builders should test logs, telemetry, debugging, updates, outputs, and support access for leaks, then document trusted components, key-release policies, freshness controls, and residual risks.
For Conan Yu, AI privacy can’t rest on a provider’s promises alone. Users need verifiable evidence of where their data is being stored and processed, how it’s being handled, and how it could potentially be reached. Through his work with TEEs at Rena Labs, he’s hoping to make those conditions an industry standard.
The Hacker News https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQQyjwPYjJP0wddSEB8Dlpr3dlnQUs52-WmlrZfqJoBPeOvv2Zoqlq-FhEAz_Xeprj_mtrI1MGCW1JS840JUjVEK6VoNe6zCNNTw_7YmyvNmf3E5pprZ3zqP8lszq74Wt97SvbJo5yeuyep0U6-nGs0vdarg4_WUrc5r6L0ML0xE-BsPipJd2-1PMHTvO1/s76-e365/thn.jpg
