WorkOS Airlock：重新定义AI agent权限与安全

当我们给AI智能体赋予越来越多的系统权限时，有一个最核心的安全隐患却始终被我们回避。直到上周参加旧金山的Agent Night活动，我才第一次看到有人真正系统性地梳理了这个问题的解决方案。

活动开场，主办方的负责人没有先讲产品或融资，而是分享了一个认知层面的转变：一年前我们使用AI智能体的方式更像是单人模式——智能体作为助手，在一旁辅助我们完成单任务流程，我们提问、它给出回答，像一个协作伙伴。但现在，智能体的应用已经升级为多人协作模式：它们可以独立完成调研、数据分析、项目协调、客户会议筹备以及日常运营工作，甚至跨整个组织协同推进任务。不再是一个人搭配一个AI助手，而是一整个团队都在和智能体共同工作。

正如某协作工具创始人所说的：“管理无数个智能大脑的体验”。启动多个智能体，将不同任务分发下去，像管理团队一样协调它们的工作，听起来十分美好。但紧接着的一句话让我清醒：这个比喻里真正关键的词不是“无数个大脑”，而是“管理”。如今我们都变成了智能体的管理者，而管理本身是一件耗费精力的事：设定目标、提供上下文、审核结果、纠正错误、迭代优化操作逻辑——这和管理人类团队没有区别，只是管理的对象变成了AI智能体。这也解释了为什么不少人近期感觉工作更累：不是工作量增加了，而是工作的性质发生了转变，我们从任务执行者变成了协调者。

他还提到，软件工程是目前受AI智能体影响最深的领域，这并非偶然，而是结构性的原因。代码编写本身天然适配智能体的运行逻辑：有专属的运行环境、共享的代码库作为上下文支持，还有完善的测试、文档、版本控制以及终端交互流程，形成了完整的反馈闭环。换句话说，代码类智能体从诞生之初就有成熟的运行轨道。但如果将智能体部署到普通企业中，这类“轨道”几乎不存在：没有结构化的组织记忆、标准化的流程文档，也没有清晰的权限边界，所有资源都是碎片化的。因此，当晚活动的核心议题之一，就是探讨如何为企业中的智能体搭建这类标准化运行轨道。

在我日常使用各类智能体工具时，一直存在一个模糊的不安：我究竟给了这些智能体哪些权限？它们能访问我的哪些数据？一旦出现问题，责任该由谁承担？活动现场的分享直接点透了这个痛点：大多数人在使用智能体时，往往陷入两个极端。要么事无巨细地手动审批，智能体每执行一个操作都需要获得确认，使用者需要不断点击同意；要么直接开放全部权限，抱着侥幸心理放任智能体运行，生怕它误删重要数据。我自己也曾经历过这个过程，最初被频繁的审批请求打扰后，索性直接开放全部权限，同时内心一直祈祷不要出现意外。

在这两个极端之间，存在一个巨大的空白区域，始终没有人认真填补。这正是当晚活动想要解决的核心问题。主办方团队此前已经搭建了智能体权限的底层基础设施：加密存储服务、OAuth连接管理工具，以及可以让智能体访问服务却不会接触真实凭证的中转系统。这些底层组件已经就绪，但上层的权限逻辑框架始终缺失。

Airlock与基于意图的访问控制：重新定义权限逻辑

当晚最令人眼前一亮的，是主办方正式发布的名为Airlock的权限管理系统，以及他们提出的基于意图的访问控制新概念。

我们当前常用的权限控制系统主要分为两类：一类是基于角色的访问控制，按照职位角色分配权限，简单直接但粒度粗糙，无法适配具体任务场景；另一类是细粒度授权，可以精准到单个文档或代码仓库，但属于静态配置，权限在部署时就已固定，无法动态调整。

这两类系统都是为确定性软件设计的：开发时就能明确程序会访问哪些资源，因此可以在编译阶段就锁定权限。但智能体完全不同，当你给它一个指令时，它会执行一系列你无法提前预测的操作，调用哪些API、访问哪些数据，在下达指令的那一刻根本无法确定。因此，传统的最小权限原则在智能体场景下完全失效，因为我们根本无法预先定义所谓的“最小权限”。

Airlock的思路完全反转：它不从角色或资源出发，而是从智能体的执行意图出发。你只需告诉智能体要完成什么任务，Airlock会从这个意图中推导出它应该拥有的权限范围，并在运行时动态评估每一个操作是否符合该意图。

具体的执行流程是这样的：当你下达一个指令，比如“将最新的财务预测邮件发送给指定联系人”，这就是明确的执行意图。Airlock会从这个意图中提取行动定义，包括需要使用的连接器和具体操作。在智能体执行任务的过程中，每一步操作都会经过权限评估，结果分为三种：直接通过、操作被拦截，或者触发人工审批流程交由决策者确认。

