Janus：用户参与的代理权限管理游乐场

# Janus：一个用户参与式智能体权限管理实验平台
来源：https://arxiv.org/html/2607.01510

###### 摘要

能够自主代表用户执行工具调用的AI智能体引发了关于权限管理的紧迫问题：用户可能扮演什么角色，又应该扮演什么角色？尽管已有许多方法被提出，但用户在这一过程中的角色仍未得到充分探索。我们引入了Janus，一个用于实现和评估用户参与式智能体权限管理设计的实验平台系统。Janus由两个组件构成：Janus-Core，一个支持多种权限管理设计的模块化智能体系统；以及Janus-Harness，一个自动化评估框架。基于一个识别用户参与关键设计轴的概念模型，我们实现了覆盖设计空间的六个权限助手，并在三个场景和三个合成响应者上进行了评估。我们证明了用户输入至关重要，可以显著增强隐私与安全性；AI对用户决策的增强有助于降低认知负荷；以及系统设计必须考虑真实的用户行为，包括权限疲劳。没有单一设计在所有情境下都能表现最佳，这促使我们在智能体系统中采用更原则化、情境敏感的部署方式。Janus已公开提供，以支持未来在智能体系统设计这一维度上的研究。

## 1 引言

AI智能体，或智能体系统，被定义为“包含一个或多个AI模型的复合软件系统，它们在环境中运行并执行操作”[1 (https://arxiv.org/html/2607.01510#bib.bib1)]。与之前的系统相比，它们允许用户以前所未有的低参与度完成任务，能够处理短周期和长周期任务、与其他智能体协作，并在多种输入上运行。这些能力对隐私和安全具有重大影响，特别是考虑到来自提示注入攻击[2 (https://arxiv.org/html/2607.01510#bib.bib2),3 (https://arxiv.org/html/2607.01510#bib.bib3)]、幻觉引发的不当行为[4 (https://arxiv.org/html/2607.01510#bib.bib4)]以及与用户意图不一致[5 (https://arxiv.org/html/2607.01510#bib.bib5)]的威胁。因此，控制智能体做什么或能做什么至关重要。系统安全中的一个经典原则是**完全中介原则**，该原则认为“对每个对象的每次访问都必须检查权限”[6 (https://arxiv.org/html/2607.01510#bib.bib6)]。另一个相关原则是**最小权限原则**：“每个程序和每个系统用户都应该使用完成任务所需的最小权限集操作”[6 (https://arxiv.org/html/2607.01510#bib.bib6)]。这两个原则共同要求智能体系统必须验证所有资源访问，并仅将其限制在用户请求任务所需的资源上。然而，在实践中，访问决策的数量庞大以及现实场景的复杂性使得这一点难以实现。

考虑一个负责管理用户电子邮件收件箱的智能体。收到的信息多种多样，从明确的攻击（如钓鱼尝试）到非恶意但模棱两可的请求——现代大语言模型（LLM）往往难以解决这些请求[7 (https://arxiv.org/html/2607.01510#bib.bib7),8 (https://arxiv.org/html/2607.01510#bib.bib8)]。一个要求智能体将家庭聚会详情转发给的人，可能是合法的亲戚，也可能不是；正确的行动可能完全取决于只有用户才了解的背景。将这种模糊性乘以每天数十次的交互，有原则的权限管理挑战就变得清晰。此外，由于智能体系统可能产生不可预测的轨迹，且用户以非结构化的语言进行交互，评估权限变得尤其困难。

智能体系统可以采用多种权限管理方法，涉及不同类型的用户参与。一种直接的选择（许多商业智能体最初使用）是始终在运行时询问用户。然而，这种方法假设用户具备完全的专业知识和持续的关注，这在规模上不现实（例如，考虑到提示疲劳[9 (https://arxiv.org/html/2607.01510#bib.bib9)]），因此常常退化为过度授权。预定义的持久策略是另一种选择——在最近的一些智能体系统安全工作中有所探索（例如[10 (https://arxiv.org/html/2607.01510#bib.bib10),11 (https://arxiv.org/html/2607.01510#bib.bib11)]）——但指定它们需要大量前期投入。此外，虽然这些策略可以防止某些类型的攻击或数据泄露，但它们可能无法区分依赖于运行时细微上下文的个别案例。在用户（不）参与的另一端，完全自动化权限决策可以改善任务流程，并且在模型足够强大的情况下可能表现良好（尤其是当用户缺乏对后果的直觉时），但也消除了用户提供系统缺乏的上下文的能力。组合方法总是可能的：持久策略或自动化手段处理一些权限决策，而其他决策则升级给用户。

尽管先前的工作和商业产品已经提出并实现了这些不同的权限管理方法，但用户在此过程中的角色仍未得到充分探索[12 (https://arxiv.org/html/2607.01510#bib.bib12)]。本文为智能体系统中用户参与的运行时权限管理提供了基础。具体来说，我们引入了Janus，一个用于实验性探索不同权限管理方法的系统实验平台，以罗马的门神命名。我们的目标是帮助实践者和研究人员设计和选择权限系统，通过分析不同方法如何影响可用性和在防止对抗性或不当工具调用方面的有效性。我们首先阐述智能体系统如何在运行时进行权限管理的概念模型，展示现有系统如何映射到这个抽象，并识别用户参与权限管理的关键设计轴（第3节 (https://arxiv.org/html/2607.01510#S3)）。利用这个模型，我们构建了Janus-Core，一个用于实现和实验设计空间中不同点的工具包，并在该工具包内实现了一系列权限管理方法（第4节 (https://arxiv.org/html/2607.01510#S4)）。我们还实现了Janus-Harness，一个用于比较设计的评估框架（第5节 (https://arxiv.org/html/2607.01510#S5)）。Janus-Core和Janus-Harness共同构成了Janus。然后，我们使用Janus评估我们实现的用户参与式运行时权限管理方法，并在此过程中研究这些方法并展示实验平台的实用性（第6节 (https://arxiv.org/html/2607.01510#S6)）。我们的发现强调，用户输入至关重要，可以显著增强隐私与安全性，同时AI对用户决策的增强有助于降低认知负荷。鉴于没有单一设计是完美的，我们的工作推动了一种细致、情境依赖且用户知情的权限管理方法。

## 2 背景与相关工作

### 2.1 AI智能体架构与攻击

AI智能体，或智能体系统，包含一个经过指令微调的语言模型，能够使用工具（即对外部服务如邮件服务器的API调用），并能够与其用户通信以及在交互和工具调用之间保持上下文。我们聚焦于一个场景：用户向智能体AA提供提示pp，然后AA进入一个循环，每一步决定是执行工具调用tt还是向用户回复rr。执行工具调用tt后，智能体将结果添加到上下文，并继续循环，可能调用更多工具或响应用户。这种动态控制流方法被称为ReAct[13 (https://arxiv.org/html/2607.01510#bib.bib13)]，它是每个智能体系统的基础，因为它允许智能体响应上下文的变化和额外的指令。关键的是，某些返回的结果（例如邮件内容）可能携带恶意指令（即提示注入[14 (https://arxiv.org/html/2607.01510#bib.bib14)]）。一个接受提示pp并决定在上下文cc上执行工具tt的智能体，可能接收到带有提示注入的响应：A(p)→t(c)→r*A(p) \rightarrow t(c) \rightarrow r^*，一旦这个响应被整合到新上下文c*c^*中，智能体可能产生下一个工具为有害的t*t^*并执行它：A(c*)→t*(c*)A(c^*) \rightarrow t^*(c^*)。由于这些智能体被设计为适应其控制流，执行有害操作t*t^*可能危及用户的安全和隐私[15 (https://arxiv.org/html/2607.01510#bib.bib15)]。

### 2.2 智能体系统中的策略与权限

当前正在发展大量关于智能体安全的系统设计和架构的文献，认识到并论证仅靠模型改进无法提供足够的安全保障，还需要系统级方法[16 (https://arxiv.org/html/2607.01510#bib.bib16)]和用户参与[12 (https://arxiv.org/html/2607.01510#bib.bib12)]。在回顾相关工作以及我们之后的概念模型（第3节 (https://arxiv.org/html/2607.01510#S3)）中，我们注意到权限管理技术包括**策略**（在特定任务之前指定并在任务执行期间确定性应用的规则）和**权限**（在运行时动态授予或拒绝的许可）。这两个概念当然可以共存和重叠：例如，对权限提示回答“是，并且始终允许”既授予了该权限，也更新了全局策略。

到目前为止，智能体系统安全领域的许多相关工作主要通过**预先编写的策略**在运行时执行来涉及用户。例如，CSAgent[17 (https://arxiv.org/html/2607.01510#bib.bib17)]提出了一个用于计算机使用智能体的系统级访问控制框架，开发者在配置期间编写或生成意图感知和上下文感知的策略。在CaMeL[11 (https://arxiv.org/html/2607.01510#bib.bib11)]中，架构特权分离（下文进一步讨论）可以与运行时应用的预写安全策略结合使用。类似的策略执行思想在Progent[10 (https://arxiv.org/html/2607.01510#bib.bib10)]、ACE[18 (https://arxiv.org/html/2607.01510#bib.bib18)]和FORGE（原PCAS）[19 (https://arxiv.org/html/2607.01510#bib.bib19)]中也有探索。虽然这些持久策略可以防止许多提示注入和相关攻击，但它们仍然可能容易受到更微妙的攻击，这些攻击取决于运行时的特定上下文：例如，攻击行为可能在预期计划的范围内（例如，根据邮件中的指令采取行动）[20 (https://arxiv.org/html/2607.01510#bib.bib20),21 (https://arxiv.org/html/2607.01510#bib.bib21)]。而且，这些系统的预写策略往往很复杂（例如用Python或DSL编写），普通用户不太可能实际编写——尽管一些工作探索通过从自然语言推导策略来减轻这一负担，例如IronCurtain[22 (https://arxiv.org/html/2607.01510#bib.bib22)]，它将用户提供的自然语言“宪法”编译成JSON策略。

少数工作探索了**动态的每任务权限**，作为持久策略管理的替代或补充。例如，Conseca[23 (https://arxiv.org/html/2607.01510#bib.bib23)]提出了一种特权“策略生成器”，它在上下文完整性理论[24 (https://arxiv.org/html/2607.01510#bib.bib24)]的指导下创建任务和上下文特定的策略。补充性地，Wu等人[25 (https://arxiv.org/html/2607.01510#bib.bib25)]探索了基于用户过去偏好和相似用户偏好的智能体系统权限预测。IronCurtain[22 (https://arxiv.org/html/2607.01510#bib.bib22)]将其基于宪法的确定性策略与（可选的）基于用户提示的运行时权限预测器结合起来。Progent[10 (https://arxiv.org/html/2607.01510#bib.bib10)]探索了一个概念验证扩展，其中每任务策略由AI生成。最后，一种日益常见的、功能上提供每任务权限的方法是将（1）一个更特权的、不访问不可信数据的规划组件与（2）一个受抽象计划约束的、低特权的执行组件分离。这种思想例如在CaMeL[11 (https://arxiv.org/html/2607.01510#bib.bib11)]和ACE[18 (https://arxiv.org/html/2607.01510#bib.bib18)]中实现。

最后，有一些工作指出了在运行时进行策略或权限指定和执行的普遍需求，但对这些策略或权限如何指定保持不可知：例如，IsolateGPT[26 (https://arxiv.org/html/2607.01510#bib.bib26)]提出智能体系统的组件隔离，有机会在隔离边界上执行策略，而AC4A[27 (https://arxiv.org/html/2607.01510#bib.bib27)]提出了一个可以通过策略或权限实施的访问控制框架。

### 2.3 其他语境下的策略与权限

访问控制和权限管理起源于多用户系统的语境[28 (https://arxiv.org/html/2607.01510#bib.bib28),29 (https://arxiv.org/html/2607.01510#bib.bib29),6 (https://arxiv.org/html/2607.01510#bib.bib6),30 (https://arxiv.org/html/2607.01510#bib.bib30)]。然而，随着像Android这样的单用户系统开始在不同的“用户”ID下隔离不同的程序，访问控制和权限管理演变为涵盖对单个程序可用资源的控制。关于智能体系统权限管理的现代讨论建立在研究社区对单用户系统权限管理的努力之上。大量关于移动平台（特别是Android）权限的研究从2010年代初期[31 (https://arxiv.org/html/2607.01510#bib.bib31),32 (https://arxiv.org/html/2607.01510#bib.bib32),33 (https://arxiv.org/html/2607.01510#bib.bib33)]一直持续到最近几年[34 (https://arxiv.org/html/2607.01510#bib.bib34)]。早期的商业移动权限设计依赖于运行时提示（iOS）或安装时的清单（Android）。运行时提示需要平衡提示频率（可能导致用户提示疲劳[9 (https://arxiv.org/html/2607.01510#bib.bib9),35 (https://arxiv.org/html/2607.01510#bib.bib35)]）与过于宽泛的权限（例如应用的生命周期）。清单导致应用过度授权[32 (https://arxiv.org/html/2607.01510#bib.bib32),33 (https://arxiv.org/html/2607.01510#bib.bib33)]，并要求用户在安装时做出脱离上下文的决策；2015年，Android改为采用运行时权限提示[36 (https://arxiv.org/html/2607.01510#bib.bib36)]。这些局限性促使了大量学术工作，试图更好地平衡移动平台权限的可用性和安全性，包括用户驱动的访问控制（其中权限根据用户与特权UI元素的交互来确定）[31 (https://arxiv.org/html/2607.01510#bib.bib31)]以及个性化或预测性权限管理[37 (https://arxiv.org/html/2607.01510#bib.bib37),38 (https://arxiv.org/html/2607.01510#bib.bib38)]。类似的想法