Red Hat Pushes Infrastructure Controls as AI Prompting Fails at Scale

提示词工程在规模化应用中失效，红帽力推基础设施级管控 企业级 AI Agent 需要容器隔离、动态凭据轮换和治理闸门，因为单纯依靠提示词工程无法防止自主模型泄露数据或产生灾难性的巨额云账单。 Sawyer Bowerman 指出，在生产环境中管控 AI Agent 不能仅依赖提示词工程，而需要在 Kubernetes 和 OpenShift 上构建强健的容器平台基础设施。他剖析了四大核心架构支柱：通过命名空间和网络隔离实现工作负载沙箱化、借助 HashiCorp Vault 和 RBAC 实现动态凭据处理、利用 MLflow 和 OpenTelemetry 等工具实现完整的分布式追踪，以及针对高风险操作设立包含“人机协同”（Human-in-the-Loop）审批闸门的代码化治理。这些实践相辅相成，可有效防止意外数据损毁、API 支出失控以及云规模急剧膨胀带来的巨额账单等常见生产灾难。 仅靠提示词工程不足以保障企业生产环境中 AI Agent 的安全，必须建立基础设施层面的防护栏。 (0:04) 不受约束的 AI Agent 行为可能像儿童一样不稳定，但其行为产生的运维和业务后果仍由部署机构承担。 (1:38) Kubernetes 和 OpenShift 等容器平台中的命名空间隔离可以建立沙箱，防止 Agent 访问未经授权的资源。 (1:38) 限制入站和出站流量的细粒度网络策略，可阻止 Agent 扫描内部网络或发起未授权的外部 API 调用。 (1:38) 将 API 密钥和凭据存储在静态环境文件中，会使生产环境的 Agent 容易遭受提示词注入和凭据失窃攻击。 (4:10)

Red Hat argues that system prompting alone cannot secure autonomous AI agents in production environments, requiring enterprise teams to enforce four platform-level pillars: isolation, identity, observability, and governance across container orchestration infrastructure. Infrastructure Sandboxing via Namespaces and Network Policies (1:38) Sawyer Bowerman, an AI Developer Advocate at Red Hat, compares AI agents to children who act unpredictably, noting that organizations remain liable for any operational fallout. Unconstrained agents with write permissions pose existential risks to databases; for example, an agent directed to clean legacy records could interpret its prompt by wiping all tables past a target date. To restrict potential blast radiuses, Red Hat recommends treating Kubernetes and OpenShift primitives as the baseline perimeter. Under this model, dedicated namespaces function as execution sandboxes, isolating agents from unintended cluster components. Network policies enforce strict ingress and egress boundaries on network ports, blocking autonomous agents from carrying out internal network reconnaissance or making unapproved outbound calls when interfacing with foundation models. Credential Protection and Role-Based Access Control (4:10) While storing access tokens and credentials in flat `.env` files is common during early prototyping, Bowerman cautions that this practice leaves production workloads vulnerable to prompt injection attacks and automated exploitation. To safeguard system identity, secrets must be dynamically injected into workloads using Kubernetes Secrets or tools like HashiCorp Vault, backed by automated credential rotation to phase out stale tokens. Red Hat emphasizes role-based access control (RBAC) to enforce privilege separation between different agent personas. Without strict identity boundaries, internal analysis agents handling confidential customer data could be breached or tricked via external-facing chatbot interfaces, causing data to leak across multi-tenant boundaries. Distributed Tracing and Telemetry for Tool Invocations (7:55) Because generative models are non-deterministic, diagnosing runtime failures requires deep visibility into agent execution paths. Bowerman cites a failure case where an agent assigned to refactor legacy code into Rust entered an infinite loop, executing 10,000 external API calls and generating a $500 bill within minutes. Without granular telemetry, engineers cannot isolate which tool invocation triggered the divergence. Implementing distributed tracing frameworks—such as MLflow, OpenTelemetry, and Jaeger—allows teams to capture ingress and egress payloads, raw JSON responses, and intermediate tool invocations. Bowerman notes that tracking the reasoning chain enables developers to audit agent decisions and catch sensitive data leaks before unmonitored API calls compound. Policy as Code and Human-in-the-Loop Gates (10:36) Autonomous operational remediation introduces substantial financial and system stability risks if left ungoverned. In one hypothetical failure mode, an agent attempting to fix a performance bottleneck might unilaterally scale cluster worker nodes tenfold, generating a $50,000 cloud infrastructure bill. Governance architectures counteract this by evaluating agent intentions against programmatic policy-as-code rules. When proposed actions exceed risk or budget parameters, execution halts automatically. Safe, low-impact tasks proceed autonomously, while destructive or costly actions require an explicit approval gate managed by either a human operator or a designated supervisory agent before production changes execute. Bowerman recommends prioritizing platform adoption in stages: first establishing isolation and identity baselines through container runtimes, then instrumenting observability to track reasoning chains, and finally codifying governance policies. Red Hat is packaging these controls into enterprise frameworks, including the Red Hat AI Factory developed with NVIDIA and upstream open-source initiatives like Open Shell.

