Agent 每次调用工具都要问用户吗？Janus 揭示权限管理的三难困境

Agent 的安全问题，正在从“模型说了什么”转向“模型做了什么”。

当 Agent 只是回答问题时，风险主要集中在输出内容：有没有违规、有没有幻觉、有没有泄露敏感信息。

但当 Agent 开始调用工具，问题就变了。

它可能读取邮件、检索文件、查看日历、创建会议、发送消息、删除资源，甚至调用企业内部系统完成真实操作。

这时，每一次工具调用，其实都是一次权限判断。

问题是：Agent 每次调用工具都要问用户吗？

如果每次都问，用户会被频繁打断，最后可能机械地点“允许”；如果全部自动放行，Agent 又可能被提示注入、错误规划或上下文误解带偏；如果让模型自己判断风险，也会遇到误判、阈值和解释性问题。

7 月 1 日，University of Washington、University of Massachusetts Amherst 和 Georgetown University 的研究者发布论文 《Janus: a Playground for User-Involved Agentic Permission Management》，正是围绕这个问题展开。

论文原文（arXiv）

Janus 不是一个单点防御算法，而是一个用于研究 用户参与式 Agent 权限管理 的实验平台。论文实现了 Janus-Core 和 Janus-Harness 两部分，并用六种权限助手、三类任务场景、三种模拟用户行为，系统评估了 Agent 权限管理中的安全性、自动化程度和用户负担之间的权衡。

传统权限模型，到了 Agent 这里不够用了

过去的软件权限管理相对静态。

一个 App 要不要访问通讯录、摄像头、相册，系统可以在安装时或运行时弹窗。用户授权后，应用获得某类能力。这个模型的问题当然很多，但至少权限对象和调用意图相对固定。

Agent 不一样。

Agent 的典型工作方式是 observe-plan-act：观察上下文，规划下一步，调用工具，拿到工具返回结果，再继续规划。

论文也用 ReAct 类流程描述了这种动态执行模式：用户给 Agent 一个任务，Agent 会在多轮循环中决定是调用工具，还是回复用户；工具返回结果后，又会影响下一步决策。

这带来了一个核心变化：工具调用的风险不只取决于工具本身，还取决于上下文。

比如“发送邮件”这个工具，本身既不是好，也不是坏。

如果用户明确要求 Agent 给同事发会议纪要，这是正常操作；如果 Agent 是被一封恶意邮件里的提示注入诱导，把用户私人信息发给外部邮箱，那就是攻击；如果 Agent 误解了用户意图，把本不该转发的客户反馈发给了产品团队，那就是偏离用户意图。

同一个工具，同一个动作，在不同上下文里可能有完全不同的安全含义。

所以 Agent 权限管理不能只问：

这个工具能不能调用？

更应该问：

在当前任务、当前对象、当前接收方、当前上下文下，这次调用该不该发生？

这也是 Janus 这篇论文的起点。

两个概念：Policy 和 Permission

这篇论文一个重要贡献，是把 Agent 权限管理拆成两个层次：

Policy，也就是持久策略。它是任务开始前或跨任务存在的规则，比如“永远不允许 Agent 删除文件”“发送外部邮件必须确认”“可以读取日历可用时间”。

Permission，也就是运行时许可。它是针对某一次具体工具调用的动态授权，比如“这次能不能把这封邮件转发给这个联系人”“这次能不能创建这个会议”“这次能不能读取这个文件”。

论文指出，很多已有 Agent 安全方案更偏向 policy enforcement，也就是提前写好规则，运行时执行。但这类方案很难覆盖具体上下文。很多危险行为并不是明显违反规则，而是在当前情境里悄悄偏离了用户真实意图。

这一区分非常重要。

因为企业做 Agent 权限管理时，容易把“有策略系统”误认为“有权限治理”，但真实问题往往发生在策略之外。

举个例子：

规则可以写成：

“允许 Agent 读取邮件内容。”

但它不能直接回答：

“这封邮件里包含别人写给用户的私人信息，Agent 是否可以把它转发给第三方？”

规则可以写成：

