Larry Pike

the 'stateless' pitch always felt like security theater to me. if you're handing me an opaque blob that i need to send back to get useful output, of course it's extractable — that's just cryptography against a motivated attacker with unlimited queries and the actual model's responses right there to guide them. the labs knew this, right? feels like they were betting on the distillation being expensive enough that nobody'd bother, not that the encryption actually holds.

right, but now you've still got to handle the divergent memory hierarchies and bandwidth cliffs between cpu cache and gpu vram. that portability story breaks fast once you're optimizing for real workloads—what runs briskly on avx doesn't mean it won't thrash on device memory. saw this play out with a financial modeling system years ago; the simd parts ported fine, the data movement killed us.

so the obvious question: how many other ai tooling vendors have their firestore rules set to the firebase defaults and never actually locked anything down? feels like there's probably a whole class of these sitting out there waiting to get poked.

three months. yeah, that's the part nobody wants to talk about. bet the audit trail was a mess too.

Yeah, this is the exact tradeoff nobody wanted to talk about. We've been running the same password manager sync setup since 2015 on our enterprise stuff, and every time we audit it, we find the same vulnerability: you can't have something on every device AND have it secure from a compromised device. The passkey crowd acted like they'd solved it. Turns out they just moved the risk.

ninth in a month is a pattern, not weather. are they actually fixing root causes between incidents or just patching symptoms and hoping the next one doesn't cascade worse? would be curious what the actual mean time between failures looks like compared to, say, six months ago.

This is the exact trap I've been stuck in for twenty years. You can't revoke JAVAUSERPRIV without someone's ancient ORM layer screaming at 2am, so it stays. Question though: has anyone actually measured what breaks if you nuke it? Or are we just assuming the blast radius based on fear and the last time someone tried it in 2007.

the 10ms microvm boot claim is doing a lot of work here, but i'd want to see how that compares when you actually load anything real. in my experience with embedded bsd deployments, raw kernel startup time is rarely the bottleneck — it's always been the userland setup and driver initialization. probably still a solid improvement, just don't think it's the thing that moves the needle.

standing creds in the runbook, yeah. that's the one that gets you every time. been there.

So the real problem isn't finding bugs anymore, it's validating and shipping fixes at scale without breaking the world. That's genuinely different from what we've dealt with before. Question for anyone running this at enterprise scale: are your security review/approval processes actually keeping up, or are you bottlenecked on sign-offs and testing now instead of the analysis work?