未来的 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.01510
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 把这些用户行为显式纳入评测，而不是默认“问用户就安全”。
六、实验结果
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 能不能安全地替人做事，最终不取决于它“会不会调用工具”，而取决于它在调用工具前，能不能知道：这件事，此时此刻，到底该不该做。
