Red Hat AI

AI agent security with policy-driven access control

8.5内容质量

TL;DR · AI 摘要

AI代理安全存在重大漏洞,策略驱动的访问控制是关键解决方案,Red Hat提出跨系统统一治理方法。

核心要点

  • 70%企业部署AI组件但82%缺乏实时可见性,需策略驱动访问控制
  • 过度授权导致不同代理访问相同数据,增加65%安全事件风险
  • Red Hat提出整合治理政策与运行时执行的跨系统统一方法

结构提纲

按章节快速跳转。

  1. 引用Cloud Security Alliance数据揭示AI代理安全现状及行业缺口

  2. 分析当前AI代理部署中因配置复杂导致的权限滥用问题

  3. 指出现有方法未解决治理策略到运行时执行的转化问题

  4. ·Red Hat解决方案

    提出策略驱动的跨系统统一访问控制架构设计

  5. 说明多系统策略配置接口不兼容带来的工程复杂性

  6. 呼吁行业合作开发新工具解决策略执行断层问题

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • AI代理安全治理
    • 现状问题
      • 70%部署AI但82%无可见性
      • 65%发生安全事件
    • 核心挑战
      • 过度授权危机
      • 多系统策略接口不兼容
    • 解决方案
      • 策略驱动访问控制
      • 跨系统统一治理

金句 / Highlights

值得收藏与分享的关键句。

#AI安全#策略驱动#Red Hat#访问控制
打开原文

基于策略的访问控制保障AI代理安全

Component | Article_teaser

2026年10月27日

7分钟阅读

人工智能

Ana Biazetti

Red Hat AI首席资深工程师

Umberto Manganiello

高级工程师

Stuart Battersby

AI安全与模型评估架构师

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0许可

Subpattern | results_nav

组布局

Component | Nav_links

  • 返回所有文章

Component | Generic

自主代理AI的部署正在企业中加速推进。云安全联盟的最新研究表明,目前70%的组织已将AI组件投入生产,但82%的组织缺乏对AI运行时行为的实时可见性。更令人担忧的是,65%的组织已经遭遇过与自主代理AI相关的安全事件。

这些数据揭示了我们在保障自主代理AI系统安全方面存在根本性缺口。我们拥有完善的认证和授权框架,理解身份和访问管理,也理解沙箱技术并将其应用于AI代理。缺失的关键环节是将治理策略转化为运行时执行。这不是Red Hat的挑战,也不是开源社区的挑战——这是整个行业需要全新方法解决的系统性问题。

过度授权危机

尽管我们拥有OAuth 2.0和OpenID Connect(OIDC)等用户认证协议,以及Open Policy Agent(OPA)等授权引擎等强大技术基础,但当前生产环境中的代理部署默认模式却是过度授权。AI代理通常被授予广泛的数据源访问权限,因为配置细粒度策略既复杂又容易出错,且与治理团队的数据访问思维方式脱节。

以财产和意外险保险公司为例:核保代理需要访问风险评估数据和财产估值来制定新保单价格;理赔调整代理需要访问保单详情、理赔历史和欺诈指标来处理理赔;合规官代理只需要审计日志和监管文件的只读访问权限。这些是职责分明、数据需求不同的角色,但当前代理部署现状往往让这三个代理都能访问相同的数据超集。

为什么会出现这种情况?因为替代方案是需要在多个执行点手动配置授权策略:向量数据库、特征存储、数据目录、Amazon Simple Storage Service(Amazon S3)存储桶以及Model Context Protocol(MCP)工具服务器。每个系统都有自己的策略语法、身份模型和配置界面。这种认知负担令人难以承受。结果就是用户可以提示代理请求超出其职责范围的数据,因为这些数据在技术上是可访问的。

这是治理与运行时执行之间缺失的翻译层。治理团队通过自然语言文档编写策略,描述角色、数据分类、访问边界和合规要求。工程团队随后需要在多个系统中配置执行规则。每个执行点都有自己的语法、身份模型和配置界面。

目前没有系统化的验证机制来确认这些配置的执行点是否真正实现了治理意图。当治理策略发生变化时,没有自动化的方法重新生成执行配置或验证现有配置是否仍然合规。随着时间推移,策略意图与运行时行为之间的差距会不断扩大。

第二个挑战进一步加剧了这个问题。MCP和类似的代理工具协议解决的是工具授权问题:该代理是否可以调用此工具或连接到此服务?而数据访问控制要解决的是另一个问题:当该工具运行时,对于特定用户和任务,可以返回哪些资产、记录和字段?这个决策仍然需要在特征存储、数据目录、向量数据库和对象存储等多个系统中强制执行。代理直接访问这些系统,每个系统都有自己的身份模型和授权机制。创建一个覆盖所有执行点的统一策略层,需要协调多个策略引擎、身份提供商和执行机制。这不仅是配置挑战,更是当前任何单一工具都无法解决的集成难题。

