开源用于AI代理的Shell级别安全层
摘要
开源一个Shell级别的控制层,该层阻止危险命令、暴露虚假秘密并强制执行运行时策略,使AI代理在开发环境中更安全、更确定。
在使用AI代理一段时间后,我一直遇到同样的问题:最终代理会无视边界,读取`.env`文件,接触生产资源,或者使用它本不该访问的秘密。即使使用MCP只读设置和精心编写的提示词,Shell本身仍然被过度信任。所以我开始为AI代理构建一个Shell级别的控制层:
* 阻止或清理危险命令
* 暴露虚拟/虚假秘密而非真实秘密
* 分离开发/生产访问策略
* 限制网络/域名访问
* 强制执行运行时策略而非仅依赖提示词
目标是在真实的开发者环境中让代理更安全、更确定。我现在正在开源它,并寻找使用Claude Code、Codex、Cursor等工具的人,尝试在实际工作流中攻破它。非常欢迎反馈、批评和攻击思路。PyPI链接在评论区
相似文章
@ClementDelangue: 从我们所知(请谨慎对待,我们需要更多透明度!),如果 @OpenAI 一直在运行这个……
NVIDIA 推出 OpenShell,一个用于安全 AI 代理执行的开源运行时,具有内核级强制和形式化验证,以防止未授权操作。
如何借助 NVIDIA OpenShell 实现自主 AI 智能体的“内置安全”设计
NVIDIA 推出 OpenShell,这是一款专为自主 AI 智能体打造的“内置安全”运行时环境。它通过将智能体操作隔离在沙箱中,并在系统级别执行安全策略,而非依赖行为提示词来保障安全。作为 NVIDIA Agent Toolkit 的一部分,该工具包使企业能够在统一的策略管理和合规监管下,运行代码编写智能体和智能体工作流。
为AI代理打造一个开源CLI编排层是否有意义?
本文探讨了为AI代理编排CLI使用而构建一个开源层的想法,解决了代理在与多个CLI交互时面临的权限、沙箱和审计追踪等挑战。
在授予本地 AI 代理 Shell 访问权限之前,你应该实施哪种安全边界?
关于具有 Shell 访问权限的本地 AI 代理安全边界的讨论,涵盖隔离、最小权限、凭据保护、网络出口控制以及人工审批门。作者强调提示词级别的指令并不是真正的安全边界,并向社区询问实际设置。
在 OpenShell 应用形式化方法控制 AI 代理的经验
本文讨论了扩展人类对 AI 代理的监督所面临的挑战,并展示了如何使用形式化方法结合 Z3 库来验证代理策略变更是否保持在已批准的权限范围内。