企业身份是为人类构建的——而非 AI 代理
Source: VentureBeat
由 1Password 提供
为企业环境添加代理能力从根本上重塑了威胁模型，因为它在身份系统中引入了一类新的行为者。
问题所在： AI 代理正在敏感的企业系统中执行操作——登录、获取数据、调用 LLM 工具以及执行工作流——往往缺乏传统身份与访问系统所设计的可视性或控制。
AI 工具和自主代理在企业中的扩散速度快于安全团队对其进行检测或治理的速度。与此同时，大多数身份系统仍然假设：
- 静态用户
- 长期存在的服务账户
- 粗粒度的角色分配
这些系统 并未 设计用于表示被委托的人类授权、短暂的执行上下文，或在紧密决策循环中运行的代理。
重新思考信任层
因此，IT 领导者需要退一步，重新审视信任层本身。这种转变并非理论上的。NIST 的零信任架构（Zero Trust Architecture，SP 800‑207）明确指出：
“所有主体——包括应用程序和非人类实体——在经过身份验证和授权之前，都被视为不可信的。”
在 代理化的世界 中，这意味着 AI 系统必须拥有明确、可验证的自身身份，而不是通过继承或共享凭证来运作。
“企业 IAM 架构是基于所有系统身份都是人的假设构建的，这意味着它们依赖一致的行为、明确的意图以及直接的人类责任来强制信任，”1Password 首席技术官兼 Felicis 风险投资合伙人 Nancy Wang 说。
“代理系统打破了这些假设。AI 代理不是可以训练或定期审查的用户。它是可以被复制、分叉、横向扩展，并在多个系统的紧密执行循环中持续运行的软件。如果我们继续把代理当作人类或静态服务账户来对待，就会失去清晰表示它们代表谁、拥有何种授权以及该授权应持续多长时间的能力。”
Source: …
AI 代理如何将开发环境变成安全风险区
这些身份假设首次失效的地方之一是现代开发环境。集成开发环境（IDE）已经超越了简单编辑器的范畴，成为一个能够读取、写入、执行、获取和配置系统的编排器。随着 AI 代理位于这一过程的核心，提示注入转变不再是抽象的可能性；它们成为了具体的风险。
- 由于传统 IDE 并未以 AI 代理为核心组件进行设计，添加后装 AI 功能会引入传统安全模型未能考虑的新型风险。
- 示例： 一个看似无害的
README可能包含隐藏指令，诱使助手在常规分析时泄露凭证。 - 来自不可信来源的项目内容可能以意想不到的方式改变代理的行为，即使这些内容表面上看起来与提示毫无关联。
- 输入来源现在不仅限于有意运行的文件。文档、配置文件、文件名以及工具元数据都会被代理作为决策过程的一部分摄取，进而影响它们对项目的解释。
当代理在没有意图或责任的情况下行动时，信任会被侵蚀
当你加入高度自治、确定性的代理，并赋予其提升的权限——能够读取、写入、执行或重新配置系统时，威胁会进一步扩大。这些代理具有：
- 没有上下文
- 无法判断身份验证请求是否合法的能力
- 不知道是谁委派了该请求
- 没有内置的行动边界
“有了代理，你不能假设它们具备做出准确判断的能力，而且它们显然缺乏道德准则，”Wang 说。“它们的每一个行为都需要得到恰当的约束，对敏感系统的访问以及在系统内能做的事情也需要更明确地定义。棘手之处在于它们持续在执行动作，因此也需要持续地受到约束。”
传统 IAM 在代理方面的不足
| 假设 | 代理如何违反 |
|---|---|
| 静态权限模型 | 代理执行一系列需要在不同时间使用不同权限级别的操作。最小权限原则不再是“设置后忘记”的配置；必须动态限定，并具备自动过期和刷新机制。 |
| 人为问责 | 传统系统假设每个身份都对应可以追溯到的具体人员，以便追责。代理模糊了这一界限，使其运行的授权主体不明确。复制、修改或在原始目的结束后仍然持续运行时，风险会成倍增加。 |
| 基于行为的检测 | 人为用户遵循可识别的模式（例如在工作时间登录）。代理持续跨多个系统运行，导致合法工作流被标记为可疑，进而压垮传统异常检测工具。 |
| 身份可见性 | 传统 IAM 工具期望静态、可管理的身份。代理可以动态创建新身份，通过现有服务账户运行，或以常规 IAM 解决方案难以检测的方式使用凭证，使其对传统系统不可见。 |
由 1Password 团队准备。
“这涉及整个上下文因素、代理背后的意图，而传统的身份与访问管理（IAM）系统根本无法管理这些，”王说。“不同系统的融合让挑战超越了单纯的身份管理，需要上下文和可观测性来理解不仅是谁执行了操作，还要弄清楚为何以及如何执行的。”
重新思考代理系统的安全架构
保护代理 AI 需要从根本上重新思考企业安全架构
需要进行以下关键转变：
-
将身份视为 AI 代理的控制平面
- 身份应被视为 根本的 控制平面，而不仅仅是另一个安全组件。
- 主要安全厂商已经在每个安全解决方案和技术栈中整合了身份。
-
上下文感知访问是代理 AI 的必需条件
- 策略必须更加细粒度，定义 代理可以访问什么 以及在何种条件下。
- 需要考虑的因素包括：
- 谁调用了代理？
- 代理运行在什么设备上？
- 是否有时间限制？
- 每个系统中允许的具体操作。
-
对自主代理进行零知识凭证处理
- 完全将凭证隐藏在代理视野之外。
- 类似 agentic autofill 的技术在认证流程中注入凭证，而不以明文形式暴露——类似于面向人的密码管理器，但扩展到软件代理。
-
AI 代理的可审计性要求
- 传统审计日志（API 调用、认证事件）已不足够。
- 所需的审计数据包括：
- 代理的身份。
- 其所依据的授权主体。
- 授予的授权范围。
- 为完成工作流所采取的完整操作链。
- 这类似于对人类员工的详细活动日志，但必须能够扩展到每分钟执行数百个操作的软件实体。
-
在人、代理和系统之间强制信任边界
- 为特定人员在特定设备上调用时，明确且可强制执行代理的行为边界。
- 将 意图（用户想要的）与 执行（代理实际执行的）分离。
企业安全的未来在代理化世界
随着代理化 AI 融入日常企业工作流，安全挑战不在于组织是否会采用代理，而在于管理访问的系统能否跟上步伐。
- 在边界阻止 AI 的做法难以规模化。
- 延伸传统身份模型同样行不通。
所需的改变： 转向能够实时考虑上下文、委托和问责的身份系统，覆盖人类、机器和 AI 代理。
“生产环境中代理的跃迁不会仅仅来自更聪明的模型，”Wang 说。“它将来源于可预测的授权和可强制的信任边界。企业需要能够清晰表示代理代表谁、被允许做什么以及何时授权失效的身份系统。没有这些，自治就会变成不可控的风险。有了这些，代理才能被治理。”
赞助文章是由与 VentureBeat 有付费或业务关系的公司制作的内容，始终会有明确标识。欲了解更多信息，请联系 sales@venturebeat.com。