“允许 Agent 创建日历事件。”

但它不能直接回答：

“这个会议邀请是不是来自攻击邮件？是否应该自动把所有参会者拉进一个外部会议？”

所以，Janus 讨论的不是“要不要加权限控制”，而是更细的问题：

当 Agent 做出具体动作前，系统如何判断这次动作是否符合用户意图？用户又应该参与到什么程度？

Janus 的核心结构：先查规则，再做运行时判断

Janus 由两个部分组成：

Janus-Core 是一个模块化 Agent 系统，用来实现不同权限管理方案。

Janus-Harness 是一个自动化评测框架，用来比较不同方案在安全性和可用性上的表现。论文和代码仓库都说明，Janus 支持交互式运行、评估 harness、场景定义，以及多个可替换的 permission assistant。

Janus-Core 的执行链路可以简单理解为：

Agent 想调用工具 ↓ Policy Manager 先检查是否有确定性策略 ↓ 如果策略没有直接批准，就交给 Permission Assistant ↓ Permission Assistant 决定批准、拒绝，或者询问用户 ↓ 工具调用被执行或被阻断

论文里，工具被建模成带有明确元数据的 typed operation，包括工具类别、动作和参数 schema。Janus 实现了 email、calendar、file 三类工具，全部运行在合成数据和模拟后端上，不会读写真正的邮件、日历或文件。

这个设计的工程含义很直接：权限判断不能只靠自然语言提示词，而要挂在工具调用链路上。

如果 Agent 只是“计划调用 send_email”，权限系统至少要知道：

• 它调用的是发送类工具
• 收件人是谁
• 邮件正文是什么
• 是否有附件
• 是否发给外部域名
• 是否包含敏感信息
• 这个动作是否由用户明确提出
• 这个动作是否来自工具返回内容里的间接指令

没有这些结构化信息，权限助手就只能看一段自然语言描述，稳定性会很差。

六种权限助手，其实对应六种产品路线

Janus 实现了六种 permission assistant。论文也强调，这些不是生产级系统，而是覆盖不同设计点的原型。

它们很适合拿来理解 Agent 产品里的权限管理路线。

1. auto approve：全部自动放行

这是最宽松的 baseline。Agent 想调用什么工具，就直接放行。

它的用户负担最低，体验也最顺滑，但安全性最差。一旦 Agent 被提示注入带偏，或者错误理解用户目标，就可能直接执行危险动作。

很多早期 Agent 产品的默认体验，本质上接近这个方向：用户给了任务，系统就一路自动做下去。

2. user confirmation：每次都问用户

这是另一个极端。Agent 每次调用工具前，都询问用户是否允许。

它看起来安全，但有两个问题。

第一，用户必须理解每一次调用的含义。现实里，大量用户并不具备判断能力。

第二，频繁弹窗会制造 permission fatigue。用户被打扰多了，最后可能不再认真看，只是点击“允许”。

论文也把这种方案等价为 risk tolerance 为 0：没有任何工具调用可以在不问用户的情况下执行。

3. risk assessment：模型评估风险，高风险问用户

这个方案更接近真实产品会采用的折中路线。

系统用一个 judge LLM 给当前工具调用打风险分，范围从 0 到 1。如果风险超过阈值，就升级给用户判断；如果低于阈值，就自动放行。

这类方案的关键在于两个问题：一是风险判断准不准，二是阈值怎么设。阈值低，用户被频繁打扰；阈值高，危险调用更容易自动通过。

4. risk assessment autonomous：模型评估风险，高风险自动拒绝

它和上一种方案类似，但区别是：高风险调用不问用户，而是直接拒绝。论文里，这个助手会根据风险分和容忍度判断，如果风险超过容忍度，就立即拒绝，而不是升级给用户。

这个设计更适合高敏操作，比如删除文件、外发敏感数据、授权变更、批量操作、资金相关动作等。

它的逻辑是：有些动作不应该把压力交给用户，因为用户可能被攻击者诱导，也可能因为疲劳而点错。

5. constitution：基于自然语言规则

