快速用户切换下本地 AI 智能体操作的安全

共享 Mac 会改变“本地”权限的含义。快速用户切换允许多个用户会话同时保持登录，因此键盘前的人、智能体进程、凭据保险库和审批提示可能属于不同的安全上下文。把它们当成同一个身份，日常交接就可能变成未经复核的生产调用。

实际规则很简单：账户所有权、保险库访问权限和审批权限必须始终绑定到同一个 macOS 用户会话。切换用户不等于可以继续运行别人的智能体任务。它是一个信号，提醒你检查哪些进程仍然存在、可以请求谁的凭据，以及谁能看到或满足下一个提示。

快速用户切换安全关乎并行会话

快速用户切换之所以重要，是因为 macOS 可以让前一个账户保持登录，同时让另一个人使用同一台设备。Apple 在 macOS User Guide 中将快速用户切换描述为一种在账户之间切换、而无需退出另一位用户的方法。这种便利正是该功能的价值所在，也意味着切换并不能证明之前的工作已经停止。

人们常把笔记本电脑想象成一把椅子：一个人起身，另一个人坐下，控制权随之转移。启用了用户切换的共享 Mac 更像一栋楼里的多个房间。当前可见的桌面能告诉你谁现在拥有控制台，却不能告诉你另一个已登录账户中是否还运行着终端、编辑器扩展、本地服务或智能体启动器。

当智能体能够调用 API 或通过 SSH 连接时，这一区别就很重要。智能体可能在午饭前以 Alex 的账户启动。之后 Sam 切换到自己的账户，看到的是一个干净的桌面。Alex 的进程可能仍然存在，任务队列可能仍有工作，某个审批状态也可能仍对这次运行有效。Mac 并没有把这种权限交给 Sam，但粗心的软件可能让两者难以区分。

不要把锁屏、切换用户和终止进程当成同义词。它们解决的是不同的问题。

• 锁屏会阻止他人随意使用当前可见的桌面。
• 切换用户会改变当前控制台账户，同时保留另一个登录会话。
• 退出登录会要求 macOS 结束该用户的图形会话及其进程。
• 撤销智能体运行会移除该运行继续进行外部调用的权限。

最后一项控制最容易被团队忘记。智能体会话应有自己的生命周期和撤销路径。如果它只借用终端窗口的生命周期，或依赖“开发者的电脑”这种模糊概念，那么在多人使用的 Mac 上就很容易出现问题。

快速用户切换本身并不一定不安全。当本地操作系统假定每个活动进程和所有可能接触设备的人都属于同一个人时，它才会变得不安全。这种假设只在单个账户使用的个人 Mac 上勉强成立。即使在那里，只要其他人知道登录密码，或使用无人看管且已解锁的办公桌，这个假设也会失效。

当前控制台用户不能继承另一个账户的权限

当前控制台用户只能控制分配给自己账户的凭据和审批。本地凭据保险库属于某个身份，而不是属于这台实体电脑。如果应用把保险库做成全机共享，任何能接触应用界面的人都可能找到通往其他用户权限的路径。

团队常常会混淆两个不同的问题。“秘密从未进入智能体”讨论的是秘密暴露。“只有正确的人才能授权操作”讨论的是权限。两者都需要满足。即使秘密边界设计得很完美，如果另一个已登录用户可以批准使用该秘密，或者所有者离开办公桌后旧会话仍保持已批准状态，问题依然存在。

在设计和操作规则中明确绑定关系：

1. 将每个人的凭据存放在其 macOS 账户下，使用独立的保险库材料和独立的本地身份验证。
2. 在发生任何外部操作前，要求凭据所属账户解锁保险库。
3. 让审批只适用于一个账户中的一个智能体进程，并在该进程退出或操作员撤销时失效。
4. 不允许切换到另一个账户来满足源自第一个账户的提示。
5. 为每次授权和调用记录账户上下文及发起进程。

一个棘手的边界情况是拥有 Mac 管理员权限的支持人员。管理员权限可以改变许多本地条件，但不应变成随意使用他人 API 凭据的通行证。要确认系统是否会要求凭据所有者重新进行身份验证，以及审计记录是否会清楚显示账户变化。如果答案不明确，设计本身也就不明确。

