Launching today
InstaVM
Instant computers in isolated environments for AI agents
73 followers
Instant computers in isolated environments for AI agents
73 followers
The production control plane for AI agents. Run agents like production servers: isolated, observable, and controlled. Firecracker microVMs with sub-200ms boot.
GitPodcast
Hello all,
We have built instant computers for AI Agents.
Cybersecurity world is abuzz with Shai-Huluds and Copy-Fail like attacks. The effect gets multiplied when you take into account the amount AI agents getting created and deployed in production.
InstaVM is cloud infrastructure for AI agents. It gives every agent a real computer to use with strong isolation guarantee.
Along with fast hardware-isolated VMs, persistent volumes, secrets injected on the fly, controlled egress, and live debugging for agents to run safely in production.
But what we have built is not just a sandbox. And sandboxes are not enough on its own to get a useful AI agent:
- Agents need a VM that is fast (quick to spin, snapshot, terminate), secure, and can install any dependency without restrictions (a computer with sudo).
- Volumes are needed for long-term memory that outlives ephemeral sandboxes and can reattach to another run.
- Secrets cannot live on the same plane as the VM due to prompt injection risk. This is new to the agent deployment pattern.
- Network egress needs to be controlled to prevent agents from calling domains they should not.
- Granular observability of state changes (filesystem, network, execution) for debugging, audit, and compliance.
Do not miss our CLI! (pip install instavm / npm install instavm)
Add via skills for your AI agents - npx skills add instavm/skills
Hey Manish, congrats on shipping 🎉
The line that stands out: "secrets cannot live on the same plane as the VM due to prompt injection risk." That is exactly the right instinct, and it is the part most agent infra gets wrong by treating secrets as just another env var inside the sandbox.
Building in an adjacent layer myself (security and permission control between agents and the apps they touch), so the question I keep circling: once secrets live off-plane, what does the agent actually hold at runtime? A short-lived scoped token per call, a broker reference it has to ask through, or does the VM get the real secret injected at execution time and the isolation is purely network-level? The distinction matters because controlled egress stops the agent from calling domains it should not, but it does not stop a prompt-injected agent from misusing a credential it legitimately holds for a domain it is allowed to reach.
Also curious where the skills system sits in the trust boundary, since npx skills add instavm/skills means third-party skill code runs inside that same isolated compute. Who vets what a skill can reach?
The persistent volumes angle is underrated in this thread — most agent infra discussions focus on isolation and secrets but gloss over the memory problem. If an agent's volume can reattach to a new run, that raises an interesting question: how do you handle volume integrity after a compromised run? If a prompt-injected agent writes malicious state to a volume that then gets reattached to a clean run, the isolation guarantee at the VM level doesn't help. Is there snapshotting or rollback on volumes, or is the assumption that the orchestration layer handles what gets reattached and when?
Regarding resource allocation how granular can we get with CPU/memory limits per microVM via the control plane, and does it support auto scaling metrics if an agent gets caught in an expensive recursive loop?
Fabraix