加载失败
Agent Safehouse 是一个开源尝试：作者偏好在“精调”的本机上全自动运行代理，于是用 macOS 的 sandbox-exec（macOS 的进程沙箱工具）和 SBPL 策略文件来生成最小权限配置，并提供在线 Policy Builder 与按集成拆分的可审计策略。讨论建立在两个前提上：用户希望本地运行以保留 Apple API/Keychain 等能力；以及必须区分“文件系统误操作”和“凭据/提示注入导致的越权调用”两类威胁。评论延伸出跨平台难题（Linux 的 landlock、bubblewrap，以及 macOS 的 Virtualization.framework/VM 替代方案）、sandbox-exec 的弃用与潜在漏洞，以及需要在沙箱之上增加短期凭据、工具层 JIT 授权和行为检测的监督层等工程与安全议题。
作者将 Agent Safehouse 设计为在本机运行代理的无依赖包装器，核心是为 macOS 的 sandbox-exec 生成最小化权限的 SBPL 策略，并提供在线 Policy Builder 可导出单个配置放入 dotfiles。项目把每个代理/集成的策略拆成可审计的文件，并声称针对自动更新、Keychain 集成、粘贴图片等场景手工摸索出最小权限集合。作者已实现自定义覆盖策略、默认允许 ~/.gitignore、并通过 PR 增加了对更多进程控制与 LLDB 的集成；仓库里也包含 E2E 测试以验证沙箱行为。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
评论普遍把风险拆成两类：一类是代理“误操作”造成的本地破坏（例如 rm -rf 或误改全局配置），这类问题文件系统沙箱可以很好地防止；另一类是代理在读取恶意输入或已有凭据后被 prompt injection 导致对外部系统越权，沙箱在代理已获取凭据或内存中已有密钥时无法阻止。多条评论建议采用短期受限凭据或本地守护进程发放 scoped short‑lived JWT／JIT 授权来限制代理对外资源的能力，或引入工具调用前的审核签名以把凭据与动作粒度化。有人还提议把“信任级别”动态化——当代理被“污染”时自动收窄其权限和账单上限，以减少提示注入风险。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多位评论指出 sandbox-exec 自 macOS Sierra（2016）就被标为 deprecated，但仍广泛可用并被若干客户端使用；有人认为它之所以被弃用部分原因是缺乏文档和维护。评论中同时警告历史上存在绕过沙箱的安全研究并预测潜在 CVE 风险，担忧长期依赖一个已弃用工具可能带来的漏洞与可维护性问题。也有观点认为底层沙箱机制仍被系统与第三方广泛使用，短期内完全移除并不现实，因此目前是可用但需谨慎审计的权衡方案。
评论区讨论了多种替代路径：有人建议直接把代理放到独立 VPS 或完整 macOS VM（通过 Apple Virtualization.framework）来隔离，而不是在宿主机上做细粒度限制；还有人指出 macOS 不像 Linux 那样有原生容器原语，导致无法复现 Linux 上的轻量隔离体验。Linux 方面常被提到的原语有 landlock（Linux 内核的沙箱机制）和 bubblewrap（Linux 的用户空间沙箱工具，Anthropic 的 sandbox-runtime 基于它），但社区认为缺少成熟的策略层与易用工具。也有混合方案建议，如给代理独立无特权用户账号（sandvault 思路）叠加 sandbox-exec 做双层防护。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
许多评论把可审计性当成信任此类工具的关键：作者采用 Bash 实现以避免不透明二进制，并把策略拆成按代理/集成的小文件，且提供 E2E 测试和在线 Policy Builder 以便审查。社区建议更偏向可审查的安装产物（比如 tarball 或可核验的构建流程），并希望项目重构为社区管理规则库加可视化生成器，这样能达到“零信任”或更易验证的目标。整体诉求是：详细文档 + 可读、自动化的测试证明策略确实按说明限制了代理行为，才能在保守或合规环境中被采纳。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
有评论报告代理在被沙箱阻止时会“疯狂”尝试绕过或反复重试，建议在被拦截点给出明确反馈（例如返回“Connection refused by the sandbox”）以阻止无限循环。多条意见认为仅有沙箱边界不够，需建设监督/审核层（supervisor agent）或 incident‑aware agents 来检测异常行为、生成事件报告并建议修复。实现手段包括拦截工具调用做签名/审批、用 LLM 在 plan 模式先写安全策略，或在运行时对危险行为自动降级或报告以实现人为介入。
实战中遇到的工程问题包括在沙箱内启动 headless Chrome 不稳定、对进程访问（如 lldb、pkill）的粒度控制存在两难，以及 macOS 缺乏真正的 overlay/COW 文件系统命名空间。作者已添加对进程控制的可选集成并建议通过本地覆盖策略白名单来允许特定全局文件（例如 ~/.gitignore），但有用户仍希望像 Linux 那样提供 copy‑on‑write 或 bind‑mount 级别的隔离以便“允许写但最终丢弃”。社区里有若干尝试（如 Treebeard、Amika、yoloai）但都在 macOS 的平台限制下折中，导致一些使用场景仍难以完美支持。
sandbox-exec: macOS 的进程沙箱工具，使用 SBPL（沙箱配置文件）来限制文件、进程和部分系统调用；官方文档标注为 deprecated，但仍可在许多系统上使用来强制执行本地策略。
SBPL: Sandbox Profile Language（或 Seatbelt 策略语言），macOS 沙箱的配置语法，用于定义 sandbox-exec 的白名单/黑名单规则和细粒度权限。
landlock: Linux 内核提供的一种安全原语，用于对进程的文件系统访问做限制，理论上可用于构建类似 macOS 上 sandbox‑exec 的文件级沙箱。
bubblewrap: Linux 上的用户空间沙箱工具（常用于 Flatpak），通过 user namespaces 等机制隔离进程；Anthropic 的 sandbox-runtime 在 Linux 平台上就采用了 bubblewrap。
prompt injection: 对 LLM/代理输入中注入恶意或误导性指令以促使模型执行不良操作的攻击向量，属于沙箱无法单纯通过文件系统限制解决的风险。