OpenShell：用内核级策略给AI Agent上安全枷锁

AI 智能体越能干，越让人睡不踏实。让它读写文件、装依赖、调 API，效率确实起飞；但权限一旦全量放开，密钥、数据和网络出口也一并交了出去。GitHub 快报里介绍的 OpenShell，想解决的正是这个矛盾：能力照给，但把数据、密钥和网络守在策略边界内。

OpenShell 为自主智能体集群提供安全私有运行时

全量权限是效率捷径，也是风险放大器

把 AI 智能体直接放进开发环境，本质上是把一台长期在线的「自动执行器」接上了你的工作目录。它可以自行读写文件、安装软件包、发起网络请求——这些动作在正常开发中是生产力，在失控时就是数据外泄和密钥泄露的通道。

OpenShell 的定位，是给这类自主智能体集群准备的安全、私有运行时。它不是收窄智能体的能力，而是在能力和资产之间插一层策略边界。这个思路值得注意的地方在于：安全问题不是靠「少给权限」缓解，而是靠「给了权限也能管住」来解决。

每个智能体一个沙箱，内核对系统调用兜底

OpenShell 让每个智能体跑在独立沙箱里，用内核级控制限制文件访问和系统调用。换句话说，策略约束下沉到了操作系统层面，而不是停留在应用层的「君子协定」。

这对多智能体集群尤其关键。多个 agent 并行干活时，一个越权的文件读取或进程调用，就可能污染整条链路。沙箱隔离加上内核级限制，把单点失控的影响面压在单个智能体内部。

系统调用（syscall） 是用户态程序请求操作系统内核服务的唯一入口，文件读写、网络收发、进程创建等最终都要经过它。内核级限制通常借助 seccomp、Landlock、cgroup 等机制，在系统调用进入内核时按白名单或规则进行拦截，因此比应用层钩子更难绕过——应用层限制可能被库、子进程或语言运行时绕开，而系统调用过滤对沙箱内所有代码一视同仁。代价是策略需要逐个系统调用族调优：过宽则隔离失效，过窄则常见的装包、编译、动态链接都会失败，这也是沙箱方案落地时最耗精力的部分。

网络出口先过策略，凭证从不交给智能体

网络是另一个高危面。OpenShell 要求每次网络连接离开沙箱前，先通过策略检查。也就是说，智能体不是拿到一张通行证就能随便出网，而是每次请求都要被审视。

凭证处理更彻底：密钥不会交到智能体手里，只在发往网络或端点的请求里注入。这样即使智能体被提示词注入攻击诱导，它手上也没有可直接泄露的凭证。这种「凭证不落地到 agent」的设计，比单纯限制访问范围更接近根因。

凭证在请求层注入，不暴露给智能体

提示词注入（prompt injection） 指攻击者把恶意指令藏在智能体读取的网页、文件或工具返回内容里，诱导模型偏离原任务去执行攻击者意图，例如把环境变量里的密钥发往外部地址。传统防护依赖模型「识别并拒绝」，但模型对嵌入文本的判别并不可靠。凭证注入的思路是把密钥移出智能体的可达范围：智能体只发起请求，由边界处的代理在转发时附加凭证，模型既看不到密钥也无法直接外传。这一设计把安全从「依赖模型行为」转为「依赖架构约束」，对注入类攻击更稳健。

策略变更要过形式化验证和人工审查

权限策略本身也会成为风险源。OpenShell 对策略变更先做形式化验证，标出新增的高风险访问，再等待人工审查。

这套流程的价值在于把「权限扩散」变成可审计事件。智能体要装包、调 API 时，策略变化会被显式暴露出来，而不是悄无声息地扩权。对于需要合规审查的团队，这种带验证和人工卡点的机制，比事后看日志更容易落地。

形式化验证 指用数学方法对系统或策略建模，并证明其满足给定性质，而非仅靠测试抽样。在权限策略场景中，它可用于判断新增规则是否引入了非预期的访问路径，例如某条网络规则是否间接放开了对敏感端点的访问、规则组合后是否产生策略冲突或覆盖漏洞。与人工审阅 diff 相比，形式化方法能系统枚举规则交互，发现肉眼容易忽略的隐式扩权。其局限在于需要对策略语言和系统行为建立足够精确的模型，建模遗漏会直接削弱结论的可信度。