红帽（Red Hat）人工智能开发者倡导者兼技术营销工程师 Sawyer Bowerman 指出，在企业级生产环境中，单纯依赖提示词工程（Prompting）无法有效约束自主智能体的不确定行为。为防止灾难性失误并保证系统安全，企业必须在 Kubernetes 和 Red Hat OpenShift 等容器编排底层构建隔离、身份、可观测性与治理四大平台支柱。 基础设施隔离：命名空间沙箱与网络策略 (1:38) Sawyer Bowerman 将人工智能智能体比作可能偶发不规则行为的儿童，强调模型即便能字面执行指令，最终产生的系统影响依然完全由企业承担。例如，一个被赋予数据库完全写入权限且负责清理历史记录的智能体，可能会直接清空指定日期之后的所有关键数据表，从而破坏核心业务价值。为避免不可逆的操作风险，平台必须在底层施加刚性约束。 红帽提出的隔离方案基于容器原生机制：一方面，利用命名空间隔离（Namespace Isolation）构建独立沙箱，确保智能体仅能在限定资源范围内运行，未经显式授权无法触及集群中的其他容器或核心组件；另一方面，借助细粒度的网络策略（Network Policies）严格控制出站与入站端口通信，防止智能体在宿主网络中进行横向侦查或发起未经许可的外部 API 调用，这在托管开源基础模型时至关重要。 身份安全：动态密钥注入与角色访问控制 (4:10) 在身份与凭据管理层面，Bowerman 警告称，本地原型开发中常见的明文环境变量或 .env 文件存储方式，在规模化生产部署中极易遭受提示词注入攻击与漏洞利用。保护智能体身份要求将敏感的 API 密钥与访问令牌从代码和静态配置中完全剥离。 该方案依赖企业级密钥管理工具与权限隔离：通过将 HashiCorp Vault 与 Kubernetes Secrets 深度集成，实现将凭证动态注入 OpenShift 和 Kubernetes 运行负载，并借助 Vault 的自动轮转功能定期刷新令牌，消除陈旧凭证可能带来的潜在攻击面。同时，架构强制推行基于角色的访问控制（RBAC），严格划分不同智能体的权限边界，例如将处理机密数据的内部数据分析智能体与面向外部公众的客服聊天机器人隔离，防止外部恶意提示词诱导客服模型跨租户窃取或泄露核心资产。 全链路可观测性：捕获黑盒推理与异常死循环 (7:55) 由于智能体的决策路径具备非确定性特征，其运行过程往往被视作黑盒。Bowerman 列举了一个真实故障场景：一个被指派将遗留代码重构为 Rust 的智能体意外陷入未受控的死循环，在短短几分钟内执行了超过 10,000 次外部 API 请求，迅速产生 500 美元的费用账单；若缺乏透明度，运维团队既无法得知智能体偏离预期的根因，也无法锁定引发异常的具体工具调用。 可观测性体系通过分布式追踪将不可预测的模型转化为受控实体。通过整合 OpenTelemetry、Jaeger 以及可运行于 Podman、Docker 或 OpenShift 内部的 MLflow，系统能够全程捕获智能体的出入站有效负载、工具调用链路和原始 JSON 响应。这不仅可严防私有数据或信用卡信息发生外泄，还能让工程师像审查代码合并请求（Pull Request）一样精确调试智能体的异常逻辑。 策略代码化治理：规避高额成本与引入人工审批 (10:36) 治理支柱的核心在于通过代码化策略（Policy as Code）建立静态底线与执行护栏，防止自主智能体为了修复问题而引发更大规模的事故。例如，当智能体监测到集群性能瓶颈时，可能会自主尝试将计算节点规模扩充十倍，进而给企业带来高达 50,000 美元的非预期云账单。 红帽的治理方案结合了程序化规则评估与多级审批门禁。当智能体规划执行某项操作时，策略引擎会首先评估该动作是否越过预设的成本上限或风险阈值。低风险常规操作可自动获准执行；而一旦涉及破坏性、高成本或敏感的系统变更，工作流将自动挂起，强制移交至人机协同（Human-in-the-Loop）或上级监管智能体关卡，必须获得授权人员的明确批准后才可落实至生产环境。 Bowerman 建议企业按照实施难度与收益顺序分阶段落地：首先在 OpenShift 或 Kubernetes 中利用 vLLM 或 llama.cpp 等运行时完成工作负载容器化与身份加固，随后接入 MLflow 和 OpenTelemetry 实现全链路可观测，最终建立策略代码与人工审批治理。目前红帽正通过与 NVIDIA 合作的 Red Hat AI Factory 方案整合这一架构，并持续推进 Open Shell 等开源 AI 安全项目。

