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

未来的 Agent 安全不只是要检测提示注入也不只是要给工具加权限开关。更重要的是建立一套能够理解上下文、约束工具行为、管理用户授权、记录执行链路的权限决策层。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》正是围绕这个问题展开。https://arxiv.org/pdf/2607.01510Janus 不是一个单点防御算法而是一个用于研究 用户参与式 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 把这些用户行为显式纳入评测而不是默认“问用户就安全”。六、实验结果1. 结果一每次都问只有在理想用户下才最安全在 alignment aware 这个理想模拟用户下只有 user confirmation 做到了 0 攻击调用和 0 偏离意图调用。也就是说如果用户永远知道什么该允许、什么该拒绝那么每次都问确实最安全。但这个结论不能直接转成产品方案。因为 alignment aware 是理想用户不是普通用户。真实用户可能不理解工具参数也可能没有足够上下文还可能因为弹窗过多而疲劳。这就是 Janus 这篇论文的价值它没有停留在“用户参与可以增强安全性”这个表面结论而是继续追问用户参与到什么程度用户错点怎么办用户长期授权怎么办用户被频繁打扰怎么办这些问题更接近真实 Agent 产品。2. 结果二用户总点“允许”多数方案都会失败Janus 的一个关键发现是当模拟用户是 always yes 时除了低风险容忍度下的 risk assessment autonomous多数权限助手的攻击和偏离意图调用比例都很高。这说明只要最终决定权完全交给用户而用户又倾向于点“允许”权限系统就会退化。这对产品设计非常重要。很多系统的安全逻辑其实是我已经弹窗提醒过你了你点了允许所以风险由你承担。但在 Agent 场景里这种逻辑并不可靠。因为攻击者可以诱导用户Agent 可以把复杂工具调用包装成看似合理的请求用户也可能因为疲劳而不认真阅读。因此Agent 权限助手不应该只是一个“弹窗生成器”。它至少应该具备两种能力第一明确危险的调用要能自动拒绝。第二询问用户时要降低误点概率而不是把一段复杂 JSON 参数丢给用户。换句话说用户确认应该是最后一道交互机制而不是唯一一道安全机制。3. 结果三自动化、安全性和用户负担很难同时最优论文 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 能不能安全地替人做事最终不取决于它“会不会调用工具”而取决于它在调用工具前能不能知道这件事此时此刻到底该不该做。