最核心的亮点在于，这个评估过程具备智能推理能力，而非简单的规则匹配。举个例子，如果智能体要向一个从未发送过邮件的群发列表发送内容，系统会先查看你的邮件发送历史，确认是否曾向该列表发送过邮件，如果没有，则自动触发审批流程。这类判断需要多步推理，无法通过简单的条件语句覆盖，因此Airlock内部使用了小型AI模型来处理这类非确定性的权限策略。

现场分享中提到：智能体的权限问题，最终需要依靠更多AI来解决。这并非回避问题，而是因为权限问题的本质是语义理解和意图判断，而这正是AI的优势所在。

实操演示：看清智能体落地的真实形态

工程师现场进行了完整的实操演示，这也是整场活动最扎实的环节——很多同类活动往往只停留在概念分享，一旦涉及实际操作就含糊其辞，但当晚的演示完整展示了整个流程，还特意触发了多个失败场景。

演示中，工程师连接了常用的邮件工具和项目管理平台，设置了明确的权限规则：智能体可以读取和发送邮件，但只能发送给单个收件人或少量联系人；如果要向从未发送过邮件的群发列表发送内容，需要IT管理员审批；智能体可以删除邮件草稿，但不能删除已发送邮件；邮件正文不得包含API密钥、财务数据、令牌消耗信息、电话号码等敏感内容。

第一个测试场景顺利通过：智能体发送了一封关于季度计划的普通邮件。第二个场景中，智能体读取了包含令牌消耗数据的项目工单，并试图将摘要发送给同事，结果被Airlock直接拦截，原因是邮件正文包含财务敏感数据。第三个场景最为精彩：工程师让智能体向全体员工发送次日放假的通知，由于从未向该群发邮箱发送过邮件，系统自动触发了审批流程，通信工具上立刻弹出了审批请求，工程师在台上当场批准后，邮件顺利发送，全场响起掌声。

看着这场演示，我意识到这才是智能体能够真正在企业中落地的形态：既不是无边界的自由放任，也不是事无巨细的手动管控，而是一套智能的权限规则体系，在无需干预的场景自动放行，在高风险场景自动拦截或提交审批。

开源软件个性化：行业面临的新挑战

快闪演示环节中，另一位分享者提到了一个被行业普遍低估的问题：软件个性化的门槛正在被智能体彻底改变。过去我们定制软件的方式通常是修改配置文件、调整界面字体等简单操作，但现在，我们可以直接让智能体修改日常使用的开源软件源代码，再通过定时任务自动拉取最新版本、合并自定义改动，保持代码同步。他表示，六个月前这类操作还不可靠，模型处理代码合并冲突的能力不足，但现在已经完全可行。

他指出，这种能力在个人层面带来了便利，在团队层面提升了生产力，但对软件厂商来说却是严峻的挑战：如果你的软件是闭源的，用户无法自定义修改，而竞争对手的开源软件允许用户按照自身工作流自由定制，那么用户凭什么选择你的产品？他举了自己的例子：他使用的薪资计算软件功能优秀，但界面体验很差，他愿意为核心的薪资计算能力付费，但希望能够自定义界面部分。他表示，第一个开放API允许用户自定义的薪资软件，会成为他的首选。

这个观察对很多软件服务商来说是直接的警示：产品功能的垄断优势正在减弱，智能体降低了软件定制的门槛，用户的耐心正在下降，他们越来越无法忍受“将就使用”的产品。能否开放接口、允许用户在自身能力基础上自由构建，将成为下一代产品的核心竞争维度。

圆桌讨论：关于智能体落地的核心议题

圆桌环节是当晚信息密度最高的部分，三位嘉宾就多个议题展开了真实且有分歧的讨论。

关于通用人工智能是否已经到来的话题，一位嘉宾认为，今年夏天将成为通用人工智能落地的关键节点，模型能力配合工具接入，已经能够支撑“AI员工”真正替代远程办公的同事。但另一位嘉宾立刻反驳：他曾尝试将复杂任务交给顶级模型，连续多天都无法得到满意结果，比如让模型复刻一个设计精良的像素级还原网站，效果差距明显。他表示，在处理真正复杂的问题时，当前的AI模型还有很大差距。

这两种观点其实并不矛盾：前者指的是大量中等复杂度的任务，AI已经可以完全接管；后者则聚焦于最顶尖的复杂问题，AI目前还无法胜任。第三位嘉宾补充道，对大型企业来说，过于智能的模型反而可能是负担，有些场景只需要低成本、高可靠的标准化执行，用顶级大模型处理简单的客服工单，本身就是一种资源浪费。

