Why prompt-level guardrails aren't enough: The platform security layers production agents need

为什么提示级别的防护措施不足：生产代理所需的安全平台分层

Component | Article_teaser

2026年7月21日

9分钟阅读

人工智能

Richard Naszcyniec

AI技术产品市场总监

Joshua Wilson

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

一个代理错误地将4000美元计入了错误客户的账单账户，直到周一才被发现。这个代理并没有故障——它完全按照设计运行。它拥有广泛的API凭证，模型选择了看似合理但错误的账户标识符，而基础设施中没有任何机制阻止此次调用。没有身份边界，没有作用域限制，没有审计日志。

我曾见过团队通过在代理代码中添加更多检查来应对此类故障——if-else语句、硬编码的白名单、手动凭证轮换。这种方法无法扩展。当单个AI代理部署在一夜之间遭遇3次故障——43个重复工单、4000美元错误计入账户，以及一个虚构的退款政策导致公司不得不兑现280美元退款时，问题的共同点不是模型或框架，而是生产基础设施的缺失。

BYOA（自带代理）是Red Hat AI的解决方案：平台为任何代理框架提供生产基础设施，无需代码修改。开发环境中的可用代理与生产就绪部署之间的差距不是框架问题，而是基础设施问题。第一个需要弥补的基础设施差距是安全，这也是最显著的差距。

在传统软件中，你保护的是应用程序。而在代理场景中，你保护的是一个自主执行操作、调用API且无需人工批准每个动作的自主代理。没有哪个代理框架提供这种解决方案，但Red Hat AI做到了。

带上你的框架——Red Hat提供平台

Red Hat不在框架层竞争。无论代理运行在LangChain、CrewAI、Claude Agents、Google ADK、Strands还是自定义Python上，平台都能实现其生产化。本文提到的安全功能适用于所有框架。团队无需在首选框架和生产级安全之间做出取舍。通过Red Hat AI，两者兼得。

我认为这比AI堆栈中的大多数决策都更重要。组织已经投入了真实的工程时间到框架选择上。一些团队选择LangChain是因为那里有教程，另一些团队选择CrewAI用于多代理模式，或选择Google Agent Development Kit（ADK）因其集成方案。BYOA意味着这些投资不会被浪费。Red Hat AI为团队已构建的任何内容提供身份验证、沙箱环境和治理——无需重写代码。

对于开发者，代理代码无需任何改动。对于决策者，组织在框架上的投资得到保护，且无论代理运行在何种框架上，安全基础设施都保持一致。

每个代理都拥有身份

/think

$4,000 的错误账户收费问题源于代理使用了跨环境共享的单一广义凭证。模型选择了错误的账户标识符，这是大型语言模型（LLM）可能发生的合理错误，而基础设施系统无法发出“你无权访问该账户”的拒绝指令。

我曾审查过生产环境中的代理部署案例，其中单个 API 密钥被同时用于测试环境和生产环境。传统软件常使用硬编码的 API 密钥或长期凭证。在大规模部署时，这会带来维护负担和安全隐患。对于代理系统而言情况更糟，因为代理会自主使用这些凭证，以机器速度调用 API。

SPIFFE/SPIRE 是一种标准，它为每个工作负载分配可验证的加密身份，彻底消除硬编码凭证的需求。每个代理在启动时会注入短期工作负载身份凭证（称为 SVID，即 SPIFFE 可验证身份文档），形式为 x509 证书或 JSON Web Token（JWT）。凭证上的身份属性决定了代理可以访问哪些服务，下游系统会根据这些属性执行授权验证。当凭证过期时，系统会自动发放新凭证。开发者无需管理密钥轮换。

通过加密身份机制，代理的访问范围被严格限制在已授权的服务范围内——平台控制服务的可达性，而下游 API 会根据代理的身份声明执行细粒度授权。需要明确的是：默认情况下，模型上下文协议（MCP）服务器访问使用的是开发者的 kubeconfig 凭证，这些凭证通常比生产环境代理应拥有的权限更广。本文描述的受控、有限访问是目标状态，需通过 MCP 网关强制执行令牌作用域策略——平台提供该能力，但需要配置。只有在两个层级都缺乏身份边界的情况下，$4,000 的错误收费才可能发生。SPIFFE/SPIRE 将平台级边界作为基础设施的一部分，而非依赖开发者的自律或代码审查。

对决策者而言，审计流程将发生根本变化。SPIFFE/SPIRE 将每次调用都关联到加密身份，MCP 网关会记录授权和拒绝的请求，MLflow 追踪会捕获执行轨迹。当凌晨 2 点发生异常时，这些基础组件能帮助确定是哪个代理发起的调用，以及它被授权执行哪些操作。组织可将这些组件组合成符合其特定合规要求的审计叙事。

沙箱机制：当代理行为异常时会发生什么

身份机制回答的是“这个代理被允许做什么？”的问题，而沙箱机制回答的是另一个问题：“即使代理做出意外行为，它能物理访问哪些资源？”

