AI Agent不应持有你的钥匙：权限最小化原则

Windows 据报道正在加入一个在后台运行、可以访问个人文件夹的 AI agent。看到这条新闻时，我感受到了一种和初级开发说"就看一下生产数据库密码"时一模一样的寒意。

这是 agent 权限问题在桌面端的降临，而这个问题在我们的系统中已经被忽视了两年。

有一个事实是产品发布会上没人会说的：危险不在于模型本身。模型只是一个文本预测器。危险在于你赋予它的隐性权限。一个在后台运行、可以读取 Documents 文件夹的 agent，不是功能——是一个穿着友好名字的 root shell。

我在生产环境运行 agent，也构建过 tool-calling 循环、重试逻辑、断路器。而我学到的最重要的一条规则是：一个 agent 只能持有当前任务所需的权限，且只在任务执行期间有效。不是整个会话。不是后台守护进程。不是"只要它觉得有用就开着"。

这条规则不是可选项。它是工具和负债之间的分水岭。

让我具体说说为什么后台访问比前台 prompt 在本质上更危险。当你在聊天窗口输入一条 prompt 时，你是在做一个有意识的决定。在行动的那一刻，有一个人类在决策链中。模型看到的是你展示给它的东西，而且你可以观察它工作。后台 agent 则什么都没有：它按计划或按事件触发，没有人看着，用的是一次授权就永不收回的凭证。

这不是 AI 问题。这是权限问题，而我们几十年前就解决了它。这叫最小权限原则。这叫作用域凭证。这叫短期令牌。我们知道怎么做。我们只是不断选择不去做。

我在自己的 agent 系统中使用的模式很无聊，但有用。每一个 tool call 都经过一个 schema，精确声明它触及了什么。agent 拿到的不是文件系统句柄——而是一个封装了检查的 read_file(path) 函数。检查会问：这个路径在白名单里吗？这个操作在当前任务的范围内吗？如果不是，就失败关闭。不存在隐性访问，不存在"既然你都进来了，顺便看看也无妨"。

而且我在每次调用执行之前就记录日志，包括参数。不是之后。是之前。因为你从用户那里收到的 bug 报告从来不是"agent 读了我的报税单"——而是"昨天它做了什么奇怪的事"。没有日志，你就只有故事。没有日志，你只有谜团。

现在把这个思路扩展到操作系统层面。一个能后台访问个人文件夹的 OS 级 agent，等同于把 root 权限给了那个 agent——不是技术层面的，是实际层面的。个人文件夹里是一切：凭证文件、浏览器数据、财务文档、私钥、那封你永远没发出的愤怒邮件草稿。爆炸半径不是沙箱，而是你整个数字生活。

而最让我困扰的是这部分：同意模型。"用户同意了"不是真正的同意，当那份协议藏在安装向导里，而后果是隐形的时候。同意必须是明确的、知情的，并且在粒度上与访问权限一致。如果我不能说"agent，你可以读我的 Downloads，但不能读我的 Documents"，那我就没有真正的同意。我只有一个服务条款的勾选框。

我不是反 agent。我以此为生。但帮助你的 agent 和对你的生活拥有长期入场券的 agent 之间，有本质区别。前者是工具。后者是一个等待 prompt injection 来兑现的漏洞。

因为这是另一件没人想谈的事。一个有文件访问权限的后台 agent 就是一个靶子。Prompt injection 不是理论问题——它已经是一种被实证的攻击类别。如果你的 agent 读取网页内容、邮件或任何攻击者可以影响的东西，那些内容就可以携带指令。而如果这些指令能到达一个拥有隐性文件访问权限的工具，你就刚刚在用自己的机器、凭自己的凭证构建了一个远程控制后门。

解决方案不是放弃 agent。解决方案是把 agent 权限当作我们对待 root 访问的方式来处理。最小权限。明确的、作用域内的同意。会过期的短期授权。你能真正看懂的审计日志。以及默认拒绝——agent 提问，用户批准，行为发生，权限消亡。

只有当我看到权限模型而非功能演示时，我才会相信 Windows 做对了。给我看作用域控制。给我看撤销机制。给我看当 agent 碰到不该碰的文件时会发生什么——它是失败关闭了，还是因为能读就读了？

在那之前，诚实的工程判断是：一个能访问个人文件夹的后台 agent 是一场还没发生的网络安全事件。我们花了两年构建能让 agent 做事。接下来的两年需要花在构建只能做它们被允许做的事的 agent 上。

这才是困难的部分。这才是真正的产品。