Touch ID 让这件事更加严格，而不是更简单。指纹审批应确认当前账户中有权执行该操作的人，以及提示中显示的具体操作。它不应变成一个笼统的实体存在信号，让任何已登记指纹的人都能使用另一个账户的权限。硬件支持的本地身份验证只有在应用保留了门另一侧的身份时，才能提供强有力的控制。

不要用“只有对方不在时我们才切换用户”这样的非正式规则来解决问题。共享设备会遇到中断、维护、借用充电器和仓促交接。控制措施必须经得起正常的人类行为，因为人们通常会在这种时候忘记没有写下来的规则。

隐藏进程可能比办公桌前的人活得更久

切换用户可能会让本地智能体继续运行，你必须按照团队实际启动智能体的方式进行测试。有些进程会在父终端关闭后停止。另一些进程通过编辑器、任务运行器、登录项或后台启动机制运行，因此会继续存在。macOS 账户边界会限制它们能访问的内容，但不会保证另一个用户到达登录窗口时所有进程都消失。

在允许共享设备执行自主工作前，先做一个小测试。使用一个无害的智能体任务，让它每分钟写入一条容易识别的本地记录，并且不持有任何凭据。通过开发者实际工作中使用的同一个终端、编辑器或启动器启动它。不退出登录就切换用户，等待一段时间后切换回来，检查任务是否继续。然后在锁屏和退出登录后分别重复测试。

用操作层面的语言记录结果。“智能体会停止”还不够。记录启动器、账户、使它停止的事件以及耗时。如果切换用户后进程仍然继续运行，对于本地代码检查任务来说或许可以接受。但如果它能发送改变托管环境的请求，就需要严格得多的审查。

一个常见的故障起初看起来并不起眼。开发者启动一次自主编程运行，它可以创建问题评论并更新测试环境。开发者批准该进程在整个下午运行，随后切换账户，让另一个人使用这台 Mac。编程任务在遇到临时错误后进入重试循环，并在稍后恢复。第二个人没有启动它，甚至可能不知道它的存在。然而这次运行仍保留有效审批，因为软件把审批绑定到了时间、设备或宽泛的用户会话，而不是绑定到发起进程。

解决方法不只是缩短审批超时时间。过短的超时会打断正常工作，并让人养成直接点击提示的习惯。应把审批绑定到进程实例。进程退出时，其授权也随之结束。用户有意把工作交给其他人时，应撤销旧运行并启动新运行。新进程会创建新的审批事件，并拥有明确的负责人。

你还需要一种清晰的方式来回答“我的账户下还有什么在运行？”答案不能依靠记忆。为操作员提供会话日志，显示运行、运行是否仍获授权以及直接撤销操作。在个人设备上，这是便利功能。在共享 Mac 上，它属于安全边界的一部分。

审批提示需要进程身份，而不是友好的名称

审批提示必须显示足够的信息，帮助用户区分真实调用者和冒充者。“编程助手”这样的标签没有用，因为两个扩展、两个 Shell 或一段复制来的脚本都可以使用同一个标签。操作员需要看到发起进程，以及在 macOS 提供相关信息时看到其代码签名身份。

代码签名身份回答了一个范围有限但重要的问题：哪个开发者身份签署了这个进程？它不能证明进程一定会做出正确决定，但可以帮助操作员识别未签名工具、不同构建版本或意外的辅助进程。这比在忙碌的下午因为请求看起来熟悉就批准匿名请求要好得多。

提示还应使用人能够判断的方式说明凭据或操作类别。“使用凭据 X”会让人去翻脑中的表格。“使用 staging publisher 凭据向部署 API 发送 HTTP 请求”则能让人做出决定。不要把完整请求体塞进每个提示。过大的提示会造成审批疲劳，也会把不应出现在桌面通知中的数据暴露出来。应让用户能够快速看到操作、目标、方法和凭据身份。

按会话审批和按调用审批解决的是不同问题。按会话审批表示：“我认出这个智能体进程，并允许它在限定范围内运行。”按调用审批表示：“我正在检查这次凭据的具体使用。”不要因为前者打扰更少，就用它替代后者。

对于难以逆转的操作，应使用逐次调用审批，例如会修改生产数据、删除资源、对外发布或访问广泛管理界面的凭据。每次调用都审批会增加摩擦，但这种摩擦正应该出现在人需要停下来判断的地方。