我发现这是大多数团队最容易忽视的区别。他们假设只要授权正确，代理就不可能造成危害。但代理是非确定性系统。提示注入攻击（恶意指令隐藏在代理处理的数据中）、工具响应被篡改，或代理代码中的缺陷，都可能导致无人预料的行为。当仅靠身份机制不足以控制风险时，沙箱机制能限制潜在影响范围。

如果某个代理程序能够访问到宿主操作系统，它就可能影响机器上所有其他工作负载。Kata Containers 是一种沙箱容器，为每个代理会话分配独立的内核，与宿主操作系统和其他代理会话完全隔离，可以有效防止这种情况。即使代理程序被攻破（例如通过提示注入、恶意工具响应或代码缺陷），它也无法突破内核边界。从攻击者的角度看，没有可访问的宿主系统；对开发者而言，无需修改代码——通过运行时类注解在部署时选择 Kata Containers 即可。

在容器内部，OpenShell（由 Red Hat 与 NVIDIA 合作开发的开源代理运行时，Red Hat 正将其集成到 Red Hat AI 以增强代理安全性和可操作性）增加了更细粒度的第二层防护。每个进程的网络策略可精确控制其能访问的外部服务。凭证占位符重写机制确保代理程序从不接触真实的 API 密钥——它看到的只是系统在调用时解析为限定令牌的占位符。Landlock 是 Linux 内核的一项功能，通过内核级而非应用程序的限制，阻止代理程序访问其指定范围外的文件。

对组织而言，两个独立的隔离层意味着单个配置错误或被攻破的库更难暴露宿主系统或其他工作负载。团队可以明确向合规审计人员说明每个代理程序能访问和不能访问的内容——这些声明由内核级强制执行保障，而非应用程序层面的承诺。

按身份而非提示控制工具访问权限

沙箱限制了代理程序能物理执行的操作，但代理程序也需要调用工具——API、数据库、外部服务。谁来决定代理程序能访问哪些工具？

如果这个决策逻辑位于代理程序的推理过程中——"我应该检查是否允许调用这个 API"——那么它就存在漏洞。攻击者通过提示注入影响代理程序的推理过程，就能绕过该检查。我曾目睹演示中，一段注入到检索文档中的文字就让代理程序调用了明确被禁止的 API。代理程序的内部逻辑本身并非安全边界。

这不是理论上的担忧。最近对代理技能市场的 VirusTotal 扫描发现，某单一发布者上传了 314 个恶意技能——这些技能伪装成生态系统中已存在的合法工具。恶意载荷是一段 README 文件中的文字，指示代理程序将敏感数据发送到外部服务器。研究人员将这种攻击称为语义恶意软件，即以自然语言指令形式传递的攻击，传统恶意软件扫描器无法检测。当威胁是一段精心设计的段落时，防御机制无法依赖代理程序的推理过程。

架构层面的解决方案是将授权机制完全移出代理程序。MCP 网关正是这样实现的。它验证令牌声明、忽略提示内容，如果代理程序的令牌未包含对特定工具的访问权限，MCP 网关将直接拒绝调用请求。无论代理程序的推理过程是否被攻破，这都无关紧要。

MCP网关为下游服务执行OAuth2令牌交换，因此代理程序从不处理原始凭证。它将多个MCP服务器聚合为单一端点，并根据代理身份过滤可用工具。开发人员只需将代理指向单一网关端点，即可获得统一的工具目录，该目录范围限定为其代理实际被授权使用的工具。如需详细了解MCP网关的认证模式——基于身份的工具过滤（使用加密腕带令牌）、OAuth2令牌交换以及HashiCorp Vault集成，请参阅Red Hat Developer博客上的《MCP网关的高级认证与授权》。

将这一机制与6 AM事件关联起来——由于MCP网关在网络层强制实施基于身份的工具访问控制，代理的访问范围被严格限制。网关控制代理可调用的服务。对于$4,000的错误账户收费（很可能是使用了错误账户参数的同一API），平台限制了可访问的服务范围，而下游服务针对代理身份声明的正确授权配置也限制了有效账户的范围。这两层防护共同降低了潜在影响。对决策者而言，这种分离意味着安全策略由平台团队管理，而非嵌入每个代理的源代码中——当组织在多个团队中运行数十个代理时，这种差异具有重要意义。

推理边界的防护

6 AM事件中出现的虚构退款政策源于完全不同的故障模式。这并非工具调用错误或凭证问题。模型生成了看似合理但错误的响应——声称90天退款窗口期，而实际政策是30天——且在客户看到之前没有任何拦截措施。客户在第47天根据代理的回应退回了价值$280的产品，团队接受了退货。法律部门则对代理做出未经授权的合同表述所暴露的风险发出警告。

这就是推理边界问题，即模型输出转化为行动的临界点。模型生成的每个响应都会经过这个边界。若未在此边界实施管控，伪造的声明将抵达客户、被存储到数据库，或作为其他代理推理的输入。

NVIDIA NeMo Guardrails（可编程对话约束框架，用于强制执行内容安全、主题边界和事实约束）作为推理边界的旁车组件运行，而非作为独立的API跳转。我需要强调这一点的重要性：由于它们在推理层运行，因此无论调用方使用何种框架，都会应用相同的约束。使用LangChain的团队和使用CrewAI的团队都能获得一致的安全管控。伪造的退款窗口期会在抵达客户响应前被拦截，而无需代理开发者编写任何安全逻辑代码。