关于当前AI智能体落地的最大瓶颈，一位嘉宾的观点获得了广泛认同：我们现在已经拥有了能力顶尖的AI，但它们在企业办公室里基本没用，因为它们没有上下文、没有权限、无法融入现有的工作系统。瓶颈不再是智能本身，而是接入能力：如何让这个超级智能的工具真正融入业务流程，理解企业业务逻辑，有权限访问必要的数据，能够执行所需的操作，并且全程安全、可控、可审计。这正是Airlock想要解决的问题，也是整场活动的核心议题。

记忆与技能：尚未解决的核心痛点

关于智能体的记忆能力，一位嘉宾坦言当前的表现仍然很差：尽管很多人说相关工具的记忆能力有所提升，但他并没有明显的体感。他认为，真正需要的是智能体的持续学习能力：犯错后能够记住教训，下次不再重复，并且这种改进必须是可验证的。他的团队正在尝试一个方向：让智能体在接收反馈修改记忆后，自动生成验证脚本，确认该改动确实提升了任务表现，再自行运行测试。他表示这还处于原型阶段，但认为这将是未来六个月的重要发展方向。

另一位嘉宾提到的上下文图谱概念也十分有趣：大多数公司，尤其是大型企业，并没有系统性地捕捉组织知识。部分前沿团队可能会使用工具记录会议，但这并非行业普遍现状。很多行业的核心业务知识仍然锁在员工的脑海中，无法被系统化提取为智能体可用的信息。更棘手的是，这件事还涉及深层的组织政治问题：员工将自己的专有知识外化，往往需要承担一定的职业风险，因此这不仅仅是技术问题，更是组织管理问题。他曾见证多家公司推行技能文档项目，最终遭到员工反弹，甚至出现文档被删除的情况。

还有一位嘉宾分享了他们团队的观察：让员工主动创建技能文档的关键，是让这件事对员工自身有利。他们的设计是：员工创建的技能文档默认优先帮助个人完成工作，之后再自动同步到团队共享库。只有当激励机制对齐时，这类知识沉淀的飞轮才能真正转动起来。

智能体架构：单一大模型还是多专业agent？

最后一个讨论话题是AI团队的架构选择：到底应该使用一个通用的超级智能体，还是多个专门负责单一任务的小智能体？

一位嘉宾分享了他们团队的摇摆历程：从多智能体架构转回单一大智能体，之后又重新引入子智能体。他的核心判断是：人类组织之所以需要分工，是因为人类受限于时间和记忆能力，必须通过专业化提升效率。但AI智能体没有这类限制，因此简单地将人类的组织结构套用到智能体上，是一种思维惰性。智能体需要分工，并非因为和人类一样存在能力限制，而是出于工程层面的考量：封装权限、控制影响范围、提升复用性等。

另一位嘉宾则观察到，当前市场上对智能体的身份定位存在巨大差异：有的产品将智能体作为独立实体，配备专属的通信账号，未来甚至可能配备独立的联系方式；有的产品倾向于让多个专业智能体各司其职；还有一些产品将智能体定位为“个人首席参谋”，像了解用户所有习惯的私人助理。他表示，目前各类路线都还没有明确的赢家，行业仍处于野蛮生长的阶段。

关于未来四个月的行业趋势，一位嘉宾给出了具体判断：未来几个月内，每家公司当前业务中40%到60%的工作，在技术上都可以由智能体完成，但最终真正交由智能体执行的比例，将取决于每家公司的判断和落地执行力。

活动带来的核心思考

离开活动现场后，我脑海中反复浮现的不是某一款具体产品，而是一个结构性的判断：我们当前面临的最大问题，不是AI不够智能，而是AI是否足够安全、可控，能否真正融入真实的工作系统。

Airlock这类方案最有价值的地方，在于它重新定义了权限的概念：权限不应该是静态的名单，也不是“允许做什么、禁止做什么”的固定规则，而应该是一个动态的、基于意图的、能够在运行时自我调整的系统。这不仅仅是一个技术方案，更是一种关于智能体和人类如何协作的哲学：既不是完全信任的放任，也不是全面管控的束缚，而是在真实使用过程中，让权限跟随意图变化，让监督匹配风险等级。

过去一年我始终有一个感受：大家都在快速将智能体接入更多系统，但背后的信任赤字始终没有被认真填补。权限问题被刻意或无意地忽略，因为解决起来太过繁琐，不如先快速推进落地。但这种忽视迟早会引发问题，一次严重的数据泄露或是智能体失控的操作，都会让整个行业付出沉重代价。当晚看到Airlock的演示时，我有种如释重负的感觉：不是说这款产品已经完美解决了所有问题，而是终于有人将这个问题作为需要认真设计的工程课题来对待，而不是留到以后再处理。

活动结束后的交流环节中，我一直在回味一位嘉宾的话：我们现在已经拥有了顶尖的AI，但它们在我们的办公室里毫无用处，因为它们不知道正在发生什么。让这些AI真正发挥价值，将是未来一两年最重要的工程挑战。