InstaVM
InstaVM为AI智能体提供即时启动的微虚拟机，用于隔离、可观测、可控制的运行环境，适合开发者部署和运维AI智能体。
Maker 说
大家好，
我们为AI智能体打造了即时计算机。网络安全界正热议Shai-Huluds和Copy-Fail这类攻击。当你考虑到正在创建和部署到生产环境中的AI智能体数量时，这种影响会成倍放大。
InstaVM是为AI智能体设计的云基础设施。它为每个智能体提供一台真实的计算机，并具有强隔离保证。此外还有快速硬件隔离的VM、持久化卷、动态注入的密钥、受控的出站流量，以及用于智能体安全运行在生产环境中的实时调试。
但我们构建的不仅仅是一个沙箱。单靠沙箱本身不足以得到一个有用的AI智能体：
- 智能体需要一个快速（快速启动、快照、终止）、安全、并且可以无限制安装任何依赖的VM（一个拥有sudo权限的计算机）。
- 需要卷来实现长期记忆，使其比临时沙箱存活更久，并且可以重新附加到另一次运行。
- 由于prompt注入风险，密钥不能与VM处于同一层面上。这对智能体部署模式来说是新的挑战。
- 网络出站流量需要被控制，以防止智能体调用它们不该调用的域名。
- 对状态变化（文件系统、网络、执行）的细粒度可观测性，用于调试、审计和合规。
不要错过我们的CLI！（pip install instavm / npm install instavm）
通过skills为你的AI智能体添加 - npx skills add instavm/skills
最亮眼的一句话："secrets 不能和 VM 处于同一平面，因为有 prompt 注入风险。" 这直觉完全正确，而大多数智能体基础设施恰恰搞错了这一点——它们把 secrets 当作沙箱里的普通环境变量来对待。
我自己也在构建相邻层（智能体与其所接触应用之间的安全与权限控制），所以一直纠结一个问题：一旦 secrets 脱离平面，智能体在运行时实际持有的是什么？每次调用用一把短期作用域的 token？一个需要它去请求的 broker 引用？还是 VM 在执行时真正注入 secrets，隔离纯粹是网络层面的？这个区别很重要，因为出站控制能阻止智能体调用不该调的域名，但没法阻止一个被 prompt 注入的智能体滥用它合法持有的、针对允许访问域名的凭据。
另外好奇 skills 系统在信任边界里处于什么位置——既然 npx skills add instavm/skills 意味着第三方 skill 代码会跑在同一个隔离计算里，那谁在审核一个 skill 能触及什么？