Trusty AI Guardrails Orchestrator（作为Red Hat OpenShift AI的一部分提供）对模型输入和输出进行筛选，在推理堆栈中提供安全策略的执行点。与NVIDIA NeMo Guardrails配合使用，它为团队在推理边界提供分层的安全控制，而非在部署后作为附加组件进行安装。

在代理投入生产之前，NVIDIA Garak（Red Hat AI 的一部分）提供对抗性漏洞扫描——一种自动化红队测试，可识别越狱、提示注入漏洞和其他攻击向量。可以将其视为对代理的渗透测试，作为部署流程的一部分进行。对于需要满足严格监管要求的行业来说，未经此类预生产测试就部署代理，是大多数合规团队无法接受的风险。如果想了解运行 Garak 探针针对真实代理的实证结果（包括发现仅通过沙箱隔离即可将凭证泄露率从 67% 成功降至零的结论），请参阅 Red Hat Developer 上的《使用消融模型进行基础设施红队测试》。

基础设施始终是解决方案

每个凌晨 6 点的故障都可以在平台层解决，无需更改一行代理代码。针对错误账户被收取 4000 美元的修复方案不是更好的提示设计，而是限定身份。针对导致公司损失 280 美元的伪造退款政策的修复方案不是更智能的模型，而是推理边界防护。我反复强调这一点，因为它重新定义了团队应投入时间的方向。当安全性依赖于代理代码时，每个团队都需要重新构建它，每个框架的实现方式都不同，每个新代理都会带来新的攻击面。当安全性由平台保障时，代理开发者只需专注于代理的功能，而平台会确保代理只执行该功能。对于需要应对严格监管和合规要求的组织而言，这意味着安全测试、审计追踪和合规验证将在组织控制的基础设施上运行，而非租用的基础设施。

现在代理已被锁定，下一个问题是该代理实际上可以访问哪些资源，以及当任务过于复杂、单个代理无法独立处理时，它如何与其他代理协作。

入门指南

准备好在 Red Hat AI 上直观体验代理安全性了吗？

• 在开发者沙箱中免费试用 OpenShift AI：在预配置环境中测试代理安全功能。
• 体验纵深防御交互式演示：直观了解分层代理安全机制。
• 在 OpenShift AI 上探索 NeMo Guardrails：配置推理边界安全控制。
• 开始 OpenShift AI 学习路径：包含安全配置的动手教程。
• 每一层都至关重要：使用 Red Hat AI 的 AI 代理纵深防御指南：包含映射攻击场景的六层安全框架和 OpenClaw 部署流程演示。

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

企业组织 AI 入门指南：初学者手册

了解 Red Hat 如何帮助您采用并扩展 AI 解决方案。探索两种 AI 类型（预测型和生成型）及其独特优势。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

获取资源

Deluxe mbox

Component | Card_header

关于作者

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Richard Naszcyniec

Subpattern | social_links

在Sybase、Siebel Systems、Oracle、IBM和红帽（自2012年起）等公司拥有三十多年软件行业经验，我目前担任AI技术架构师和AI未来趋势专家。在红帽任职期间，我曾领导团队通过战略性销售策略提升全球销售业绩，并此前负责应用服务（中间件）事业部的技术竞争营销管理。如今，我的使命是解析AI架构，帮助专业人士和组织理解AI如何创造商业价值、推动创新并有效集成到软件解决方案中。我凭借丰富经验，指导AI的战略实施，工作重点在于阐释AI架构的组成部分、实际应用方式以及如何转化为具体商业效益，例如获得竞争优势、实现差异化并以简单创新的方案令客户满意。我热衷于赋能企业不仅利用AI预见未来技术格局，更主动塑造未来。同时，我致力于推动AI的负责任使用，使每个人都能超越以往的成就。

更多该作者文章

Joshua Wilson

类似内容

动态模式

博客文章

物理AI：当机器开始在现实世界中思考和行动

模型即服务（MaaS）治理：管理AI访问权限和令牌配额

原始播客

技术访谈 | 用开源定义主权AI

技术访谈 | 开源AI战略解析

子模式 | card_flex

子模式 | text_basic

继续探索

• 什么是智能体AI？文章

• 预测性AI与生成性AI对比 文章

• 构建生产级AI/ML环境的首要考虑因素 电子书

• 以Ansible方式实现生成性AI 视频

• 通过现代应用平台实现创新与转型 电子书

继续探索 mbox

子模式 | simple_text

按频道浏览

探索所有频道

模式 | raw_html

自动化

关于IT自动化在技术、团队和环境中的最新动态

人工智能

关于使客户能够随时随地运行AI工作负载的平台的最新动态

混合云

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

安全

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

边缘计算

关于简化边缘运算平台的最新动态

基础设施

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

应用程序

深入探讨我们解决最复杂应用程序挑战的方案

虚拟化

关于企业虚拟化的未来，无论是在本地还是跨云环境中