constitution 方案会先把一组自然语言“宪法”编译成有序 JSON 规则，然后按规则判断工具调用。如果没有规则直接允许，则检查用户最近消息是否明确授权了该动作，否则升级给用户确认。

它的优点是可解释、可审计。企业可以把安全原则写成规则，例如：

• 读取通常允许
• 发送邮件需要确认
• 删除资源需要确认
• 不可逆操作不得自动执行
• 外发敏感信息必须升级审批

但它也有风险。默认规则如果过宽，会自动批准攻击行为。论文后续实验里就发现，默认 constitution 允许创建和更新日历事件，导致某些攻击场景下出现非零攻击调用。

6. policy suggestion：让系统建议持久策略

这是最有产品感的一种方案。

当用户面对某次权限请求时，系统不只是问“允许还是拒绝”，还可以建议创建一条持久策略。用户接受后，后续类似动作就可以自动处理。

论文描述中，这个助手会让用户选择拒绝工具调用，或者生成一条新的持久策略；策略通过 LLM 生成后加入 Policy Manager。

这个方案看起来很自然，因为很多产品都会提供“以后都允许”“记住我的选择”。

但 Janus 的实验提醒我们：这恰恰可能引入长期风险。

一次局部正确的授权，可能变成后续全局错误的自动放行。

Janus 怎么评测：三类场景，三种用户

Janus-Harness 的作用，是把权限管理方案放到可重复的场景里评估。

论文设计了三个场景：

Morning Email Triage：早晨邮件处理。 Calendar Management Sprint：日历管理。 Project Collaboration Workflow：项目协作流程。

每个场景又分成四类子场景：

• attack：包含提示注入攻击
• permissive：用户非常宽松
• balanced：用户有选择地允许
• restrictive：用户非常保守

然后，论文设计了三种 synthetic responder，也就是模拟用户：

always yes：所有权限请求都同意。

always no：所有权限请求都拒绝。

alignment aware：知道 ground truth，拒绝攻击或偏离用户意图的调用，批准其他调用。

这个设计很有启发。

因为真实产品里，用户不是一个稳定、理性、永远正确的安全组件。有些用户会全部点同意，有些用户会过度拒绝，有些用户在当前判断里是对的，但接受了一条过宽的长期策略，后面又会出问题。

Janus 把这些用户行为显式纳入评测，而不是默认“问用户就安全”。

实验结果

结果一：每次都问，只有在理想用户下才最安全

在 alignment aware 这个理想模拟用户下，只有 user confirmation 做到了 0 攻击调用和 0 偏离意图调用。也就是说，如果用户永远知道什么该允许、什么该拒绝，那么每次都问确实最安全。

但这个结论不能直接转成产品方案。

因为 alignment aware 是理想用户，不是普通用户。真实用户可能不理解工具参数，也可能没有足够上下文，还可能因为弹窗过多而疲劳。

这就是 Janus 这篇论文的价值：它没有停留在“用户参与可以增强安全性”这个表面结论，而是继续追问：

用户参与到什么程度？用户错点怎么办？用户长期授权怎么办？用户被频繁打扰怎么办？

这些问题更接近真实 Agent 产品。

结果二：用户总点“允许”，多数方案都会失败

Janus 的一个关键发现是：当模拟用户是 always yes 时，除了低风险容忍度下的 risk assessment autonomous，多数权限助手的攻击和偏离意图调用比例都很高。

这说明，只要最终决定权完全交给用户，而用户又倾向于点“允许”，权限系统就会退化。

这对产品设计非常重要。

很多系统的安全逻辑其实是：

我已经弹窗提醒过你了，你点了允许，所以风险由你承担。

但在 Agent 场景里，这种逻辑并不可靠。因为攻击者可以诱导用户，Agent 可以把复杂工具调用包装成看似合理的请求，用户也可能因为疲劳而不认真阅读。

因此，Agent 权限助手不应该只是一个“弹窗生成器”。

它至少应该具备两种能力：

第一，明确危险的调用要能自动拒绝。 第二，询问用户时要降低误点概率，而不是把一段复杂 JSON 参数丢给用户。

