2026-08-04 06:33:20 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文指出AI智能体安全需从可见性转向控制，因为智能体具有自主性、可跨系统运行并引入权限、认证等风险。静态访问控制不足，需理解智能体的所有权、意图、身份等维度，并建立基于意图的统一控制平面。安全团队应停止将可见性视为终点，转而通过关联分析实施规则，将智能体治理融入身份、云和应用安全领域。 综合评分： 85 文章分类： AI安全,安全建设,安全意识,技术标准,解决方案

cover_image

仅仅看到 AI 智能体并不够，安全团队必须控制它们的行为

原创

HackerNews HackerNews

安全行者老霍

2026年7月29日 08:00 美国

在小说阅读器读本章

去阅读

发布时间：2026年7月24日

AI 智能体安全正在经历一个熟悉的成熟曲线：采用、可见性，最终到控制。但我们共同发现的是，为 AI 智能体强制实施最小权限比我们过去想象的更加困难。这也是为什么目前存在如此多的方法，从提示词过滤到身份层访问控制。我们最终认识到，理解 AI 智能体的意图对于保护它们至关重要。这并不容易，但这是唯一的前进道路。

组织面对这一挑战时，采用了不同程度的成熟方法。对于许多组织而言，目前的目标只是发现已经在企业环境中运行的 AI 智能体。这是必要的第一步。AI 智能体正出现在 SaaS 平台、开发环境、云工作流、客户支持系统、生产力工具以及内部应用程序中。其中一些是经过批准，另一些则不是。

但仅仅发现并没有实际价值。AI 智能体并不是被动的；它们能够进行推理、规划、调用工具、调用 APIs、访问数据，并且在没有人工介入的情况下采取行动。风险并不是组织拥有太多智能体，而是这些智能体可以在缺乏一致身份、意图、所有权和控制机制的情况下跨系统运行。此外，AI 智能体也存在不同类型，每种类型都需要采用不同的方法进行安全保护。

近期关于谨慎采用智能体 AI 服务的指导明确指出：智能体 AI 引入了权限（privilege）、认证（authentication）、责任归属（accountability）、设计（design）以及行为（behavioral）风险，这些风险需要安全团队在这些系统被嵌入关键业务流程之前进行处理。可见性是起点，但真正重要的是控制。

1. 可见性陷阱

大多数安全项目开始时都会提出这样的问题：“我们拥有什么？”对于 cloud、SaaS、终端、身份以及漏洞管理来说，这种方式是合理的。对于AI 智能体来说同样如此。

但是，对于 AI 智能体而言，仅停留在可见性阶段所带来的风险，比上述其他环境中的风险更高，因为 AI 智能体创建速度非常快，它们拥有访问权限，并且可以被共享。

一个无法连接到控制机制的 AI 智能体清单，只会成为另一份静态资产列表。它可能显示某个智能体存在，但无法告诉你：

该智能体的访问权限是否合理；
它的行为是否符合其用途；
它的所有者是否仍然承担责任；
或者当环境发生变化时，何时应该撤销它的权限。

对于 AI 智能体来说，没有控制能力的可见性会创造一种危险的信心，让人感觉自己处于控制状态，而实际情况可能完全不同。

2. 为什么 AI 智能体会打破静态访问模型

传统访问控制假设一定程度的可预测性。人类身份和访问管理相对简单，因为每个人都有明确的工作职责。非人类身份（non-human identity）或机器身份管理更加复杂，但一个服务账户仍然对应一个定义明确的工作负载。

这些假设虽然并不完美，但它们为安全团队提供了角色（roles）、权限（entitlements）、审批（approvals）、访问审查（access reviews）以及定期清理（periodic cleanup）的基础。

AI 智能体远非静态对象。一个智能体的定义更多依赖于目标，而不是固定工作流程。它可能解释指令、调用不同工具，并根据上下文调整自身行为。两个拥有类似权限的智能体，根据它们各自试图完成的目标不同，可能具有完全不同的风险等级。