## Background 本视频由 YouTube 频道 Ai4 于 2026 年 8 月 19 日发布，主讲人为红帽（Red Hat）的 AI 开发者倡导者 Sawyer Bowerman。视频简介指出，AI 智能体在测试阶段往往表现良好，但进入生产环境后容易出现不可预测的调用并破坏系统；演讲重点分享了隔离、身份、可观测性与治理这四大平台实践，展示如何通过底层基础设施而非单纯依赖提示词工程来规模化管控 AI。 ## TL;DR 演讲深入剖析了生产级 AI 智能体在脱离有效管控时可能引发的系统瘫痪与高昂财务风险，明确指出仅靠提示词工程无法构筑真正的安全防线。为此，主讲人系统阐述了保障智能体安全的四大平台支柱：基于命名空间与网络策略的隔离性、基于 RBAC 与密钥生命周期的身份管理、借助链路追踪实现的全流程可观测性，以及融入“人/智能体在环”与策略即代码的系统治理。最后，演讲梳理了企业从沙箱容器隔离、可观测洞察到策略治理的分阶段落地路线，并介绍了红帽携手 NVIDIA 打造的企业级 Red Hat AI Factory 实践方案。 ## Atmosphere & style 演讲风格生动风趣且极具工程师现场感，主讲人将捉摸不透的智能体戏称为“小孩”，并用“自作主张扩容十倍导致数万美元账单”等惨痛反面教材活跃气氛，迅速引发技术受众的强烈共鸣。叙事节奏明快务实，既有对大模型黑盒失控的幽默调侃，又有深入云原生网络与权限架构的硬核拆解。整场分享仿佛一位经验丰富的前线架构师在倾囊相授踩坑排雷指南，让听众在轻松专注的氛围中领会到平台工程对于可信 AI 的兜底价值。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=4s) 单纯依赖提示词工程（Prompt Engineering）无法满足生产级 AI Agent 的安全要求，必须从底层平台和基础设施维度进行管控。 - [00:04](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=4s) Red Hat 提出生产级 AI Agent 安全四大支柱：隔离性（Isolation）、身份认证（Identity）、可观测性（Observability）与治理（Governance）。 - [01:38](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=98s) AI Agent 的行为极具不可预测性且最终责任在人类开发者，必须在容器沙箱与网络层面设防，防止误删数据库等灾难性后果。 - [01:38](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=98s) 通过 Kubernetes/OpenShift 命名空间沙箱与网络策略（Network Policies）实施出入站流量白名单，杜绝 Agent 的内部网络侦察与异常外联。 - [04:10](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=250s) 生产环境严禁将 API Key 等凭据明文存储，需集成 HashiCorp Vault 与 K8s Secrets 实施密钥自动轮转与 Token 刷新以杜绝僵尸权限。 - [04:10](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=250s) 采用细粒度 RBAC 权限隔离内部数据分析与外部公开客服等不同角色 Agent，防范 Prompt 注入攻击导致的专有数据外溢。 - [07:55](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=475s) 借助 MLflow、OpenTelemetry 与 Jaeger 捕获 Agent 完整推理链路与工具调用参数，将不可预测的黑盒调用转化为可追溯、可调试的系统。 - [10:36](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=636s) 必须为 Agent 自主修复与资源调度设定硬性策略边界，防范因错误判断导致底层基础设施崩溃或节点失控扩容。 - [11:30](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=690s) 推行“策略即代码”并引入“人在环/智能体在环（HITL）”审批流，高危及高昂操作必须经人工或辅助监管 Agent 审批方可执行。 - [14:34](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=874s) 企业安全落地应分阶段演进：从低门槛高收益的容器沙箱隔离与身份管控起步，进阶至链路可观测性，最终筑牢策略治理防线。 - [16:14](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=974s) Red Hat 携手 NVIDIA 打造 Red Hat AI Factory 方案，结合企业级 Linux 安全积淀与上游开源项目（如 Open Shell）共建可信 AI 生态。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=4s) 生产级 AI Agent 的安全挑战与四大支柱 演讲者 Sawyer Bowerman（Red Hat 的 Developer Advocate 及 Technical Marketing Engineer）以轻松幽默的互动开场，询问在场听众日常使用 AI、Agent 以及在安全环境中运行 AI 的情况。他强调，在如今的生产环境中，“单纯依靠 Prompt Engineering（提示词工程）已经不足以应对生产级用例的安全性与稳定性要求”。 为了在 Kubernetes 或 OpenShift 等容器编排平台上安全可靠地运行 AI Agent，Red Hat 提出了 AI Agent 安全的四大支柱（Four Pillars of AI Agent Safety）： 1. **隔离性（Isolation）** 2. **身份认证与权限（Identity）** 3. **可观测性（Observability）** 4. **治理（Governance）** ```mermaid flowchart TD accTitle: AI Agent 安全四大支柱 subgraph Pillars["AI Agent 安全四大支柱 (Platform Best Practices)"] P1["1. 隔离性<br/>(Isolation)"] P2["2. 身份与凭证<br/>(Identity)"] P3["3. 可观测性<br/>(Observability)"] P4["4. 治理与规范<br/>(Governance)"] end P1 --> Goal["构建可信、安全且受控的生产级 AI Agent"] P2 --> Goal P3 --> Goal P4 --> Goal ``` --- ### [01:38](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=98s) 第一支柱：隔离性（Isolation）与网络管控 Sawyer 将当下的 AI Agent 比作“小孩”——你给它下达一条指令，它可能会听，但也经常表现得捉摸不定，甚至说出或做出完全出乎预料的事情。但无论如何，“Agent 所采取的行动，最终责任都在人类开发者身上”。 一个典型的反面案例是：如果你赋予 Agent 对整个数据库的写入权限，并要求它“清理旧数据”，它可能会直接把某个时间点之前的所有数据表全部删除。虽然从字面上看它确实完成了清理任务，但这会直接导致股东价值流失，引发灾难性后果。为了防止这种越权破坏，平台层需要引入两层隔离控制： - **命名空间隔离（Namespace Isolation）**：在 Kubernetes / OpenShift 中，将 Agent 部署在独立的 Namespace 中作为基础沙箱环境，严格限制其资源配额与操作范围，避免其触碰未授权的系统组件。 - **网络策略（Network Policies）**：通过网络策略精准控制 Agent 的入站（Ingress）与出站（Egress）流量，仅开放指定端口。在多 Agent 协作或 RAG（检索增强生成）场景下，该机制能有效杜绝 Agent 进行内部网络侦察（Internal Recon）或向未知外部地址发起异常调用，尤其是在运行开源大模型时保障环境封闭安全。 --- ### [04:10](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=250s) 第二支柱：身份认证（Identity）与 RBAC 权限控制 身份管理的核心在于保护 API Key、Token 等敏感凭证，防止其泄露。在本地开发时，把凭证写在环境变量或 `.env` 文件中或许可行，但在生产环境规模化部署时，面对新型 Prompt 注入攻击与各类 AI 漏洞探测工具，凭证泄露将带来极其昂贵的财务与数据损失。 在 Kubernetes 体系中，合理的身份与凭据治理包括： - **密钥管理与自动轮转**：使用 Kubernetes Secrets 以及集成 HashiCorp Vault 等专业密钥管理工具，实现凭证的安全注入、定期轮转（Key Cycling）与 Token 刷新，避免长期有效的僵尸权限（Stale Access）。 - **基于角色的访问控制（RBAC）**：为不同用途的 Agent 明确划分角色。例如，负责处理内部敏感客户数据分析的 Agent 与面向外部用户的客服 Chatbot 必须在权限上严格隔离，防止客服机器人发生越权，将专有数据或其他客户的隐私信息泄露给外部用户（就像有人试图诱导餐馆客服 AI 去做快速排序算法一样，严防专有数据外溢）。 ```mermaid flowchart LR accTitle: 身份认证与权限控制流程 subgraph SecretMgmt["凭据生命周期管理"] Vault["HashiCorp Vault / K8s Secrets"] --> Cycle["自动密钥轮转与 Token 刷新"] end subgraph AccessControl["RBAC 隔离"] InternalAgent["内部数据分析 Agent<br/>(高权限/内网)"] PublicAgent["客服 Chatbot Agent<br/>(只读/严格受限)"] end SecretMgmt --> AccessControl ``` --- ### [07:55](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=475s) 第三支柱：可观测性（Observability）与调用链追踪 Agent 的工作流本质上是一个黑盒。Sawyer 举了一个生动的场景：你让 Agent 去重构一段旧代码（或者像现在很多人做的那样，尝试将其改写移植为 Rust），结果它背地里疯狂发起了 10,000 次 API 调用，账单瞬间刷掉 500 美元，而你完全不知道它在干什么、为什么这么做。“可观测性能够将一个‘非礼勿言/黑盒’的 Agent，转变成守规矩的好公民”。 通过全链路追踪（Tracing），团队可以捕获 Agent 的完整出入站行为： - Agent 调用的工具与外部 API 详情 - 工具返回的原始 JSON 数据（防止敏感数据或信用卡信息被悄悄发送到境外） - 支持的常用开源工具包括： - **MLflow**：轻量易用，支持 `pip install` 本地运行（通过 Podman/Docker），也可直接托管部署在 Kubernetes 或 OpenShift 上。 - **OpenTelemetry** 与 **Jaeger**：提供标准化的分布式链路追踪能力。 - 全面的可观测性让开发者能够像“调试实习生写的代码”一样，清晰排查和纠正 Agent 的异常行为。 --- ### [10:36](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=636s) 第四支柱：治理（Governance）与自主修复的边界 治理即为 Agent 设定硬性规则（Hard and fast rules）与运行边界，防止模型“自由放飞”造成破坏。有了治理规则，Agent 才能在承接复杂任务的同时，不至于给底层基础设施带来崩溃风险。 在生产环境中，当 Agent 检测到底层性能问题并尝试进行“自主修复（Autonomous Fix）”时，如果不加治理约束，往往会导致意想不到的后果（例如误判代码性能问题或盲目变更 Kubernetes 集群资源配置）。平台必须通过静态规则与策略介入，确保 Agent 的自动化修复动作始终在预设的安全阈值之内执行。 ### [11:30](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=690s) 治理与失控成本：引入“人/智能体在环”机制 如果缺乏平台级别的管控，AI 智能体在处理工作负载时极易做出不可预测且代价高昂的决策。例如，智能体在监测到请求量上升或系统变慢时，可能会自行判定当前运行在单节点上的工作负载无法满足需求，从而自作主张将集群节点“瞬间扩容 10 倍”。这种自动化决策看似积极，但伴随云端算力资源的激增，企业月末可能会突然收到一张高达 50,000 美元的云服务账单。演讲者调侃道：“智能体可不会替你付这笔钱——虽然它理论上可能会尝试，但千万别给它能刷你信用卡的工具。” 为了避免这种灾难，必须在架构中引入治理（Governance）机制，其中最为核心的就是“人/智能体在环”（Human-in-the-loop / Agent-in-the-loop）模式。治理的核心理念是将规则沉淀为“策略即代码”（Policy as Code），并在关键决策生效前进行自动化拦截与校验。当智能体产生一个操作意图时，系统会率先判断该操作是否具备“危害性”或“昂贵性”：如果属于低风险常规操作，系统直接放行执行；一旦判定为高风险或高成本操作，则必须将请求路由给人工审批者或专属治理智能体进行审批与拦截。 ```mermaid flowchart TD accTitle: 智能体治理与审批流 subgraph AgentLogic["智能体决策层"] A["智能体生成操作/决策"] --> B{"是否高危或昂贵？"} end subgraph Evaluation["策略与审批层"] B -- "否 (低风险)" --> C["直接执行代码/调用工具"] B -- "是 (高风险/高成本)" --> D["人工 / 辅助智能体审批"] D -- "批准" --> C D -- "拒绝" --> E["拦截并终止操作"] end ``` - **意外扩容陷阱**：单节点任务被智能体误判后扩容 10 倍，可导致数万美元的非预期账单。 - **策略即代码（Policy as Code）**：通过前置规则自动评估操作的危险度与成本阈值。 - **审批在环模式**：在最终推向生产环境前，为敏感指令引入人工（Human-in-the-loop）或辅助监管智能体（Agent-in-the-loop）的双重确认。 --- ### [13:29](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=809s) 打造坚不可摧的 AgentOps 统一防护架构 将隔离（Isolation）、身份（Identity）、可观测性（Observability）与治理（Governance）四项原则结合起来，能为企业级 AgentOps 提供一套“无懈可击（lock-tight）”的端到端防护网。这套体系的核心思路并非依赖提示词工程去祈祷大模型不犯错，而是从基础设施层面限制其作恶空间。 在完整的运行架构中，AI 智能体被严格封装在容器化环境中运行；在网络层面，系统对其出入站流量（Ingress/Egress）实施最小权限控制；在身份与凭据层面，敏感的 API Key、Token 以及各类环境变量均受到严格的加密与脱敏屏蔽；而在业务执行的最末端，则有治理策略作为兜底防线，对核心资源调用与高危变更执行严格的阻断或审批。 - **全流程容器隔离**：彻底封锁智能体直接触碰底层宿主机或未授权内网的能力。 - **网络与凭证管控**：严格限制出入站流量白名单，对敏感环境变量及 Token 全程脱敏。 - **全局安全兜底**：通过全方位监控智能体决策轨迹，确保系统可在安全合规的前提下高效扩展。 --- ### [14:34](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=874s) 落地演进路线：从隔离、可观测到策略治理 企业在构建安全智能体平台时，应当依据实施难度与价值回报（ROI）分阶段推进： 第一步是门槛最低且收益立竿见影的**隔离与身份（Isolation & Identity）**。开发者在使用 vLLM、llama.cpp 等推理引擎配合工具调用（Tool Calling）时，无需引入过多额外复杂度，只需顺手将智能体运行环境打包进容器中，就能实现“在破坏发生前将其扼杀在摇篮里（stop destruction before it starts）”。 第二步是**可观测性（Observability）**。当智能体被安全锁入容器沙箱后，平台需要获得深入箱体内部的可见性，实时追踪智能体的思维推理链（Reasoning Chain），在那些可能导致高额账单或系统崩溃的错误调用真正发生之前，透视其决策动机。 第三步也是最终的基石是**治理（Governance）**。虽然实施“策略即代码”并设置审批阈值相对前期步骤需要投入更多精力，但它是规模化安全落地的根本保障。开发者和技术决策者必须共同制定规则，清晰界定哪些操作属于高风险或高成本红线，并强制接入流程审批。 - **阶段一：沙箱隔离（低门槛/高防线）**：利用容器化快速限制执行边界，锁死凭证与权限。 - **阶段二：可观测洞察（深度透视）**：捕获智能体推理链与工具调用细节，及时发现异常逻辑。 - **阶段三：策略治理（安全扩展）**：自定义风险阈值，通过代码化策略与人工介入防范重大灾难。 --- ### [16:14](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=974s) 红帽与 NVIDIA 的企业级实践：Red Hat AI Factory 为了将这些最佳实践真正推向工业化落地，红帽（Red Hat）与 NVIDIA 展开深度合作，联合打造了 **Red Hat AI Factory** 解决方案。该方案将底层加速算力与上层全生命周期的平台安全管控机制融为一体，为企业提供了开箱即用的安全智能体运行架构。 红帽在开源社区上游持续发力，主导并参与了包括 Open Shell 在内的多项 AI 智能体安全开源项目。安全性一直是红帽的立足之本与名声所在（"where we got our claim to fame"），如今红帽正全力将这一传统企业级安全基因为 AI 时代赋能。演讲者最后邀请参会者前往会场展台深入交流，共同构建安全可控的企业级 AI 工作流。 - **Red Hat AI Factory**：红帽携手 NVIDIA 推出的全栈 AI 平台解决方案，兼顾算力加速与架构安全。 - **上游开源投入**：积极参与 Open Shell 等智能体安全开源生态建设，推动行业安全标准。 - **安全基因传承**：将企业级 Linux 与云原生领域的深厚安全积淀全面注入 AI Agent 生态。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=4s) 单纯依靠 Prompt Engineering（提示词工程）已经不足以应对生产级用例的安全性与稳定性要求 — Sawyer Bowerman > [01:38](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=98s) Agent 所采取的行动，最终责任都在人类开发者身上 — Sawyer Bowerman > [07:55](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=475s) 可观测性能够将一个‘非礼勿言/黑盒’的 Agent，转变成守规矩的好公民 — Sawyer Bowerman > [11:30](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=690s) 智能体可不会替你付这笔钱——虽然它理论上可能会尝试，但千万别给它能刷你信用卡的工具。 — Sawyer Bowerman > [14:34](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=874s) 在破坏发生前将其扼杀在摇篮里（stop destruction before it starts） — Sawyer Bowerman > [16:14](https://www.youtube.com/watch?v=Tu5-9fGz1nQ&t=974s) where we got our claim to fame — Sawyer Bowerman ## Mentioned Sawyer Bowerman, Red Hat, Kubernetes, OpenShift, HashiCorp Vault, MLflow, OpenTelemetry, Jaeger, Podman, Docker, vLLM, llama.cpp, NVIDIA, Red Hat AI Factory, Open Shell, Ai4 ## Video description Sawyer Bowerman - AI Developer Advocate, Red Hat Your AI agent works in testing. In production, it makes unpredictable calls and breaks things. Four platform practices make agents safe: isolation, Identity, Observability, and Governance. This talk shows how to add them, and why infrastructure, not just prompting, is how you control AI at scale. [Source](https://www.youtube.com/watch?v=Tu5-9fGz1nQ)