对于进程身份明确且凭据影响范围受限的工作，可以使用按会话审批。会话必须在进程结束时结束。“允许这台 Mac 上的智能体”这种宽泛授权，只是披着友好名称的政策漏洞。

在可信的本地开发机器上关闭审批，是一个很流行但不适合共享 Mac 的建议。它受欢迎，是因为提示会打断工作流程，也因为开发者把本地进程看成私有进程。快速用户切换打破了这一前提。本地设备可能包含多个活动用户上下文，熟悉的进程也可能在所有者离开键盘很久后继续运行。

共享 Mac 需要以结束权限为目标的交接流程

真正的交接会先结束原用户的权限，再开始下一位用户的工作。传递终端标签页、任务说明或聊天消息并不能转移责任。接手的人需要创建新的进程，并为任何凭据使用获得自己的授权。

有人需要接手本地智能体任务时，使用以下流程：

1. 如果当前智能体仍在做决定，先停止它。让它写入普通工作文件，但交接期间不要让它继续调用外部系统。
2. 在会话记录中撤销旧智能体会话。原用户离开前，确认撤销确实改变了会话状态。
3. 如果设备在较长时间内由下一位用户使用，锁定原用户的保险库，或让该账户退出登录。
4. 让接手者切换到自己的 macOS 账户，并在那里启动新的智能体进程。
5. 要求新的授权，确认提示中标明新进程，然后在允许外部操作前检查任务状态。

第一次模糊交接导致请求发出之前，这套流程听起来可能过于严格。相比事后追查到底是谁授权了某项变更，重启智能体的代价很小。如果工作无法承受重启，就需要经过认真设计的多用户方案，而不是通过共享桌面进行意外交接。

不要为了加快交接而共享账户。共享登录会摧毁你之后需要的证据。你无法知道是谁解锁了保险库、哪个终端启动了进程，或是谁判断后批准了调用。独立的 macOS 账户不能解决所有问题，但能保留一条有用的边界和一份可用记录。

团队还需要为负责人不在场的情况制定规则。如果智能体进程运行在一位暂时无法联系的用户账户下，任何人都不应通过操作其账户来让它继续运行。停止它，撤销它，然后在当前负责人的账户下重新启动。工作可以等待，但无人看管且能修改外部系统的权限不应继续存在。

锁定保险库应在提示出现前停止操作

保险库门禁在锁定时必须拒绝所有操作，即使智能体进程此前已经获得会话审批。这体现了运行授权和当前使用凭据的许可之间的区别。前者确认人认可哪个进程，后者确认凭据存储现在是否可用。

Sallyport 有意采用这一顺序：保险库门禁是绝对的。在 macOS 上，它在锁定状态下使用 Secure Enclave 和 Touch ID，同时拒绝被锁定时的操作。这种顺序能防止用户锁定会话后，旧的智能体授权取代保险库访问权限。

在思考时要把这些控制分开。保险库门禁保护凭据材料的访问。会话授权确认某一次特定的智能体运行。逐次调用审批为选定凭据增加直接复核。如果一个控制承担了另一个控制的职责，操作员就无法判断拒绝的原因。

例如，不要把逐次调用提示作为广泛凭据的唯一保护。用户切换回拥挤的桌面后，可能会误批错误请求。锁定的保险库应先拒绝操作，直到凭据所有者在本地完成身份验证。随后，逐次调用提示再询问更具体的问题：这次具体使用是否值得允许？

同样，不要因为长时间编程任务稍后可能需要保险库，就让它永久保持解锁。这样会把短暂的注意力空档变成旧进程可以行动的一段时间。有人监督工作时解锁，所有者离开或把 Mac 交给他人时锁定。如果任务确实需要无人看管的权限，就把它转移到专门为服务身份、受限凭据和明确运营所有权设计的环境中。共享个人会话不是用来假装服务器的地方。

“人在回路中”这个说法经常掩盖身份问题。是哪一个人？使用哪个账户？批准了哪个进程？无法回答这些问题的提示，并不能提供有意义的控制，它只留下了有人点击按钮的记录。

审计记录能还原时间线，但不能决定权限

防篡改审计轨迹可以让你在发生争议的操作后重建智能体运行，但它无法在操作发生时阻止错误授权。用日志确认顺序和所有权，然后修复允许该操作发生的控制。不要把审计历史当成锁定保险库或清晰审批边界的替代品。

