> The base unit shouldn’t be a VM an agent rents. It should be an isolated cloud an agent owns.
This idea solves nothing, creates unnecessary attack surface and exposes the owner to unknown cloud spend. No place that I have ever worked would greenlight something like this.
An agent scoped cloud is exactly what fixes some of those concerns though. from a security perspective, you either trust your multi tenancy implementation to isolate workloads from each other or you use a common isolation layer (which k8s already gives you). budget becomes a property of the per-agent cloud itself.
From a security perspective, multi-tenancy is not any less secure than the "turtle shell security" microservices approach. You still have access to virtualization, networking controls and finer-grained fixed-cost hosting that you control instead of delegating to an LLM.
kube api gives you auditing, events, rbac, across pretty much all layers of the infra stack. if the agent does something in a VM you have to figure out what happened. if it does something on the control plane, it’s obvious what happened. i agree with you that security is any issue either way (especially based on recent events) but doing it under the kube umbrella makes it easier to manage at scale
no one is saying you can’t audit a VM. it’s about where you should audit and place controls. the k8s control plane makes me care less about what’s going on in the VM.
hard disagree on your last point. k8s powers pretty much all clouds as we know it
This idea solves nothing, creates unnecessary attack surface and exposes the owner to unknown cloud spend. No place that I have ever worked would greenlight something like this.