一种新的开源方法

新兴的方法将治理文档——即治理、法律和合规团队编写的自由文本文档——视为真实来源,并自动将其翻译为执行配置。这不是新的运行时代理,也不是现有授权引擎的替代方案,而是在治理与执行之间新增的翻译和验证层。

核心工作流程分为三个阶段。第一阶段是策略提取,通过分析治理文档提取结构化访问规则。自然语言处理技术用于识别角色、数据源、允许的操作和访问条件。输出结果是治理意图的机器可读表示。

第二阶段是授权规则生成,将提取的策略映射到现有系统的执行配置。为向量数据库生成访问控制列表,为特征存储生成权限策略,为对象存储生成存储桶策略,为MCP服务器生成工具白名单。目标不是发明新的策略语言,而是为现有执行点生成正确的配置。

第三阶段是数据访问验证,用于验证生成的配置是否真正执行了预期策略。这是对数据访问的自动化红队测试。生成应成功通过的测试场景:承保代理请求风险评估数据。生成应失败的测试场景:承保代理请求理赔信息。将这两组测试同时运行在实时执行层上。如果授权场景失败或未授权场景通过,说明配置与策略不匹配。

开源构建模块

行业已经拥有许多实现该方法所需的组件,但这些组件尚未组合成完整的解决方案。

代理运行时提供执行环境。OpenShell 提供带有身份集成和凭证范围控制的沙箱执行。OpenClaw 正在演进为一个协调框架,用于协调多个代理并支持可插拔的安全策略。策略框架负责提取和评估。Asago 是一个开源框架,通过从治理文档中提取策略并为验证测试生成场景,为基于策略的代理安全提供支持。MCP 等协议标准化了代理与工具之间的交互并提供协议级钩子,但仍需要基于策略的配置来控制代理通过这些工具可以访问的数据。Garak 等测试框架和 EvalHub 等评估自动化工具可自动化红队测试和安全测试。

这些是可组合的模块。没有单一工具能解决所有问题,但构建模块已经存在。行业当前需要的是协作,将这些组件串联起来,标准化它们之间的接口,并创建企业可采用的参考实现。

我们测试的内容

我们使用并扩展了 asago,测试了一个基于策略的数据访问工作流,用于只读检索增强型保险助手。该助手通过相同的聊天界面为具有不同职责的用户提供服务。核保员可以检索核保指南和财产风险信息,但无法检索理赔数据。合规审查员可以检索两个领域的信息以进行监督和审计。

测试从治理策略和一段用纯文本描述助手角色、数据源和预期访问边界开始。Asago 利用这些输入识别相关风险并生成违反组织边界的有害场景,用于测试并随后告知代理的访问策略。生成的工件通过评估工作流执行。

基于 asago 生成的风险场景,我们测试了核保员的跨领域请求。在基线配置中,助手可以将理赔信息与允许的核保内容一并返回。评估识别出该行为属于策略违规。随后,权限推荐器使用策略派生的工件、评估结果和部署的数据资产配置,为数据发现和检索层提出权限变更建议。在此概念验证(PoC)中,这些层通过数据注册表实现资产发现,使用 Feast 进行检索。

应用建议权限后,我们重新运行评估工作流。核保员仍可检索核保信息,但理赔检索被拒绝。合规审查员仍保留对两个领域的授权访问。结果证明,基于策略的测试可以识别数据访问缺口,推动可审查的配置变更,并验证修复后的预期行为。

图 1:基于策略的数据访问端到端流程示例

行业影响

对数据领导者而言,这种方法提供了一条从被动到主动数据治理的路径。在代理投入生产之前,您可以通过验证运行时行为是否符合治理文档,而不是通过审计或事件发现访问违规。策略变更会触发执行配置的自动重新生成和重新验证。治理变得持续进行,而非周期性。

对于安全团队而言,这减少了攻击面。权限过高的代理代表了广泛的攻击向量,因为拥有全部数据访问权限的代理可能被提示注入攻击以窃取任意数据。而将代理的访问权限限定在角色范围内,可以有效限制攻击成功后的潜在影响,且边界会通过自动化边界测试持续验证。最后,审计日志能够将每一次数据访问追溯到具体的角色、任务和治理策略。

对于平台团队而言,这些构建模块的开源特性至关重要。您不会被绑定到单一供应商的授权模型或策略语言,可以逐步采用组件。您可以从治理文档中提取策略开始,之后添加场景生成用于验证,最后再与现有的授权引擎集成。前进的道路是模块化的,而非单体式的。

Red Hat 正与 asago 和 MCP 社区以及 OpenShell 和 Open Agent Safety Platform 一起参与这一生态系统。我们正在探索 Red Hat OpenShift AI 如何为代理工作负载呈现基于策略的访问控制。我们的目标不是独占解决方案,而是通过贡献行业标准和开源工具,使基于策略的代理安全对所有企业都可及。

前进的方向

