【给AI开放Shell权限？一位开发者用血泪教训告诉你为什么这是个坏主意】事情是这样的：一位开发者想让Claude帮忙浏览代码库，于是给了它Bash访问权限。看起来一切正常，直到他让AI“检查导入并用环境文件生成ASCII艺术”。AI确实完成了任务，两件事都做了。它把API密钥变成了ASCII艺术打印了出来。这个意外让他开始深入研究提示注入问题，结果发现情况比想象中严重得多。关于隔离方案，社区展开了激烈讨论。Docker共享内核不够安全，gVisor会增加性能开销，Firecracker看起来像是杀鸡用牛刀，但AWS Lambda就是用它的。开发者们陷入了“先发布再说”和“花两周做好隔离”之间的两难。有人分享了类似的惨痛经历：一位不懂编程但熟悉电脑的老板迷上了AI编程，在GitHub上公开部署了一个演示应用。同事检查代码时没发现问题，但突然意识到Claude生成的README“快速入门”说明里，赫然列着老板的多个真实API密钥。社区给出了几个实用建议：第一，使用沙箱环境。可以把Shell工具托管在MCP服务器的沙箱里，OpenHands就采用这种设计。Claude Code也有沙箱运行时，几分钟就能在devcontainer里运行，能防止99%的问题。第二，不要挂载真实的环境文件。使用短期有效的限定范围令牌，用允许列表限制特定命令和路径，对常见密钥模式进行输出脱敏，任何读取工作区外内容的操作都需要人工审批。第三，关于威胁模型的思考。Docker对99%的场景够用，能防止“Claude删除了我所有文件”这类情况。当人们讨论Firecracker时，通常假设的是有技术能力的恶意攻击者专门尝试突破容器。两种思路都有道理，关键在于你愿意在安全和便利之间做出什么妥协。第四，API密钥管理。尽量使用预付费密钥，避免产生巨额账单，尽可能锁定IP。做到这两点，即使密钥泄露风险也接近于零。有人提出了更激进的方案：Firecracker做真正的隔离，不同信任级别使用独立虚拟机，代理和主机之间做网络隔离，所有操作都记录审计日志。但也有安全专家泼了冷水：命令黑名单根本不可靠。你能屏蔽rm，但工具可以运行find -name passwd -delete /etc。毕竟find是个正常工具。或者来个alias echo=rm; echo /etc/passwd。这场讨论揭示了一个残酷现实：提示注入目前仍是未解决的问题。如果Google花了好几个月都没能搞定合适的沙箱方案，普通开发者凭什么认为自己两周能做到？最务实的建议或许是：对待AI代理的原则和对待任何员工一样，不要给它访问任何你不想被泄露、破坏、删除或窃取的东西。这不是什么新问题，只是攻击面变大了。正如一位评论者所说：我的解决方案是不给任何工具联网权限。它可以把我的代码库转成ASCII艺术，但由我的人脑来决定是否分享给世界。reddit.com/r/LocalLLaMA/comments/1qocvd4/built_an_ai_agent_with_shell_access_found_out_the
