一家公司的“员工”可以在短时间内增加上万倍，还能读取文件、调用服务，甚至花钱。随着智能体从回答问题走向执行任务，AI 安全的讨论也逐渐进入企业系统。
围绕前沿 AI 失控风险的争论升温，多位 AI 企业负责人近期呼吁放缓模型研发。9 月 27 日，Axios 报道称，美国总统特朗普计划当晚与 Anthropic 首席执行官 Dario Amodei 共进晚餐，其提出的“放缓前沿 AI” 主张，成为这场争论的焦点之一。
在 a16z 于 9 月 26 日发布的播客中，美国企业内容管理公司 Box CEO Aaron Levie 与主持人 Erik Torenberg、a16z 合伙人 Martin Casado 和前微软高管 Steven Sinofsky 讨论 AI 安全。话题从前沿模型的“放缓”，延伸到监管、网络安全与企业智能体。
访谈中，Aaron 对实验室加强测试、隔离和安全治理等表示赞同。在他看来，企业是否敢用 AI，取决于产品能否可靠运行、数据能否得到保护。但他也担心，具体的安全要求一旦变成笼统的限速主张，其他开发者可能更难参与竞争。
智能体进入企业，则让安全问题有了更具体的形态。Aaron 指出，系统常在频繁征求用户确认与一次交出过大权限之间摇摆。若智能体持续读取文件、调用内部服务，企业需要更细的访问控制，也需要知道它们实际执行了哪些操作。
到底要不要“放缓”
面对近期“放缓前沿 AI” 的提议，Aaron 认为，安全工作首先关系到技术能否被企业采用。模型能否按预期运行，系统会不会遭入侵，都影响客户的使用意愿。因此，他赞成前沿实验室加强治理，检验模型行为，并为部署建立安全保障。
与此同时，他也认同 Dario 文章中改进测试、提高系统安全性和使用沙盒等建议。沙盒能够为程序划出受限的运行环境，尽量减少程序出错时对其他系统的影响。这些工程实践可能占用开发时间，却有助于建立企业信任，使 AI 更容易进入实际业务。
争议出现在安全实践如何转化为监管要求。Aaron 担心，如果政策笼统地要求放慢发展，其他公司可能更难与前沿实验室竞争，还可能出现与模型安全无关的限制。在他看来，加强安全工作有其必要，但不能仅凭“放缓”一词决定该采取什么措施。
另外，“放缓”本身指什么，也引起对谈者们的争论。Martin 指出，研发速度较慢并不能自动保证安全。Steven 则问，如果实验室没有公开原定进度，外界如何判断它是否已经放缓？Aaron 认为，实验室内部的模型可能远比对外提供的产品先进，因此所谓“放缓”也可能只是推迟发布。
如果连“放缓”的参照都没有说清，实验室关于严重风险的表述便更难得到一致理解。他认为，实验室需要正面回应自己是否相信存在生存风险，否则‘放缓’难以与其风险表述相匹配。因此，实验室需要更明确地说明自己如何判断风险，以及为何仍继续研发。
不过，针对是否应该要求业内人士给出风险的具体概率，Aaron 持保留态度。他提出，有些研究人员恰恰因为担心风险，才选择留在前沿实验室参与安全工作。对外沟通时，实验室可以说明 AI 存在真实风险，也有潜在收益，并交代正在采取哪些措施减轻风险。
但向政府提出“放缓”要求，最终产生的规则未必会符合实验室的设想。Steven 提醒，由于政府需要听取不同群体的意见，监管方案需要经过复杂协商。实验室可能希望获得一套针对前沿模型的安全安排，但其他参与者却可能推动范围更广、力度更强的限制，那么企业就无法独自决定规则会落在何处。
监管讨论还会随用途变化。当 AI 进入医疗建议、交易系统或飞机设备，政府迟早会关注它的运行与责任问题。Aaron 随后提及，类似美国金融业自律监管机构 FINRA 的安排，或将成为 AI 监管的一种选择。
另外，Aaron 还预测，AI 可能成为美国 2028 年选举的重要议题。他认为，支持 AI 的理由往往较难讲清，行业需要用工作、医疗等具体用途说明技术可能带来的收益。Steven 则注意到，“暂停”“失控”等词已经占据讨论的前沿，支持发展的一方常要先解释自己反对什么，才能开始讲述自己的主张。
Martin 则希望把讨论进一步落到可辨认的风险上。他提起早期互联网的病毒、蠕虫和系统瘫痪：这些事件造成过实际损失，安全措施和规则也在应对具体问题的过程中逐步形成。他认为，相比预先规定整个行业应以什么速度发展，新型网络安全风险更适合成为各方共同讨论的起点。
“万倍”员工数量如何改写软件
如果“放缓”难以给出清晰的衡量标准，企业正在使用的系统则提供了更具体的问题：当智能体开始执行任务，现有软件能否管住它们的访问和操作？
Aaron 将智能体比作一种可以迅速扩增的“员工”，它们能够读取文件、调用服务，甚至可能持有用于付款的信用卡，但企业过去为员工设计的安全机制将面对更庞大使用规模的挑战。
他指出，传统企业系统在一定程度上依赖人的使用习惯。多数员工通常会按工作需要访问资料，不会持续尝试系统里的每一个入口。智能体的数量却可能放大上万倍，还可能把正当任务误判为有害任务，或作出相反的判断。即使没有人蓄意攻击，大量错误调用也足以让数据和内部服务承受新的风险。
例如公司内部的 GitHub、Slack 和报销系统，这些服务过去未必需要防范来自企业内部的大量并发请求。但若许多智能体同时运行，正常任务产生的流量也可能看起来像拒绝服务攻击。
以往企业的部分安全设计建立在人的使用习惯之上，而多数员工并不会不断访问系统中的每个角落。但当智能体数量增加后，误判任务或错误调用的机会也会随之增加，原有的授权方式便显得粗糙。
Aaron 举了一个更贴近日常工作的例子：用户希望智能体修改一个文件夹中的资料，同时参考另一个文件夹中的内容。它需要对前者拥有读写权限，对后者拥有只读权限，没必要因此获得整个文件系统的访问权。
但细分权限也给产品设计带来难题。用户需要看得懂智能体能访问哪些文件、能做哪些操作，并能方便地调整设置。否则，即使系统提供了细致的选项，人们也很难在实际工作中正确使用。
针对 Aaron 提出的访问控制问题，Martin 指出，操作系统领域早已有细粒度权限和威胁建模的研究。过去，这类机制没有广泛应用，一个重要原因是配置和维护过于复杂，当时也缺少足够强的需求。现在，智能体既使这类控制变得必要，也可能帮助用户处理复杂设置，操作系统、网络和编程语言因此都值得重新审视。
不过，增加控制不等于增加确认弹窗。Steven 担心，若智能体每次与外部服务交互都要征求用户同意，提示会像浏览器和软件中的警告一样反复出现。用户可能逐渐习惯直接点击确认，甚至不再细看智能体究竟要获取什么权限。
回到 Aaron 所说的另一个极端，即为了让任务顺利完成而一次交出过多权限。智能体若只需整理某个文件夹中的资料，就不必获得其他目录的读写能力。这要求企业能够让权限与任务相匹配，也需要在智能体持续工作时看清它调用了哪些服务。
更多的安全工作还包括事故发生后怎样查明原因。Steven 认为，实验室公布的部分安全事件复盘缺少完整经过，使外部研究者难以判断问题出在哪一步，并主张借鉴计算机安全领域已有的漏洞披露和结构化报告经验。
这些改变不会只落在模型本身。个人电脑和企业软件曾因病毒与入侵风险，逐步关闭自动运行等便利功能，增加系统更新与身份验证要求，这套渐进优化模式也可能在当下复现。
Aaron 也认为，智能体所需的工具权限并非现有操作系统最初的设计重点。随着它们进入实际业务，软件各层都可能需要调整，让授权、执行和追踪能够相互衔接。
访谈接近尾声时，Aaron 转述了对过早监管的一种担忧：如果尚未弄清 AI 系统将如何发展，就提前确定广泛的限制，风险可能依然存在。能否把这些具体问题处理好，将影响企业对 AI 的信任，也将决定智能体能在多大范围内承担实际工作。
参考资料：
1.https://www.youtube.com/watch?v=TLJNJDf2XGo
2.https://darioamodei.com/post/we-must-pace-the-frontier
3.https://www.box.com/mcp-server
运营/排版：何晨龙
注：封面/首图由 AI 辅助生成
热门跟贴