怀古游戏宅SIR如果你把一个带有“文件读写权限”的 Agent 放进工作目录，第一反应通常是：这不就和普通进程一样吗？我只要遵循最小权限原则，给它刚好够用的权限，不让它越界，安全上就稳了。可实际跑起来你会发现，这套操作系统时代总结出来的金科玉律，到了由大模型驱动的智能体世界里，正在一处接一处地失灵。最小权限原则本身没有错，错的是它隐藏了一整套关于“主体是谁、意图是否稳定、权限能否预计算”的假设，而这些假设在 Agent 场景里几乎全部不成立。
这篇文章不打算停留在“智能体很危险，大家要小心”的层面。我会用做系统安全和做 Agent 框架的双重视角，把最小权限原则的底层前提拆开，讲清楚它在智能体领域到底断在了哪些环节，然后给出我在实际项目里验证过的权限改造思路。无论你是在搭个人 Agent、开发企业内部智能体平台，还是在给 Agent 设计工具调用安全方案，这篇内容都应该能帮上忙。
1. 先回到操作系统：最小权限本来依赖哪四个稳态条件
1.1 最小权限在进程世界里为什么“够用”
最小权限原则说起来非常朴素：每个主体（进程、用户、服务）只拥有完成自身任务所必需的权限，不多给一分。在操作系统里，这个原则被贯彻了几十年，靠的是一整套非常具体的机制。文件权限位区分属主、属组和其他人；进程以非 root 的低权限用户运行；POSIX capabilities 把 root 的超级权限拆成几十个可独立授予的能力项；SELinux 或 AppArmor 还能给进程额外套一层强制访问控制标签。
这套体系的效果是实实在在的。Web 服务器以 www-data 用户运行，读不了 /etc/shadow；数据库进程即使被攻破，默认也无法直接覆盖系统二进制文件；一个只负责打印任务的程序，根本不会被授予网络监听能力。在传统进程模型里，“最小权限”是一个可规划、可审计、可校验的目标，安全工程师可以坐下来，对着代码和配置把进程需要的权限一条条列出来。
这套模型之所以能运行得这么好，不只是因为它有完善的权限检查机制，更关键的是它背后默认了一个非常稳定的世界：程序的行为是代码写死的，执行路径相对确定，主体身份由内核追踪，权限边界在进程启动前就能基本划清楚。
1.2 真正支撑它成立的是四个稳态假设
把操作系统的权限模型放到显微镜下看，你会发现它至少依赖以下四个“稳态前提”，只是平时很少有人点破。
其一，主体意图是稳定的。传统进程没有“自由意志”，它的每一步行为都由代码决定。无论代码写得再复杂，安全审计员原则上可以通过代码审查来判断它可能需要哪些权限。权限一旦授予，程序一般也不会在运行中途突然“改主意”去做另一件事。
其二，权限集合是可以预枚举的。操作系统里的客体相对静态：文件、目录、设备、端口、进程信号，数量有限且命名规则清晰。给某个进程授权的本质，就是从一个相对有限的权限清单里做减法或加法。
其三，授权与执行之间是机械对应的。进程每次发起系统调用，内核都会执行权限检查，且检查逻辑是确定性的。你不可能通过给内核发送一段文本，让它改变对主体身份的判定。
其四，资源边界是封闭的。进程活在操作系统划定的边界内，能触达的资源类型和范围由内核统一仲裁，没有“越过系统调用去操纵外部服务”的通道。
在以上四个前提下，最小权限原则是成立的，也是最有效的纵深防御手段之一。你不需要担心进程被人用语言“说服”去执行超出代码逻辑的操作，也不需要频繁在运行过程中动态改写权限边界。
1.3 大模型 Agent 把每一条稳态假设都打破了
当执行者从一段静态代码变成一个由大模型驱动、能自主规划并调用外部工具的 Agent 时，四个稳态前提开始逐个崩塌。
意图稳定性没了：Agent 的“计划”不是预先写死的，而是根据每次输入的上下文实时生成的；同一个用户请求，换一种 Prompt 描述，Agent 选择的工具路径可能完全不同。