[0:04] Sawyer Bowerman: 单纯依靠 Prompt Engineering（提示词工程）已经不足以应对生产级用例的安全性与稳定性要求 [1:38] Sawyer Bowerman: Agent 所采取的行动，最终责任都在人类开发者身上 [7:55] Sawyer Bowerman: 可观测性能够将一个‘非礼勿言/黑盒’的 Agent，转变成守规矩的好公民 [11:30] Sawyer Bowerman: 智能体可不会替你付这笔钱——虽然它理论上可能会尝试，但千万别给它能刷你信用卡的工具。 [14:34] Sawyer Bowerman: 在破坏发生前将其扼杀在摇篮里（stop destruction before it starts） [16:14] Sawyer Bowerman: where we got our claim to fame

Sawyer Bowerman: Your AI agent works in testing. In production, it makes unpredictable calls and breaks things. Sawyer Bowerman: Four platform practices make agents safe: isolation, Identity, Observability, and Governance. Sawyer Bowerman: infrastructure, not just prompting, is how you control AI at scale. [0:04] Sawyer Bowerman: prompting is not enough for production use cases. [1:38] Sawyer Bowerman: you kind of give them a command and they might listen, they kind of act erratically at times... but at the end of the day, the actions that the agents take are ultimately your responsibility. [1:38] Sawyer Bowerman: Namespace Isolation: Serves as a baseline boundary. [7:55] Sawyer Bowerman: AI agent execution paths are inherently non-deterministic black boxes. [7:55] Sawyer Bowerman: good rule following citizen