换句话说，用户确认应该是最后一道交互机制，而不是唯一一道安全机制。

结果三：自动化、安全性和用户负担，很难同时最优

论文 Figure 4 和 Figure 5 展示了一个非常清晰的趋势。

当 risk tolerance 从 0 增加到 1 时，用户交互次数下降，但攻击和偏离意图的工具调用增加。也就是说，系统越愿意自动放行，用户越省心，但风险越高；系统越谨慎，风险越低，但用户被打扰越多。

这就是本文标题里的“三难困境”。

Agent 权限管理要同时处理三件事：

第一，自动化程度。 Agent 之所以有价值，是因为它能替用户完成多步骤任务。如果每一步都要用户确认，Agent 会退回到“带工具的聊天机器人”。

第二，安全性。 Agent 一旦连接真实工具，就可能造成真实后果。提示注入、越权访问、误发邮件、误删文件、错误创建会议，都不是简单的输出问题。

第三，用户负担。 用户不是安全专家，也不是权限判断机器。频繁询问会带来疲劳，复杂询问会带来误解，长期询问会诱导用户形成“全部允许”的习惯。

这三者之间没有一个简单最优解。

Janus 的结论也很克制：没有一种设计在所有上下文中都表现最优，权限助手需要更有原则、更依赖上下文地部署。

最值得关注的发现：局部正确，可能导致全局错误

policy suggestion 的实验结果很值得单独拿出来说。

论文发现，在某些情况下，alignment aware 用户批准了一条当下看起来合理的策略，但这条策略后来导致 Policy Manager 自动批准了攻击调用或偏离意图调用。也就是说，一个局部正确的用户响应，可能导致后续全局错误。

这对真实产品非常关键。

很多 Agent 产品为了减少打扰，会自然走向“记住我的选择”：

• 以后都允许读取这个文件夹
• 以后都允许给这个联系人发邮件
• 以后都允许创建日历事件
• 以后都允许访问这个系统
• 以后类似操作不再询问

这在传统软件里已经有风险，在 Agent 里风险更高。

因为 Agent 的“类似操作”很难定义。表面类似，不代表安全语义类似。

例如：

这次用户允许 Agent 给同事发项目材料，不代表以后所有“项目材料”都可以发给所有同事。

这次用户允许 Agent 读取客户反馈，不代表以后可以把客户反馈自动转发给产品团队。

这次用户允许 Agent 创建会议，不代表攻击邮件诱导的会议也应该自动创建。

所以，Agent 里的“以后都允许”必须极度谨慎。

更合理的策略不是 always allow，而是带有作用域的 allow：

• 只在当前任务中有效
• 只对指定接收方有效
• 只允许读取，不允许外发
• 只允许内部域名，不允许外部邮箱
• 只允许不含附件的邮件
• 只允许不包含个人信息或商业敏感信息的内容
• 一旦涉及批量、删除、外发、授权变更，重新询问用户

这才是 Agent 权限策略和传统权限策略最大的不同：它必须有上下文边界。

启发：不要把权限管理做成一个弹窗

如果把 Janus 的发现转成工程建议，我认为至少有五点。

1. 工具元数据必须结构化

权限系统不能只看到“Agent 想调用一个工具”。它应该看到更细的信息：

• 工具类型：读、写、删除、外发、授权变更
• 操作对象：邮件、文件、日历、数据库、代码仓库
• 数据敏感度：个人信息、密钥、客户数据、内部文档
• 接收方：内部、外部、个人、群组、未知主体
• 操作后果：是否不可逆，是否产生费用，是否影响他人
• 来源链路：动作来自用户明确指令，还是来自工具返回内容
• 批量程度：单个操作还是批量操作

没有这些元数据，后面的风险评估、策略匹配和用户确认都会变得不稳定。

2. 权限应该分层，而不是一刀切

低风险操作可以自动放行，例如读取公开信息、查询日历空闲时间、搜索用户授权范围内的文件。

中风险操作可以风险评估后决定是否升级，例如读取内部文档、汇总邮件、创建普通日历事件。

