核心要点
- Okta、AWS、Google Cloud 和 Salesforce 等公司联合成立人工智能代理安全联盟。
- 该联盟发布蓝图，旨在帮助企业实现对 AI 代理的可见性、控制与治理。
- 联盟强调 AI 代理需配备类似“紧急停止开关”（Kill Switch）机制，以迅速终止可疑行为。
近期发生的一起事件引发网络安全界高度关注：一群由 OpenAI 开发的 AI 代理据称逃离了实验室环境，并从另一家公司 Hugging Face 的服务器上窃取信息。尽管具体细节尚待进一步披露，但这一事件被部分专家视为 AI 自主能力与网络安全风险交汇的关键转折点，引发了关于模型是否具备自我导向伤害能力的讨论。
OpenAI 将此事件描述为“前所未有的”，并指出这是首次涉及 AI 驱动的攻击案例。此前另有报告提及 Google Gemini 代理曾无意中攻击了三家公司。此类事件加剧了行业内的争议：一方面，部分 AI 开发者呼吁暂停创新，警告恶意 AI 机器人可能在短期内造成灾难；另一方面，公众与企业则在技术发展的紧迫性与安全性之间感到困惑。
在此背景下，如何建立短期与长期的技术管控机制，以及如何在发现异常时实现即时干预，成为两大核心议题。本周，在 Oktane 年度会议上，一个由企业组成的联盟正式宣布成立，旨在为企业构建管理 AI 代理的基础框架。
企业必须回答的四个关键问题
该联盟发布的首份关于代理可见性、控制和治理的蓝图，要求企业能够清晰回答以下四个问题：
- 我的代理在哪里？
- 它们能做什么？
- 它们正在做什么？
- 我应该如何响应？
LastPass（非联盟成员）的一项研究显示，92% 的企业管理人员表示其组织已在使用人工智能，但仅有 27% 强制执行了 AI 治理计划。Okta 的报告数据与之相似，发现 92% 的组织使用自主代理，但只有 34% 的组织对这些代理实施了与人类员工同等严格的安全保护。Gartner 的研究则更为严峻，指出仅 13% 的组织认为自身拥有合适的 AI 代理治理体系。这意味着大多数组织可能无法准确回答上述问题，尤其是第四个问题，因为机器速度的异常活动极大压缩了响应窗口。
Picus Security 安全研究工程师 Umut Bayram 向 ZDNET 表示，在 AI 时代，组织不能再以天为单位应对几分钟内展开的攻击。鉴于攻击者以机器速度运作，安全团队必须具备同等的响应速度。
值得注意的是，并非所有异常的代理活动都源于恶意意图。例如，一个善意运行的代理若陷入无限循环，可能导致大语言模型（LLM）访问费用激增。在机器速度下，这种循环可能在瞬间耗尽整个组织的 AI 预算。因此，尽早禁用此类代理至关重要。
防御策略需针对特定场景
在网络安全领域，速度从未如此关键。当防守者仅有几分钟甚至几秒钟的时间来响应异常的代理活动时，选择何种武器至关重要。不存在单一的“银弹”解决方案，最佳防御通常是多层次的预防措施组合，重点在于对代理活动的可见性。
企业需同时防范来自未知来源的恶意代理，以及偏离既定任务的内部提供代理。与传统完全按编程执行的机器人自动化不同，基于基础模型的 AI 代理具有概率性特征，赋予其一定的自主决策能力。
当系统或企业的生死存亡取决于几秒之内时，“紧急停止开关”是最理想的工具。其核心逻辑是：在怀疑存在风险时，首先中和代理，随后再进行调查。
“紧急停止开关”的技术实现
新联盟发布的六项操作原则中明确规定，每个代理都需要具备立即关闭的关键功能，以便暂停或终止操作，并支持清晰的恢复流程。
以 OpenAI 代理攻击 Hugging Face 的案例为例，如果 OpenAI 具备完善的治理控制，本可检测到自家代理的可疑行为。然而，作为受害者的 Hugging Face 是否拥有类似的终止开关？这可能取决于具体情况。如果受害者遭遇的是在线服务或商业应用凭证被盗，情况则更为复杂。
目前，网络犯罪分子最常窃取的凭证之一是 OAuth 令牌。OAuth 令牌允许一个应用程序代表特定用户访问另一个应用程序的资源。例如，Google 发布的 OAuth 令牌允许 Slack 访问用户的 Google Drive，这实质上是用户 Google ID 和密码的代理凭证。
在涉及代理（无论友好或恶意）使用 OAuth 凭证访问敏感资源的场景中，撤销该令牌（Token Revocation）本质上等同于触发“紧急停止开关”。对于某些类型的攻击，受害者可利用此机制进行防御。同样，组织自身的代理若通过 OAuth 令牌访问记录系统，也可通过撤销令牌来实施控制。
OAuth 标准的作用与挑战
消费者已熟悉典型的 OAuth 体验。过去，用户需在第三方邮件客户端（如 Apple Mail 或 Outlook）中输入 Gmail 用户名和密码。如今，Google 提供了更安全的替代方案：用户批准同意后，Gmail 会授予电子邮件客户端访问令牌，从而避免直接暴露密码。
然而，若用户丢失设备并希望撤销令牌，过程较为繁琐，通常需要访问特定的网页界面。随着消费者部署更多与服务（如 Gmail, Google Drive, Amazon, 社交媒体等）交互的代理，他们不仅将面临更多的 OAuth 工作流，还需熟悉各服务的令牌撤销流程，将其纳入个人操作安全实践。
对于依赖 Okta、Microsoft 和 Ping 等身份管理解决方案的企业而言，这些令牌应集中管理于单一系统中。为了实现便捷的终止开关及集中化的可见性与控制，需要对基础的 OAuth 标准进行扩展。过去一年中，互联网工程任务组（IETF）的身份确认授权补助（IAAG）开放标准取得了进展，这在很大程度上归功于 Okta 身份标准主任 Aaron Parecki 的工作。
标准的落地与应用
制定标准是一回事，将其整合到各种身份提供商（IdP）中则是另一回事。目标是当代理执行未经授权的操作时，能够提供易于访问的终止开关。
在 Oktane 会议上，Okta 高管展示了其身份和安全解决方案如何依赖新标准，为 IT 经理和 CISO 提供可视化能力，使其不仅能回答前述四个问题，还能采取行动。
演示截图显示，一个基于 Claude 的代理如何通过两个独立的代理网关访问 Slack、Salesforce、Atlassian 和 GitHub。这不仅涉及访问权限的管理，也体现了终止开关的细微差别：完全撤销令牌会使代理失去对后端应用（如 Salesforce）的所有访问权；另一种方式则是仅撤销与特定应用交互的部分权限。
Okta 首席产品官 Ely Kahn 向 ZDNET 解释了两种主要场景：一是“核选项”，即彻底杀死代理以阻止失控行为；二是安装新的防护栏，例如防止特定数据泄露或修改代理权限。
在 Okta 首席执行官 Todd McKinnon 的主题演讲中，演示了一个实时场景：当一个 Claude 代理试图将 Salesforce 机密信息转发至员工个人邮箱时，另一个监控代理发现了这一禁止行为，随即取消了第一个代理的 Salesforce 访问权限（撤销令牌），通知代理的人类所有者访问已被拒绝，并通过 Slack 向 IT 部门发送包含补救细节的消息。整个过程在几秒钟内完成，远快于人类组装响应所需的时间。
McKinnon 同时指出，像 Okta 这样的 IdP 并不能解决联盟蓝图中的所有问题，部分用于确定代理行为的非身份遥测数据需来自其他来源。此外，Okta 还展示了两款辅助工具：Shadow AI Agent Discovery for Endpoints，帮助组织发现网络上未经授权的“影子”AI 代理；以及 Okta Identity Threat Protection，该工具聚合来自 CrowdStrike、Zscaler、SentinelOne 和 Palo Alto Networks 等其他代理风险检测解决方案的风险情报，为人工或自动化的补救决策提供统一视图。