静态访问控制是不够的，因为 AI智能体更容易以授权时未预期的方式被使用。问题并不总是恶意行为，而是存在潜在风险的模糊性，例如一个任务可能超出其最初设计目的。安全团队需要提出的问题不仅仅是：“这个智能体可以访问什么？更重要的问题是：“在这些条件下，为了这个目的，这个智能体应该被允许做什么？”这才是一个控制问题。

3. 控制始于更好的理解

有效的AI智能体控制不能简单附加在一个基础的、缺乏上下文的信息清单之上。安全团队需要在定义有意义的控制措施之前，关联分析所有者、使用者、身份、系统、权限以及意图等信息。

这意味着需要从多个维度理解一个智能体：

所有权（Ownership）：谁拥有这个智能体？（这可能比你想象的更加困难。）
使用者（Consumers）：谁正在使用这个智能体？
身份（Identity）：这个智能体使用哪些 identities、tokens、secrets、OAuth grants 和 service accounts？
意图（Intent）：这个智能体的目标是什么？
访问权限（Access）：它可以访问哪些系统、应用程序、数据存储、APIs 和基础设施？
使用情况（Usage）：这个智能体实际执行过什么操作？执行频率如何？
来源（Origin）：这个智能体是如何创建的？
生命周期（Lifecycle）：这个智能体当前是 active、dormant，还是已经不再与其最初目的相关？

这正是许多组织面临困难的地方，因为智能体的上下文信息是分散的。身份数据存在于一个位置。云权限存在于另一个位置。SaaS 集成拥有自己的权限模型。Infrastructure as Code 可以揭示预期的部署模式，但这些上下文很少会与其他信息进行关联。对于创建智能体的人员来说，所有权可能非常明确，但对于其他人来说却完全不可见。

如果没有关联分析，控制就会变成猜测。有了关联分析，安全团队才能开始制定反映智能体实际运行方式的规则。

4. 从修复转向规则

许多安全工具将控制等同于修复。发现某个风险后，系统通过剧本创建工单、删除访问权限、禁用身份或者通知负责人。这些措施很有价值，但对于 agentic AI 来说还不够。AI智能体需要在采取行动之前、行动过程中以及行动之后都受到控制。

安全团队需要从提出：“发现风险后，应该删除什么？”转变为：“这个智能体从一开始应该被允许执行什么？”这种转变让控制从清理变成真正的控制。组织随后可以定义如下规则：

客户支持智能体可以读取工单历史记录，但不能批量导出客户数据
代码助手可以提出修改建议，但未经批准的工作流程不能直接推送到生产环境
云运维智能体可以检查配置偏差（configuration drift），但不能修改高权限角色
财务智能体可以生成报告，但不能发起付款或修改供应商信息
安全智能体可以对告警进行分类处理，但不能删除日志或抑制检测结果

这些规则无法仅在单个平台内部有效管理。企业将同时使用多个智能体平台、SaaS 原生智能体、内部框架、云服务以及开发工具。每个平台可能拥有自己的控制方式、日志以及权限模型。安全团队需要一种一致的方法，在这种碎片化环境中治理智能体。这就是为什么下一代 AI 智能体控制平面必须具备：以身份为中心感知上下文与平台无关。

5. 意图在控制中的作用

身份回答的是：这个智能体是谁。许可回答的是：存在什么访问权限。意图回答的是：为什么这些访问权限应该保持有效。

意图维度非常关键。AI 智能体风险不能仅仅通过判断某个 API 调用是否在技术层面被允许来理解。安全团队需要评估，一个操作是否符合该智能体被批准的用途。

基于意图的控制（intent-based enforcement）为组织提供了更加精确的控制模型。它允许安全团队从广泛的、静态权限模型，转向基于目的和上下文的条件访问。这并不意味着每一个操作都必须人工审批。它意味着高风险操作应该受到智能体的角色、所有者、任务、环境以及预期结果的约束。

OWASP Top 10 for Agentic Applications 强调了以下风险：

identity 和 privilege abuse
tool misuse
insecure inter-agent communication
cascading failures
rogue agents

这些风险都指向同一个结论：安全控制必须理解智能体行动的原因。