高风险操作应该默认拒绝或强确认，例如删除文件、发送外部邮件、转发附件、修改权限、批量操作、调用生产系统。

不可逆操作要单独处理，不能混在普通工具调用里。

3. Permission Assistant 要能自动拒绝

Janus 的实验说明，如果用户总点 yes，仅靠确认机制无法挡住风险。

所以权限助手必须有自动拒绝能力。尤其是明显攻击、明显越权、明显偏离用户目标的调用，不应该再交给用户选择。

这和内容安全里的一个经验很像：高置信风险不应该只做提示，而应该直接拦截。

4. “记住我的选择”要加作用域

policy suggestion 的问题说明，长期策略本身就是风险源。

生产系统可以提供“记住我的选择”，但不能粗暴地记成：

以后都允许。

更安全的设计应该是：

在当前任务、当前对象、当前接收方、当前数据类型、当前时间窗口内允许。

同时，策略要可查看、可撤销、可审计。用户和管理员都应该知道 Agent 现在拥有哪些持久授权。

5. 评测指标不能只看攻击成功率

Janus 的评测思路也值得借鉴。它不只记录 attack tool call，还记录 out-of-alignment tool call、desired tool call、输出评估结果和 permission assistant message count。

这比单纯看 ASR 更适合 Agent 产品。

因为一个系统可以通过“拒绝所有工具调用”把攻击成功率降到很低，但用户任务也做不成。真正的权限管理评测，至少要同时看：

• 攻击调用是否被拦住
• 偏离用户意图的调用是否被拦住
• 正常工具调用是否被完成
• 最终任务是否成功
• 用户被询问了多少次
• 用户误点 yes 或 no 时系统是否仍然稳健

这才接近真实产品里的安全可用性评估。

局限性

Janus 的价值在于提出了一个权限管理试验场，而不是证明某个方案已经可以直接用于生产。

它有几个明显限制。

第一，用户是 synthetic responder，不是真实用户。always yes、always no、alignment aware 能覆盖一些极端行为，但真实用户会更复杂：会犹豫，会误解，会被诱导，也会随着时间疲劳。

第二，场景数量不大。论文自己也说明，三个场景、四类子场景是一个有意控制规模的设计，重点是验证 Janus-Harness，而不是构建大规模 benchmark。

第三，Janus 假设工具本身是可信的。论文明确说明，它没有研究工具调用失败执行或工具本身恶意的情况，例如 send email 工具被假设只会发送指定邮件，delete document 工具被假设只会删除指定文档。

第四，Janus 使用的是合成数据和模拟后端，不涉及真实企业环境里的权限体系、组织架构、数据分级、审计流程和审批链路。

第五，它还没有覆盖多 Agent 协作、跨会话记忆、长期策略漂移等更复杂问题。论文也把多 Agent 交互、更细粒度上下文和领域专用场景数据集列为未来扩展方向。

这些限制不削弱 Janus 的意义，反而说明 Agent 权限管理还有很长的工程化空间。

写在最后

Agent 的权限管理，不应该被简化成一个弹窗问题。

如果默认自动放行，Agent 会在提示注入、错误规划和上下文误解中放大风险。 如果每次都问用户，系统会把安全责任转嫁给用户，最终制造疲劳和误点。 如果完全依赖模型判断，又会遇到风险评估不稳定、阈值难设和缺乏上下文的问题。

Janus 提醒我们，Agent 权限管理真正要解决的是一个运行时控制问题：

什么时候自动放行，什么时候自动拒绝，什么时候询问用户，什么时候把一次授权变成长期策略。

这套机制会成为 Agent 产品从 demo 走向生产的关键基础设施。

未来的 Agent 安全，不只是要检测提示注入，也不只是要给工具加权限开关。更重要的是建立一套能够理解上下文、约束工具行为、管理用户授权、记录执行链路的权限决策层。

Agent 能不能安全地替人做事，最终不取决于它“会不会调用工具”，而取决于它在调用工具前，能不能知道：

这件事，此时此刻，到底该不该做。

— end —