> 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
Simple question: Why's everyone and their grandma funding sandboxes for agents? Explain to me like I'm 5.
EC2 is too slow and agents want to go vroom vroom.
VCs don’t want to be left out. if a trend starts to appear, they will all try to place bets on players in the same game knowing only 1-2 might win
> 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
> if the agent does something in a VM you have to figure out what happened.
If you can't audit what users are doing on a Linux system you have no business pretending you can run a k8s cluster.
(k8s was a ZIRP-fueled evolutionary mistake for most of the industry.)
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