6. 智能体AI 的统一控制平面

AI 智能体并不存在于单一平台中。它们存在于整个企业环境中。虽然“传统”机器身份（machine identities）通常由 IT、Developers 和 DevSecOps 团队创建，但 AI 智能体可以由组织中任何角色的人员创建。一些智能体会运行在云环境中，而另一些则会在本地运行。还有一些智能体会被嵌入到安全团队无法直接管理的业务流程中。针对AI智能体的逐平台控制方式无法实现规模化。

每个平台可能都会创建自己的智能体，但没有任何单一平台能够看到整个企业范围内的身份、访问权限、所有权和生命周期全貌。组织需要一个统一的控制平面，能够跨不同环境理解智能体，并实施一致的控制规则。

这个控制平面应该完成三件事情：

发现（Discover）：找到它们存在于何处的所有智能体。
理解（Understand）：将智能体与 identities、owners、access、infrastructure context、usage 以及 intent 进行关联。
控制（Enforce）：应用规则，管理 agents 可以执行什么操作、什么时候可以执行，以及当上下文发生变化时访问权限应该如何调整。

了解像 Token Security 这样的 AI-first security solutions 如何发现、理解并控制你的 AI智能体在所有平台上的能力。

这就是管理智能体蔓延（agent sprawl）和治理智能体AI 之间的区别。当每个平台、团队和业务部门独立创建智能体时，就会产生智能体蔓延。而当组织能够在不阻碍创新的情况下，对这些活动应用一致的控制措施时，就实现了治理。

7. 安全领导者现在应该做什么

安全团队不需要等待完美的标准或者完全成熟的工具出现之后再采取行动。他们现在就可以开始建立运营模型。

第一步，是停止将 AI 智能体可见性视为最终目标。当然，智能体清单是实施控制的基础。每一个智能体都应该被映射到：

一个所有者（owner）
一个目的（purpose）
一个身份（identity）
一组权限（permissions）
一个生命周期状态（lifecycle state）

没有所有者的智能体应该被调查。权限过高的智能体应该进行权限调整（right-sized）。处于休眠状态的智能体应该被挂起。高风险操作应该要求更强的控制措施。但最终，真正重要的是控制。

安全领导者应该将 AI 智能体治理与以下领域结合：

identity and access management
cloud security
application security
DevOps workflows

智能体AI 并不是一个独立存在的领域。它本质上是具有访问权限、自主能力和业务影响的软件。它应该被纳入企业安全模型之中，但这个模型必须不断演进。

NIST’s AI Agent Standards Initiative 也指向同一个方向，其工作重点包括：

标准（standards）
协议（protocols）
认证（authentication）
身份基础设施（identity infrastructure）
安全的人机交互和多智能体交互（secure human-agent and multi-agent interactions）

市场正在朝着同一个结论发展：AI智能体需要被作为具有权限的行为主体（actors with authority）进行治理，而不能被当作带有聊天机器人界面的普通应用程序。

8. 可见性是开始，但控制才是目标

AI 智能体安全的第一阶段关注的是认知。组织需要意识到，智能体正进入企业环境，并创造新的身份风险。这一观点已经被接受，每个安全团队和 IAM 团队都知道他们需要可见性。下一阶段是控制。

企业需要定义智能体被允许执行什么操作，并跨平台一致地实施规则。他们需要从：“哪些智能体存在？”转变为：“哪些智能体可以在什么条件下执行哪些操作，以及谁对此负责？”

这正是智能体 AI 所需要的控制平面。不是另一个 dashboard，也不是静态清单。AI智能体正逐渐成为企业运营中的主动参与者。它们将：

编写代码
管理基础设施
移动数据
更新系统
执行业务流程

能够成功应用智能体 AI 的组织，不会只是那些能够发现所有智能体的组织。而是那些能够充分理解每一个智能体，并能够控制它可以执行什么操作的组织。

https://thehackernews.com/2026/07/seeing-ai-agents-is-not-enough-security.html

（完）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全行者老霍 HackerNews HackerNews《仅仅看到 AI 智能体并不够，安全团队必须控制它们的行为》