[0:04] My name is Sawyer. I am a developer advocate and  technical marketing engineer at Red Hat, and I [0:09] wanted to just discuss a couple things regarding  AI agents. I know we just came off of another [0:14] panel, which was awesome. Um, yeah, I just kind of  wanted to talk about it in the general sense. So, [0:19] let's kind of speed through cuz we got  a few things we got to talk about. So, [0:23] firstly, you know, I should see a show of hands.  How many of you are using AI in your daily life? [0:27] Probably should be everyone. Awesome. Cool.  Uh, I would assume then also a lot of you are [0:35] using agents as well. There's surely there's more  than five people. Okay, thank you. Awesome. And [0:42] and then yeah, how many of you with show of  hands can spell AI? AI. Okay, I see I see two, [0:48] so that's we're that's better than last time.  Anyways, yeah, and how many of you are using [0:54] AI in a secured environment? Or are you just  kind of trusting it with your your computer, [0:59] with your root? Okay. Cool. I just wanted to kind  of highlight here before we go into too much that [1:05] nowadays in production, prompting is  not enough for production use cases. So, [1:12] yeah, let's talk about kind of what that means.  So, we have kind of split up the main key points [1:19] into four pillars as we like to call them. So,  we're just going to talk about the four pillars [1:23] of AI agent safety and how you can implement them  in Kubernetes or any other container orchestration [1:30] platform, namely for us, OpenShift. [snorts] So,  yeah. Um, let's start off with isolation. So, [1:38] it's not too far-fetched to think of your  agents as children nowadays. You know, [1:42] you kind of give them a command and they might  listen, they kind of act erratically at times, [1:47] or whatever, or say things that you could have  never predicted. But, at the end of the day, [1:52] the agents, the actions that the agents  take are ultimately your responsibility. [1:58] So, you know, if you give an agent right access  to your entire database and ask it to clean up [2:03] old data, it could delete, you know, all your all  your tables from, you know, a certain point uh [2:11] of dates, for example, and this uh is  obviously not what we want. Of course, [2:18] technically it's true, it's cleaning up uh old  data, but that's not what we're uh hoping for. [2:24] And uh as you can see, our shareholder value is  running away from us. Um so, yeah, try explaining [2:30] that you deleted all your shareholders' data. It's  not great. Um so, yeah, so we can do this through [2:37] a couple different techniques. So, namely, we  have uh namespace isolation. So, in any Kubernetes [2:43] platform, this uh applies, but for example, here  we're using OpenShift. Um so, you can actually [2:50] use uh a namespace as kind of like a base layer.  So, agents can exist in their own namespace, [2:55] um and and kind of exist in their own sandbox  environment without touching other things that [3:01] you don't want it to necessarily touch unless  given. So, I'll kind of go into that a little [3:06] bit more in depth in a couple more slides, but  the idea here is just giving the resources and [3:11] permissions needed to allow your agent to operate  in a functional way. [snorts] Um yeah, so this is [3:19] also great in case, you know, you're trying to  make some sort of rest uh API or some sort of [3:24] post request across multiple different containers  or namespaces, and uh you want to make sure that [3:30] they're not just uh pulling information out of,  you know, their back pocket. So, on top of that, [3:37] you can control who your agent can talk to, like  I said, with network policies, which allow ingress [3:42] and egress through uh only specified ports.  So, this is super useful if you have multiple [3:47] different uh agents, or if you're setting up some  sort of rag situation, and you need agents to [3:54] only uh uh talk and connect through those specific  ports. This is a great [snorts] way to prevent any [3:59] sort of internal recon or, you know, mystery  outbound calls, especially when you're running [4:04] these, you know, open-source models. You just  want to make sure you have stuff zipped up tight. [4:10] Um and then, yeah. So, that's kind of the  first pillar. The next pillar I want to [4:14] talk about is identity. So, identity is kind  of both managing and securing your identity. [4:22] So, that when I say identity, I'm referring to,  you know, your API keys, your tokens, any sort of [4:27] authentication method that you don't want just  sitting in some sort of environment variables [4:33] or environment file. So, it's really  easy to mess up agent deployment [4:38] in a lot of ways, but credentials  could potentially be the most costly. [4:42] If any of this information gets out or in some  way is, you know, picked up in a way that you [4:49] don't want it to be, this could be really bad. It  could be catastrophic or costly for your company. [4:55] Um or just personal use case as well. Um and so,  this is this is okay kind of locally, I suppose, [5:03] if you're putting, you know, your API keys into  an environment variable, but the second that [5:07] you're trying to scale any larger than that,  that's when you kind of want to be a bit more [5:10] mindful of where things are going, especially,  you know, with the onslaught of, you know, [5:15] all these new prompt engineering techniques and  all these new um AI vulnerability finding tools. [5:22] Um and kaboom. Yeah, so this is what happens when  it gets compromised. So, you know, you don't want [5:28] that to happen, obviously. Um touching more on  identity, there's something within Kubernetes [5:35] called a secret, and we're already  familiar with secrets in general, you know, [5:39] something that your friend tells you not to  tell your other friends, but you still tell them [5:43] anyway. Ideally, you wouldn't want to follow that  practice in uh production AI workloads as well. Um [5:50] but for example, uh there are a couple different  tools that allow you to do this in Kubernetes. [5:55] So, like we said, uh there are stuff like uh  you know, HashiCorp Vault, which allows you to [6:01] uh apply these directly into Kubernetes. Um and  you know, you can sync and secure them through uh [6:09] a a a a deployment um orchestrator like Kubernetes  or OpenShift. And the nice thing about HashiCorp [6:16] Vault is that it will also help you like  automatically cycle uh your keys and everything [6:20] like that, so you can keep on top and not have  any sort of stale access that you don't know [6:24] about. [snorts] It's also a really good idea to uh  have your tokens refreshed periodically on top of [6:30] that. So, of course, the cycling is nice, but also  just being aware of, you know, if you have some [6:36] API key that you feel like is getting stale or  you've had it for, you know, a month or something [6:40] like that, uh you might just want to uh refresh  that as well. And that's kind of that's kind of [6:46] the first thing that you can do to make sure that  none of your um keys are being leaked. [snorts] [6:52] Yeah. Uh so, continuing on with identity,  we have something called RBAC, which is a [6:57] an acronym for role-based access control. So,  the core of identity management kind of sits on [7:04] assigning identities in the first place  or, you know, roles to your agents. Um [7:09] and kind of allowing you to RBAC allows you to  do this in a way that's really uh convenient [7:15] when it's and not so difficult to uh set up. So,  if you have like some sort of internal uh secure [7:21] data analysis agent working on your uh customer  data, for example, I just have an example here. [7:26] Um and you have some sort of customer chatbot  using uh RBAC allows you to keep those apart, [7:32] so you don't accidentally uh have an agent give  a ton of information to a customer that you [7:39] don't want or or a customer information about a  different customer. Um kind of like how I'm sure a [7:45] lot of you have probably tried asking um Chipotle  AI to do like quick sort or something like that. [7:50] You don't want that to happen in a production  environment when you have proprietary data. [7:55] Um so now let's move on to the third pillar. So  this is um observability. This is where we're [8:01] getting kind of into the key portions and this is  this is not um I guess uh mutually exclusive for [8:10] um Kubernetes or even OpenShift in in that sense.  Uh this is just good for uh good practices when [8:17] you're using AI agents in general. But of course  I want to talk about how you can do this on a [8:22] platform like this. So let's just have let's  have a let's set a let's set the scene here. [8:27] So you have an agent uh you just told it to  fix I don't know some old code or you wanted to [8:33] do what everyone else is doing right now and port  it to Rust for some reason. It decided to then [8:39] uh make 10,000 API calls and just cost you like  500 bucks and you're like what the hell? That was [8:46] obviously not what I was hoping to do but it just  did it and you have no idea why. That's kind of [8:51] the the the pain point right there. You know, when  you're working uh with an agent workflow they're [8:57] kind of inherently a black box and being unable to  see what's going on can really uh bite you in the [9:05] um butts I guess you know in the long run. So  kind of I like to say observability turns like [9:13] a speak no evil agent into a good rule following  citizen. So that's something that you should [9:20] always kind of keep in mind even if it's just  in the general sense. But let's move on here. [9:26] So we can kind of harness observability through  a couple different tools namely you know tracing. [9:32] So uh you can collect and export your traces  so that ingress and egress from your agent to [9:38] tools it's calling or to the APIs it's accessing  or even to the JSON that the tools returning. So, [9:46] you know, just in case you want to make sure  that you're not accidentally sending, you know, [9:50] your credit card information halfway across the  world or something like that. So, a couple tools [9:55] that actually allow you to harness this are ML  flow, which is really great and convenient. It's [10:01] open source tool. It's just a like one pip  install and you can run it locally on your [10:07] on server using like podman or docker, but you can  also host it in Kubernetes or open shift as well. [10:13] And then we have Jaeger and open  telemetry as well that are both tools for, [10:18] you know, this observability convenience.  [snorts] So, kind of having full observability [10:24] allows you to debug an agent's behavior just  like you would like debug your intern's code. [10:30] And that's kind of a really nice feature. And  then yeah, let's talk about the last pillar. [10:36] Shout out to Gemini for this amazing the very very  human-made diagram here, but I want to talk about [10:43] governance. So, governance is the act of setting  static rules or guidelines for an agent like [10:49] essentially hard and fast rules that keep the  robot in check. Um you know, with government [10:55] agents with governance agents allow are able to  work through like more difficult tasks without [11:03] without you having the fear that they're  going to blow something up, which is cool. [11:08] So, let's just look at this diagram here. So,  this is this is the problem we have with letting [11:11] models run free according to this duty here. So,  we have this autonomous fix. So, an agent detects [11:17] performance issue and and in in a production kind  of environment that could mean a couple different [11:25] things. That could mean that, you know, your code  is poorly optimized, but also in Kubernetes that [11:30] could mean that uh agent is interpreting it that  they're getting a ton more requests and they need [11:35] to scale up nodes or something like that. So,  all of the sudden, you were using, you know, [11:39] one node for your workload and then all and then  uh the agent is like, "Oh, well, that's too slow [11:46] for our workload. Let's scale it up by 10 times  or something like that." Um that's great, but at [11:52] the same time, now, since cloud costs are getting  pretty expensive and everything, uh you have to [11:58] pay a $50,000 bill to someone and uh that's not  fun. The agent isn't going to pay it for you. [12:05] It might, but I wouldn't recommend that. Um don't  give it tools to spend money on your uh card. [12:11] Anyways, then there's a solution here. So, a lot  of you are probably familiar with the human in the [12:15] loop uh concept. This is kind of what I want to  uh highlight here. Um having a human in the loop, [12:21] and of course, there's also the agent in the loop,  which is becoming more uh popular of a technique [12:25] as well, but for now, just uh having something  additional in the loop to approve or deny uh [12:31] specific uh decisions before they get pushed into  prod is always uh a good practice. Um so, here's [12:39] this amazing uh diagram. This one you can tell is  human generated or human created. I shouldn't even [12:44] say generated, but effectively, this is the order  of operations for governance. So, governance uh is [12:51] policy as code, like we said, and enforces rules  automatically. So, let's say our agent has uh a [12:57] thought here. It wants to make a decision. First,  we should check, is that harmful or expensive? [13:03] If it's uh not, and you can't really see the  no, but there's a no there, um then yeah, [13:09] it executes the code and we're all fine and dandy,  we move on to the next uh decision. If it is, [13:15] we need some guy or some other agent to approve or  deny this request. So, that is just the whole uh [13:23] process, the whole pipeline here. And um I'm sure  that's pretty self-explanatory, but Uh, and yeah, [13:29] just another highlight here. So, combining  and shout out to Gemini for half, 2/3 I guess [13:35] this time. So, combining all these philosophies  provides the user with like a lock-tight solution [13:40] uh, to agent ops and kind of mitigates concerns,  allows you to monitor uh, your agent's decisions [13:48] and um, and scale effectively. So, this is  this this uh, diagram here is kind of the whole [13:55] uh, philosophy uh, put into one image. So,  that's just running your agent in a containerized [14:02] uh, environment, um, only giving it access  to what it needs for ingress egress. Um, [14:08] you know, making sure you're checking policies  and uh, blocking out secure uh, secure [14:15] uh, keys, um, tokens, all that kind of stuff.  All your environment uh, variables and whatnot. [14:21] And then um, governance at the end. So, having  a human in the loop to approve or deny these uh, [14:27] these claims. So, where where can you go from  here? Um, there's a couple There's a couple [14:34] ways to go, but I want to highlight like the the  highest value first cuz realistically we're trying [14:40] to just get the most out of what we can out of  this. So, right off the bat, the lowest barrier of [14:45] entry is isolation. Uh, identity as well. So, um,  you know, making sure that you containerize your [14:54] agents um, doesn't take anything more to to  to set up than if you were to just, you know, [14:59] use uh, vllm or llama.cpp and set up tool calling  like that. Just run it in a container as well. Um, [15:06] stop destruction before it starts if by  utilizing containerization. Uh, secondly, [15:13] uh, you can kind of go to the observability side.  So, once you have your agent uh, kind of locked [15:18] in a box, you can um, look at what it's actually  doing inside that box. So, once like we said, once [15:26] contained gain visibility. So, you can observe  the reasoning chain to understand why an agent [15:31] is making calls before they cost you a fortune  and um you know, hopefully be all good to go. [15:37] Uh and then uh governance as the final step. So,  that's the final pillar for uh scaling safely. [15:43] That's uh of course a little bit more work than  the prior two, but of at the end of the day, [15:48] it's still really useful. Uh and that's enforcing  policy as code. Um you know, keeping a human in [15:54] the loop for high-risk actions uh or expensive  actions as well. And you as a developer or a um [16:02] a decision-maker needs to determine what  that threshold is for those actions. So, [16:08] uh that's kind of the step-by-step to go  through if you want to kind of tackle stuff. [16:14] And then, yeah, so you can kind of do all this  stuff with uh Red Hat AI Factory with NVIDIA. So, [16:22] NVIDIA and I and Red Hat have kind of paired it  to make a overarching solution for such a thing. [16:29] So, I figured you you should all know. We actually  have an implementation of this in collaboration. [16:34] Um and you can feel free to feel free to stop by  the booth after the fact. We're right by the front [16:39] door and chat more about this cuz it's kind of  in-depth, but Red Hat is working upstream on all [16:45] these open-source projects uh for agent security  like Open Shell and a lot of others as well. [16:50] And security is a huge part of our model. That's  kind of where we got our claim to fame. So, [16:55] of course, we want to try and employ that in the  AI space as well. So, uh definitely take a look [17:03] um Red Hat AI Factory. And yeah, come by  the booth after the fact. So, I just want [17:08] to say thank you guys so much for listening  and uh have fun making your workflows safe.