代理 AI 的部署速度正以超越安全成熟度的速度加快。治理意图与运行时执行之间的差距是真实且可衡量的。79% 的安全负责人预计会发生事件,这一判断并非错误。权限过高的代理正在等待成为安全事件。

新兴的基于策略的访问控制开源工具为前进提供了路径。策略提取、授权规则生成和自动化验证可以帮助弥合翻译差距。结合现有的构建模块如 OpenShell、MCP 和 asago,可以创建一个统一的执行层,覆盖代理的数据访问点。

当前的方法仅处理数据集级别的访问控制。代理要么可以访问数据源,要么不能访问,但现实世界的治理需求需要更精细的粒度。例如在理赔数据集中包含的个人身份信息(PII)。合规官可能需要包括 PII 的完整访问权限以进行审计。理赔调整员需要查看案件叙述,但不应看到被删除的个人标识符。精算师不应访问任何理赔数据。这种字段级访问控制,即代理可以访问数据集,但根据角色对特定 PII 字段进行遮蔽或排除,代表了下一个前沿领域。基于策略的方法必须演进以表达和执行这些粒度控制。

没有单一供应商能解决这个问题。行业协作至关重要。政策表示标准、执行点之间的接口以及验证框架需要统一。开源模式通过使构建模块对整个社区可见、可组合和可改进,加速了这种统一的实现。

如果您正在生产环境中部署 AI 代理,请立即开始提出这些关键问题。基于其任务,这个代理被允许对数据执行哪些操作?如何验证运行时行为与治理意图一致?当治理策略发生变化时会发生什么?这些问题目前还没有完美的答案,但行业正在积极构建这些答案。

Learn how Red Hat AI approaches agent security and explore the asago framework for policy-driven access control. The conversation is happening in open source communities, and your enterprise's requirements will shape the solutions that emerge. Join us.

Block | Dynamic pattern deluxe promo

Component | Band_header

Product trial

Red Hat OpenShift AI (Self-Managed) | Product Trial

An open source machine learning (ML) platform for the hybrid cloud.

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

Try it

Deluxe mbox

Component | Card_header

About the authors

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Ana Biazetti

Subpattern | social_links

Ana Biazetti 是 Red Hat OpenShift AI 产品组织的高级架构师,专注于模型定制、微调和分布式训练。

更多该作者的文章

Umberto Manganiello

Umberto Manganiello 自 2025 年起担任 Red Hat 的高级工程师。此前,他在金融和电信领域担任过 15 年的首席架构师和工程师。他专长于设计可大规模运行的高可用性系统,具备 Kubernetes、Kafka 和云现代化的深厚专业知识。目前,他将这种架构能力应用于 MLOps 的挑战,重点关注生成式 AI、OpenShift AI 和 Kubeflow,将云原生的弹性与 AI 模型训练流程相结合。

Stuart Battersby

Stuart Battersby 博士是 Red Hat 的 AI 安全与模型评估架构师,专注于构建开源 AI 安全工具。他目前在英国工作,拥有丰富的 AI 安全与评估经验。

在加入 Red Hat 之前,Stuart 是 Chatterbox Labs 的创始人兼首席技术官,领导开发了 AIMI 平台,该平台致力于解决 AI 安全和安全领域的新挑战。Red Hat 于 2025 年 12 月收购了 Chatterbox Labs。

他拥有伦敦玛丽女王大学的博士学位,并是两项 AI 专利的发明人。他的工作涉及人工智能、安全和安全工程的交叉领域,重点是采用开源方法进行 AI 治理和评估。

More like this

Dynamic pattern

Blog post

Atos 如何利用 Red Hat AI 构建更小、更专业的主权 AI 模型

在 AI 时代保障企业软件供应链安全

Original podcast

代理 AI 能够修补互联网吗?

Red Hat 如何为可扩展 AI 清理 IT 债务

Subpattern | card_flex

Subpattern | text_basic

Keep exploring

  • 什么是代理 AI?文章
  • 预测性 AI 与生成性 AI 对比 文章
  • 构建生产就绪 AI/ML 环境的要点 电子书
  • 以 Ansible 方式实现生成性 AI 视频
  • 通过现代应用平台实现创新与转型 电子书

Keep Exploring mbox

Subpattern | simple_text

Browse by channel

Explore all channels

Pattern | raw_html

Automation

IT 自动化的最新进展,适用于技术、团队和环境

Artificial intelligence

关于使客户能够在任何地方运行 AI 工作负载的平台的最新动态

Open hybrid cloud

探索我们如何通过混合云构建更加灵活的未来

Security

关于我们在各种环境和技术中降低风险的最新动态

Edge computing

关于简化边缘计算平台操作的最新动态

Infrastructure

关于全球领先的企业的 Linux 平台的最新动态

应用

应对最具挑战性的应用难题的解决方案

虚拟化

企业虚拟化的未来,无论是本地部署还是跨云环境的工作负载