记录需要提供两种视图，因为操作员会提出两类不同问题。会话日志回答：“哪个智能体运行获得了授权，我能撤销它吗？”活动日志回答：“发生了哪个调用，针对什么通道，时间是什么？”两种记录应来自同一个只追加数据源，而不是来自两个可能逐渐不一致的独立数据库。

Sallyport 从一个写入盲、加密并采用哈希链的审计日志中生成这两种日志，因此活动历史和运行历史共享同一个记录源。你可以通过以下命令进行离线检查：

sp audit verify

归档设备、调查有争议的交接或收到导出的审计存储时，运行这项检查。验证器会在密文上检查哈希链，不需要解密凭据。这一特性对共享 Mac 很重要：调查人员可以检查记录是否仍组成有效历史，而不必拿到相关历史记录中的 API 令牌或 SSH 材料。

验证能告诉你哈希链在内部是否保持一致。它不能证明每个事件都是明智的，不能证明某人理解了每个提示，也不能证明设备本身没有遭到入侵。必须准确描述结论。经过验证的链会让过去记录被悄悄修改这件事更难隐藏，但不会把不安全的共享账户变成安全账户。

调查时，对比账户上下文、进程身份、会话授权时间、保险库解锁事件和每次调用的顺序。不要只问“是不是智能体做的？”还要问，保险库、智能体进程和审批是否都属于同一个账户。如果它们不一致，就说明有一条边界需要处理。

HTTP 和 SSH 调用带来的共享会话风险不同

HTTP 和 SSH 操作都会消耗权限，但留下的操作痕迹不同，失败方式也不同。HTTP 凭据通常指向具有广泛 API 范围的远程服务。SSH 凭据可能提供远程主机上的 Shell，而一次接受的连接就能执行多个命令。不要因为它们都来自同一个本地智能体，就给它们相同的审批方式。

对于 HTTP，应检查目标、方法和凭据范围。向范围狭窄的开发 API 发起读取请求，和向环境管理端点发起写入请求，应采用不同规则。智能体应通过本地网关请求操作，由网关自行注入凭据，让智能体收到结果而不是持有令牌。这能限制秘密暴露，但不会降低已批准的破坏性请求所造成的影响。

对于 SSH，应关注主机身份、账户身份和命令意图。使用受限账户连接开发主机，与连接共享生产账户有明显区别。如果凭据授予交互式 Shell，即使第一条命令看起来无害，也应将其视为高影响权限。下一条命令可能完全不同。

快速用户切换给两个通道都增加了一个本地条件。一个账户中的活动智能体进程不能仅仅因为另一个用户让 Mac 成为当前设备，就继续发出 HTTP 请求或打开 SSH 会话。网关必须将请求与发起进程关联起来，并要求保险库所有者满足门禁。第二个用户的屏幕不应成为第一个用户运行的审批界面。

在责任划分重要时，为不同人员使用不同凭据。共享部署令牌会让人难以区分进程问题和人员交接问题。个人凭据和按账户划分的保险库条目能让审计历史在需要查找真正负责人时发挥作用。

有些工作负载不适合放在共享工作站上

共享 Mac 适合在有人监督、凭据范围狭窄且审批明确的情况下进行本地开发工作。它不适合运行长期自主智能体，尤其是能够修改生产系统、访问广泛管理 API 或在无人值守时维持远程 Shell 的智能体。

分界线不在于智能体是否聪明，而在于负责人离开控制台后，工作是否还能继续行动。如果可以，就应使用为这类任务构建的环境。为工作负载提供专用服务身份、明确负责人、受限凭据，以及运营人员无需借用某人的桌面会话就能检查的记录。

不要把服务器设计和本地应用设计混为一谈。服务器有不同的威胁模型、生命周期控制和无人值守执行预期。Mac 菜单栏应用可以让开发者对本地操作保持紧密的人为控制，但不应因为有人希望任务运行一整夜，就假装自己是无头自动化系统。

对于已经拥有的共享 Mac，先制定一条具体政策：任何智能体都不能在无人负责的交接后继续拥有外部权限。测试切换用户后哪些内容仍会存活，凭据所有者离开时强制锁定保险库，并撤销旧运行，不要指望下一位用户注意到它们。快速用户切换到这里才不再只是桌面便利功能，而是开始接受它应有的安全处理。