TEEs keep the operator out of the operations. a bug in the software inside the TEE can still make it exploitable. this is what happened to @near_ai, which responded promptly to the attack, but it still caused some harm. here's what happened and why it matters ↓ • sglang rce on one near ai inference server (nov 8) • ~100 user account details downloaded • 18 legacy agents reached (these weren't in a tee) • confidential requests on that server could have been seen • path closed and fixed. near protocol / intents untouched. ↓ on nov 8 an attacker used a remote code execution bug in sglang (the open-source inference engine near ai runs) and got code execution on one of their inference servers. from there they reached an old internal system tied to the deprecated private chat feature and pulled account details (emails, names, some plan/balance info) for about 100 users. they also got into 18 agents on a legacy deployment that wasn't running inside a tee at all. those had chat history, settings, and logs. on the same day they could have watched user requests being processed on that server -- including ones in confidential mode, per the team's official report. near ai says no evidence that stored private chat content or uploaded files were touched. they closed the path, fixed the bug, rotated credentials, and brought cloud back. protocol, intents, and core infra were fine. @ilblackdragon put it well: inference providers are honey pots right now. they hold user data and can inject actions back through agents. a tee (intel tdx + nvidia confidential gpus in this case) is a hardware box. code and data stay encrypted even while running. the host, the operator, nobody outside can peek. that's the whole point. but the software inside the box still has to be solid. sglang is a full inference engine -- scheduling, kv cache, templating, loading weights, talking to other processes. big attack surface. an rce in it means the attacker is now running as the thing that processes your private prompts. near ai's own report says it clearly: "Confidential computing protects data from the operator and the host. It does not protect against a vulnerability in the software running inside the environment... the SGLang vulnerability let the party run code inside one inference server and access requests in processing on that server, including confidential ones." the 18 agents were outside the tee entirely. the confidential requests that could have been observed were the ones actively running on the broken server. they keep the stack open so people can check what runs inside. they're adding more checks on dependencies and a "turnstile" to catch weird behavior inside the enclave. good moves. still, the lesson is simple: the hardware keeps outsiders out. it does not make the inference engine magically safe. running big serving stacks inside tees is hard. the engine has to be treated with the same care as the enclave itself or the boundary doesn't hold. near ai contained it fast and were honest about the limits. that's better than most. the broader problem is real for anyone doing this. i run a near validator: thecoding.pool.near (stake with me via app.thecoding[.]dev) and also a devops business on thecoding[.]dev, helping teams with technical content, documentation, and user/dev education.