大家好，最近怎么样？酷毙了。很高兴能在这里向大家演讲。我希望大家在AI开发者大会暨AI工程师大会上玩得开心。我是迈克尔·帕森斯，我在Coder公司担任高级解决方案工程师。今天我想和大家谈谈“致命三重奏”。我们这里的人不算多，能举个手让我看看吗？有人听说过这个“致命三重奏”吗？所有人还是只有一半人知道？看来大概是一半一半。太棒了。所以，我要简单解释一下什么是“致命三重奏”，以及我们在Coder应对这一挑战时所学到的经验。首先，我要从演示者视图中移除这些格拉纳达便签，抱歉。
我想先快速回顾一下2025年的代理式AI（Agentic AI）。毫无疑问，2025年是AI代理的元年。每个人都推出了新的代理工具：微软、Salesforce、AWS，还有Claude Code基本上在去年三月发布时改变了游戏规则。大家都在使用这些工具。我有个小故事。当时“氛围编码”（Vibe coding）非常流行，Jason在推特上发帖说代理式编程改变了他的生活。他正在推出大量代码，对产品进行各种新更改。这对他来说就是未来。
然而，我想不到24小时（或者是两天后），他又在推特上发帖说：“代理式AI刚刚毁了我的产品，删除了生产数据库。任何人还能怎么使用代理式AI呢？”问题是，AI代理非常强大，但它们也会带来问题。在座各位熟悉OpenClaw吗？对吧？那么OpenClaw到底是怎么回事呢？它是一个非常酷的工具。你可以把自己的AI放到电脑上，它基本上可以成为你的个人助理，为你做所有非常棒的事情。
但你可能看到大家都在说：“如果你要用OpenClaw，你需要买一台Mac Mini，把它放在与你个人电脑不同的另一台电脑上。”因为它存在许多安全漏洞。你最不想看到的情况是，OpenClaw下载了你所有敏感文件并上传到互联网上，从网上下载病毒到你的笔记本电脑上，然后删除你所有的个人文件，这样你自己没有了，但全世界都有了。
关于代理式AI的安全开发，我们仍然面临许多尚未完全理清的问题。今天我会花一点时间谈谈“致命三重奏”，如果你还没听过的话，以及Coder如何应对代理式安全的原则。我们来看看人们是如何来找我们的，以便他们解决这些问题并在公司内部扩展AI应用。
简单介绍一下Coder。Coder成立于2017年，由三个正在制作《我的世界》（Minecraft）模组的十几岁少年创立。他们厌倦了为了开发模组而不断配置虚拟机，结果不知怎么地搞出了一家价值8000万美元的公司。我们为他们感到骄傲。Coder提供一致、可靠且安全的远程开发环境。这些环境几乎可以在任何你想要的地方搭建起来，并通过Terraform进行配置。我们是开源的、模型无关的（model agnostic）、云无关的，并且支持本地托管。我们发现，如果你需要自托管模型用于开发者环境或代理式环境，这是一个非常非常好的解决方案。
我们受到美国及欧洲一些最大公司的信任。以下是我们要董事会成员名单的一部分：我们相信有六家顶级大银行、许多对冲基金以及多个三字头的政府机构在使用。基本上，如果SaaS模型不适合你，如果你有本地基础设施，如果你的代码不能坐在开发者的笔记本电脑上或处于某种不可控制的边界内，Coder通常是一个很好的解决方案。这些公司都需要它。
那么，“致命三重奏”是什么呢？这个术语由Simon Ellison创造，指的是攻击面中的三个层次、三种威胁层。第一层是如果你的代理在笔记本电脑上，比如Claw Code、OpenClaw或Codex。这台笔记本可以访问私有数据：可以是电脑上的个人文件信息、凭据、公司知识产权或数据库。现在你的笔记本电脑有了访问权限，代理也就获得了这些私有数据的访问权。
既然它拥有了这些数据访问权，它还可以与互联网通信。也就是说，它可以把数据放到互联网上。而且它不仅能把数据放上去，还能从网上下载东西。这是个问题，因为你无法监督代理在收到提示时具体会做什么。这三个因素中单独一个其实不算大问题，但在任何安全的企业环境中，两个同时存在是完全不可接受的。拥有全部三个基本上是不可接受的。这不是“是否”会发生安全事件的问题，而是“何时”会在笔记本电脑上的代理引发某种安全事故。
这里我有几个攻击场景的例子。我相信在座各位都听说过提示注入（Prompt Injection），这本质上是在代理会信任的信息源中存在某种恶意引导。它可能会查看错误消息、支持工单或CI/CD日志。恶意的行为者很容易在这些信息中的任何地方放入恶意内容，而代理会将其视为真理来源，并做出你意想不到的行为。
上下文投毒（Context Poisoning）属于同一范畴，即你在文档、数据或代理获取信息的任何地方放入不良信息。如果其中有任何恶意数据，代理就会照单全收并随意执行它想做的任何操作。还有权限提升（Privilege Escalation）。大家都熟悉最小权限访问原则，对吧？通常我们给予代理几乎完全的访问权，因为它们需要这些权限才能完成工作。
因此，任何一次提示注入或上下文投毒都可能无意中提升代理的权限，使其执行本不该执行的危险操作：比如删除表、上传文件、发起请求或发布不应发布的内容。那么我们该如何应对呢？针对“致命三重奏”有三个支柱，也就是代理式安全的三个支柱。我们称之为代理安全三重奏。
安全方面，首先要控制数据访问权限。如果你要使用智能体（Agent），不要让它运行在你的笔记本电脑上，而应将其置于安全的环境中，最好是虚拟环境。这样可以阻止其访问私有文件，并防止因其在另一台机器上运行而对你的本地设备造成破坏性操作。此外，还需要限制其外部通信能力。
如果将智能体部署在虚拟机等独立环境中，它在架构上将与你的网络隔离开来。它只能访问你授权的域名，并通过虚拟私有云（VPC）或企业内网连接。所有流量需经过防火墙管控，智能体在该环境中的任何操作都受到监管。你可以监控其细微行为，一旦检测到越界访问，系统应立即向管理员和你发出警报，以便你能及时终止该虚拟机或智能体进程。
同时，必须严格锁定内容、联系人及访问权限。这意味着要收紧权限设置，限制其可访问的资源范围，并使用作用域明确的凭证（Credentials）。智能体安全的核心原则与通用的良好安全实践并无二致。人们常误以为人工智能强大到足以避免人类会犯的错误，或者认为它不易受其他漏洞利用的影响。因此，我们必须确保隔离该机器、加固环境，并拦截智能体与互联网之间的任何通信。
接下来简要介绍在大型企业中规模化部署智能体的情况，以及阻碍采用的因素和企业不愿实施的原因。如果决定在公司内部推广代理式人工智能（Agentic AI），你将面临哪些挑战？在领导相关倡议时，又需要应对哪些问题？
首先，在采用之前，你几乎必须获得首席信息安全官（CISO）的安全审批。你需要运维团队（DevOps）的支持，因为是由他们负责向各团队推广部署。此外，你还需要提供实际案例来说明需求：“看，这就是为什么我需要它”、“这是我想要的工作流”。
这里的关键在于：如果你未能获得批准，或者公司目前不允许使用智能体，大多数人仍会使用个人云服务订阅或个人ChatGPT账号，将其安装在笔记本电脑上。因为他们确实能从使用AI中获得切实利益，只是未获公司授权而已。他们无论如何都会完成工作，这被称为“影子AI”。
正如“影子IT”（员工自带虚拟机或技术进入公司以完成工作）一样，“影子AI”是指未经授权使用个人设备上的AI工具。这是一个严重的问题，因为一旦你在笔记本上使用带有个人订阅的AI，企业便无法监控其活动。而代理式人工智能往往能迅速造成巨大破坏。
业界开始出现一个新术语：“忍者AI”（Ninja AI），即规模化后的影子AI。这不仅仅是单个智能体造成破坏，而是组织中大量智能体在无人知晓的情况下执行各种操作，直到为时已晚才发现造成了广泛的损害。
因此，如果要在公司采纳AI，必须确保产生良好的结果并具备适应性。通常企业会从开发人员入手，因为他们从使用AI中获益最多。但你需要重新思考架构以及如何保护组织免受诸如智能体删除数据库、泄露个人信息或上传客户数据等事件的影响，甚至防止其将公司知识产权提取至公共互联网。
一旦决定引入AI，你就必须与安全团队沟通：CISO担心什么？如何防止智能体违反最佳实践？如何在这些智能体周围设立边界？我个人每周与CISO交流一两次，他们表示：“我们理解AI的价值，希望推动开发速度，但我需要护栏（Guardrails）。”
平台团队或业务部门不能只说“我们需要AI，请批准”，因为如果出错，责任将完全归咎于首席安全团队。他们不希望因他人使用代理式AI且缺乏适当护栏而受到指责。平台管理员、DevOps、基础设施和安全工程师主要担忧的是可观测性（Observability）。
他们关心：这些智能体在做什么？如何监控其行为？如何将它们对LLM提供商的所有调用集成到可观测性工具中？同时，如何设置警报机制而不导致“警报疲劳”（Alert Fatigue）？
另一个问题是：即使实现了AI的可观测性并产生大量警报，一旦陷入警报疲劳，人们就会停止关注实际发生的情况。所有AI产生的噪音掩盖了真正需要解决的关键问题。
最后，如果要规模化部署AI，如何以可重复、一致、可靠且安全的方式为公司所有人设置这一体系？此外，开发人员也有其担忧。目前仍存在一场“圣战”，部分技术专家尚未完全信服AI能写出比他们更好的代码。
他们担心会产生更多的技术债务、代码冗余和安全漏洞，并花费大量时间修复AI生成的低质量代码（Slop），而不是亲自完成工作。如果他们将Claude设置为“YOLO模式”并让其批量生成拉取请求（PR），如何确保该智能体不会做出导致他们陷入麻烦的行为？
归根结底，当智能体执行了预期之外的操作时，总有人需要为此承担责任。接下来我将谈谈如何应对大家所关心的这些护栏问题。
首先，云开发环境是至关重要的一环。Coder 提供的正是这种远程执行层和远程环境，而不是依赖本地笔记本电脑。你应该通过 URL、RDP 或 SSH 连接到安全团队和平台团队认可的安全环境中，让代理在隔离的云基础设施上编写和执行代码。这些环境具有严格限制权限的访问控制，除非你明确允许，否则无法与公共互联网通信。这意味着代理只能处理环境内的代码、凭证和数据，从而确保安全性。
云开发环境（CDE）能显著提升 AI 的生产力。如果将项目下载到本地，你需要处理依赖项下载、路径更新以及潜在的版本冲突（如 Python 2 与 3 的兼容性问题），还要创建虚拟环境，过程繁琐且容易出错。相比之下，Coder 提供的云环境已预先配置好，开发者无需在本地 shell 中折腾，只需连接到轻量或重型虚拟机即可开始开发。
同样的逻辑也适用于代理。如果将代理部署在一台全新的机器上，让它下载 GitHub 仓库并运行项目，它需要读取内容、判断依赖并开始下载。你不知道它会从哪里获取文件，如果从被污染的注册表获取，风险极大。因此，最好让环境预先就绪，使代理能够直接开始开发工作，避免潜在的安全隐患。
其次是模型代理（Model Proxy）。在本地机器上的代理或模型与大型语言模型（LLM）提供商之间，需要设置一个中间层来嗅探所有流量并记录每一个细节。在正常场景中，代理直接连接互联网和模型提供商；但在解决方案中，流量需先经过你的代理服务器或网关。这样可以进行数据清洗和注入剥离。例如，如果提示词中意外包含信用卡数据，模型代理会将其剔除，防止敏感信息泄露给 LLM 提供商。
最后是代理防火墙（Agent Firewall）。当代理在进程级别开始执行时，必须确保它不能运行未经安全团队批准的命令。在上述远程环境中，如果代理因某种原因执行了如“删除 GitHub 仓库”或“DROP TABLE”等危险命令，代理防火墙应通过检查进程日志来拦截并拒绝该指令。
综上所述，这三种架构层面的措施可以有效保护组织免受失控代理的威胁。由于时间关系，无法进行现场演示，但欢迎前往 Coder 展位交流（位于舞台对面左侧）。关键要点是：代理功能强大，但需警惕“致命三重奏”；确保能监控代理的所有行为；在架构设计和基础设施需求上应谨慎规划，稳扎稳打。我是 Michael Patterson，高级解决方案工程师，期待与您探讨如何安全地使用代理进行开发。