Tenable AI Security 纳入 Tenable One，但可见性不等于控制力

尽管企业面临的问题复杂得多，Tenable AI security 已从 2025 年的私有预览阶段进入 Tenable One 的正式可用功能。发现 AI 应用只是第一步。安全团队还必须在暴露演变为事件之前，将用户、数据、基础设施、智能体和不安全行为关联起来。

这一变化使 Tenable 加入了围绕企业 AI 控制层日益扩大的竞争。Palo Alto Networks、Microsoft、Cisco 以及新兴 AI 安全厂商正在争夺重叠领域。各方都希望帮助企业发现 AI 系统、评估其风险，并在日常使用中实施策略。

Tenable 的论点有一个重要不同之处。它将 AI 视为暴露管理中另一个相互关联的攻击面，而不是一项独立的安全计划。这种方法能提供有用的上下文，但也带来了一项严苛考验：Tenable 必须证明统一可见性能带来更快速、可执行的风险降低。

Tenable One 现已覆盖 AI 攻击面

关键变化不在于新增一个 AI 仪表板。Tenable 已将 AI 发现、使用治理和保护纳入其更广泛的暴露管理模型。

Tenable 于 2025 年 8 月 6 日在 Black Hat USA 首次推出 Tenable AI Exposure。该产品面向 ChatGPT Enterprise 和 Microsoft Copilot 等企业平台。它当时进入私有客户预览阶段，并计划在当年年底前正式发布。

该公告中描述的产品可识别用户、交换的数据、风险配置、第三方集成、提示词注入和越狱尝试。提示词注入是一种通过精心构造的指令操纵 AI 模型的攻击。越狱尝试则旨在绕过限制模型行为的安全防护。

Tenable 还表示，该功能采用无代理模式。在此场景中，无代理部署意味着客户无需在每台员工设备上安装监控软件。该平台转而依赖集成，以及受支持系统提供的可用遥测数据。

这种设计可以减少部署阻力，但覆盖范围仍取决于这些集成能够暴露哪些信息。无代理连接无法自动观察每个未受管理的个人账户、本地模型或未注册应用。

最初的 AI security launch 强调要超越简单发现。Tenable 希望将可见性与风险管理和策略执行结合起来。公司将其定位为 Tenable One 的延伸，而非一个割裂的产品类别。

2026 年 1 月 27 日，Tenable 宣布 Tenable One AI Exposure 正式可用。扩展后的版本覆盖软件即服务应用、云服务、API、智能体、本地系统和云环境中的 AI。

这一更广的范围十分重要，因为企业 AI 很少只存在于一个获批准的助手之中。一家公司可能使用 ChatGPT Enterprise 进行研究、使用 Microsoft Copilot 完成办公工作，并在面向客户的应用中部署定制模型。开发团队还可能将智能体连接到数据库、代码仓库或内部 API。

Tenable 表示，该平台会持续发现这些组件并映射它们之间的关系。它可以将 AI 使用情况与身份、应用、基础设施和数据关联起来。其目标是形成一种具备风险意识的视图，展示一个弱点如何与另一个弱点相互叠加。

以一个能够访问客户记录的内部支持智能体为例。其模型可能配置正确，但背后的服务账户却拥有过多数据库权限。传统的 AI 资产清单可能会将该智能体标记为已获批准。暴露映射则应揭示其周围存在危险的身份与数据访问路径。

Tenable 的 general availability release 将这种关系映射作为核心承诺。它还将产品范围扩展到预览期间重点提及的企业助手之外。

时间线很重要。这并不是一款在 2026 年 8 月首次发布的产品，尽管新闻流中重新浮现的标题可能会造成这种印象。最初的公告发生在 2025 年 8 月，随后于 2026 年 1 月正式发布。

这一区别改变了买方评估该新闻的方式。相关问题不再是 Tenable 是否已宣布 AI 安全方向。买方现在可以考察其生产环境覆盖范围、集成、工作流和执行边界究竟如何。

为什么 Tenable AI Security 让独立工具承压

Tenable 押注买方更青睐一个暴露关系图谱，而不是另一个孤立控制台，尤其是在 AI 风险源于模型本身之外时。

企业安全团队已经在管理漏洞扫描器、云安全产品、身份系统、终端控制、数据丢失防护工具和应用测试平台。一款专门的 AI 安全产品会新增一个发现结果来源，却不会自动增加一个负责调查这些结果的团队。

Tenable 的策略给那些主要将 AI 安全视为应用发现或运行时过滤的厂商带来压力。这些功能仍然重要。然而，安全团队若不了解某个暴露智能体的权限、可达资产、数据访问权和业务角色，就无法有效确定其优先级。

这正是在 Tenable One 中管理 AI 暴露的核心优势。一项发现可以继承周围环境的上下文。当薄弱配置位于可从互联网访问且具有敏感访问权限的服务上时，其紧迫性就会提高。

同样的逻辑也适用于普通员工使用。向获批准的助手上传文档，并非在所有情况下都具有同等风险。相关问题包括文档敏感性、用户身份、组织策略以及平台的数据处理控制措施。

Tenable 表示，其平台可以监控使用模式、交换的数据、助手行为和已连接的工作流。它还声称支持可接受使用策略，用于定义组织内允许和禁止的 AI 活动。

这些功能应对了一个真实的责任归属问题。AI 部署通常由业务部门、开发者或产品团队发起。安全人员往往在权限、集成和数据流已经存在后才发现它们。

资产清单可以帮助安全团队发现这些部署。关系图谱可以显示哪些系统最为关键。随后，策略执行可以限制行为，前提是平台既拥有足够的遥测数据，也拥有可用的控制点。

最后一个条件将暴露管理与纯粹报告区分开来。一款产品可以识别风险配置，却未必能够更改它；可以标记可疑的提示词活动，却未必能够阻止请求。买方需要区分检测、建议的修复、自动化变更和实时执行。

Tenable 的方法也给拥有庞大安装基础的既有平台带来压力。Palo Alto Networks 已在 Prisma AIRS 中整合发现、模型扫描、态势管理、红队测试和运行时保护。其当前产品强调覆盖开发和生产全流程中的应用与自主智能体。

因此，Prisma AIRS platform 对 Tenable 的挑战在于范围，而不只是品牌知名度。Palo Alto Networks 可以将 AI 控制与网络和云端执行关联起来。Tenable 则可以将 AI 发现与其漏洞和暴露情报关联起来。

Microsoft 处于另一种战略位置，因为 Copilot、Azure、身份、终端和数据治理产品已经产生相关遥测数据。Cisco 同样已将 AI 安全与网络和应用基础设施相连接。

这张竞争版图并不会产生一个简单的赢家。它将采购问题从功能数量转向架构适配度。客户必须判断哪一平台能看见其环境中的足够范围，并控制真正关键的节点。

已经使用 Tenable One 的组织拥有一个显而易见的运营理由来进行整合。其团队可以在云、身份、运营技术和漏洞暴露旁审查 AI 发现结果，也可能保留现有的优先级排序和修复流程。

以其他安全平台为核心的客户将需要更有力的证明。统一的 Tenable 图谱只有在获得足够数据并契合现有工作流时才有帮助。否则，它可能会成为本已拥挤的技术栈中又一个不完整的视图。

因此，压力最大的是独立发现产品。单纯识别正在成为更广泛安全平台中的一项功能。专业厂商必须通过更深入的测试、模型分析、数据控制或运行时干预来实现差异化。

真正的竞争在于上下文与执行能力

Tenable 的机制之所以引人注目，是因为 AI 失败会跨越系统边界；但上下文无法替代能够阻止危险行为的控制措施。

Tenable 将这一问题称为“AI Exposure Gap”。该术语描述了 AI 应用日益普及与安全团队看清相关系统、身份、数据和行为的能力之间的差距。

这一概念符合许多事件的发展方式。AI 应用不需要出现新颖的模型漏洞就可能造成危害。过度权限、暴露的云服务、薄弱认证、不安全的集成或处理不当的数据，都可能提供一条更简单的路径。

这正是暴露管理模型合理的原因。它寻找的是弱点组合，而不是孤立地看待每条告警。理论上，Tenable 可以根据周围攻击路径和潜在业务影响，为 AI 问题排序。

攻击路径是使攻击者能够向高价值目标移动的一系列相互连接的条件。一个权限过高的智能体身份可能成为这类链条中的一个步骤。公共端点或被攻陷的用户账户可能提供入口。

AI 智能体提高了风险，因为它们可以采取行动，而不只是生成文本。智能体可能检索文档、修改记录、调用外部服务或触发内部工作流。其实际风险既取决于模型行为，也取决于被授予的权限。

Tenable 表示，AI Exposure 可以识别高风险集成、错误配置、数据交换和操纵尝试。它还表示，平台可以遏制高风险或已被攻陷的智能体。这些说法值得在产品测试中进行精确评估。

买方应询问遏制发生在哪里。Tenable 可能通过集成禁用某项配置、调用另一项安全控制，或向介入的操作人员发出告警。每种方式在速度、可靠性和覆盖范围上都不同。

他们还应询问系统如何区分合法实验与策略违规。在获授权环境中测试提示词注入的开发者，可能与攻击者表现相似。上下文有所帮助，但自动分类仍可能产生误报。

平台的 AI Exposure documentation 为客户了解受支持功能和版本提供了起点。当团队规划运营控制时，文档比宽泛的发布措辞更为重要。

技术问题并不止于可见提示词。间接提示词注入可能通过 AI 应用处理的文档、网站、电子邮件或数据库记录进入系统。攻击者的指令会成为模型上下文的一部分，却不会以直接用户请求的形式出现。

OWASP 指南将提示词注入列为大语言模型应用的主要风险之一。指南还指出，检索和模型定制并不能彻底消除这一问题。这意味着，单靠暴露关系图无法消除底层模型行为带来的风险。

Tenable 仍可降低其周边影响。权限被严格限制的智能体，风险小于拥有广泛访问权限的智能体。监控数据流和集成设置，也可以揭示使操纵行为更加危险的条件。

这构成了本文的核心权衡。Tenable 能够提供跨环境的广泛覆盖，而专业控制措施可以更贴近模型或运行时交易。企业买家通常两者都需要：既要上下文，也要干预能力。

广泛的平台可能识别出：某个智能体通过权限过大的身份访问敏感数据库。运行时安全层则可能检查请求并阻止恶意指令。身份系统可以撤销访问权限，而数据控制措施则可以防止信息泄露。

最强的实施方案会将这些决策连接起来。最弱的方案则只会产生多个告警，却没有协调一致的响应。Tenable 的成败将取决于 Tenable One 能否成为这一连接层，还是主要停留在分析视图层面。

这也是为什么“单一平台”不应毫无保留地等同于“单一事实来源”。AI 系统横跨云服务商、模型供应商、开发者平台、生产力套件和内部应用。没有任何一家供应商拥有所有相关信号或执行点。

Tenable 已通过集成及其更广泛的暴露数据战略承认了这种分布式现实。它的任务是在标准化这些信号的同时，不抹去关键细节。高层风险评分必须能够追溯到支撑它的证据。

安全团队应坚持这种可追溯性。分析人员需要了解平台为何将某一 AI 暴露风险排在另一项之前。他们还需要知道，哪些资产、身份、权限和数据关系促成了这一结果。

没有可解释的证据，优先级排序就会成为另一项不透明的建议。有证据却没有行动路径，它也只是更好的报告。真正有价值的中间地带，是连接上下文、责任归属、修复与验证。

Tenable 的主张仍未证明什么

正式发布证明了产品已具备上市条件，并不代表其在所有企业 AI 环境中拥有完整可见性、准确的优先级排序，或经过验证的防护能力。

Tenable 的公告描述了广泛的功能。它们并未公布关于发现覆盖率、检测准确率、误报率、修复时间或拦截攻击的独立测量数据。

这种缺失在安全产品发布中很常见。但它仍限制了买家能够得出的结论。支持功能的清单并不能证明这些功能在不同架构下都能稳定发挥作用。

发现能力是首个不确定因素。获批准的企业平台通常提供管理 API 和审计记录。未经管理的消费者工具、浏览器扩展、嵌入式助手、本地模型和自定义网关则可能更难观察。

网络遥测可以揭示与已知服务的连接，但加密流量限制了内容检查。端点控制可以看到本地活动，但需要部署和权限。云连接器可以提供配置数据，不过它们依赖受支持的服务和账户访问权限。

Tenable 的无代理方法降低了安装要求，但并未消除这些可见性边界。买家在接受持续发现的主张前，应将每个 AI 使用场景映射到具体数据源。

第二个不确定因素是数据解读。平台可能检测到用户上传了文件，却不了解文件的敏感程度。它可能识别出某项 AI 集成，却不知道该工作流是实验性的、对生产至关重要，还是已被弃用。

准确的上下文需要身份记录、数据分类、资产所有权、应用元数据和业务优先级。这些来源在 AI 安全项目启动前往往并不完整。

第三个不确定因素涉及提示词级别检查。监控提示词可能会将敏感的员工或客户信息暴露给另一个系统。组织需要为安全遥测数据本身制定明确的保留、访问、脱敏、驻留和审计政策。

这带来了艰难的平衡。更高的内容可见性可以改善对不安全共享和操纵行为的检测，但也可能增加安全平台收集的敏感材料数量。

第四个不确定因素是执行能力。Tenable 表示，AI Exposure 可以阻止 AI 特定攻击并遏制高风险智能体。客户应验证哪些受支持平台允许实时拦截，哪些仅提供检测或建议操作。

延迟同样重要。依赖计划同步后更新的控制措施，无法阻止智能体即时发起的工具调用。它仍可支持调查和修复，但那是不同的安全结果。

第五个不确定因素是优先级排序质量。暴露管理依赖于将技术严重性与可达性及业务上下文相结合。AI 引入了传统漏洞评分并非为之设计的行为因素。

一个基础设施权限较低的智能体，仍可能影响高价值决策。没有系统访问权限的聊天机器人也可能泄露敏感文本。技术上暴露的模型可能只处理合成测试数据。

Tenable 必须考虑这些差异，同时避免将每项 AI 发现都变成严重告警。安全团队已经在应对过多的发现项。再增加一份缺乏严格排序的大型清单，只会加重这一负担。

行业指南可以帮助界定问题，但不能验证供应商的实施效果。NIST AI 框架围绕治理、映射、测量和管理 AI 来组织风险工作。其生成式 AI 概要增加了该技术的风险及建议行动。

这些职能与 Tenable 的叙事高度一致。不过，符合框架并不等同于认证产品有效性。组织仍需要测试、治理、事件流程和人为问责。

Tenable 最初的公告还重点提到了 ChatGPT Enterprise 和 Microsoft Copilot。当前产品则展示了对 AI 平台和智能体更广泛的覆盖。买家应确认具体受支持的服务、功能深度和区域可用性。

一个支持标签可能掩盖重大差异。某项集成可能暴露身份和配置，另一项则可能提供提示词活动和执行能力。采购团队应比较字段、操作、更新频率和故障行为。

安全负责人也应避免将购买平台视为 AI 治理的终点。产品负责人必须定义可接受的使用方式。法务和隐私团队必须设定数据要求。身份团队必须限制权限，开发者则必须设计更安全的智能体操作。

Tenable One 可以协调其中部分工作，但无法决定组织的风险容忍度。它也无法在部署后纠正每一种不安全的应用设计。

三个信号将显示该战略是否奏效

下一阶段应通过集成深度、经验证的风险降低和竞争响应来评判，而不是再看一份 AI 功能清单。

第一个信号是生产环境覆盖范围扩大。Tenable 应记录哪些 AI 平台、云服务、API 和智能体框架获得深度支持。重要细节不在于集成数量。

买家需要了解每个连接能够观察和更改什么。有价值的披露包括可用身份数据、配置覆盖范围、提示词可见性、策略操作、同步时机和修复选项。

更深的覆盖将强化 Tenable 统一暴露管理的论点。拥有很长但遥测浅薄的连接器清单则会削弱这一论点。安全团队应关注新增可执行操作的发行说明，而不仅是新增库存来源。

第二个信号是可衡量的运营改进。Tenable 应提供客户证据，证明 AI 上下文改变了优先级排序、缩短了调查时间，或防止了高风险行为。

最有价值的证据应比较部署前后的工作流。它可以展示一个结合身份、云和 AI 的暴露风险如何被排在影响较低的发现之前，也可以记录团队关闭该路径所需的时间。

独立测试比单独的客户引述更具分量。研究人员可以在可重复的场景中评估发现覆盖率、攻击检测、策略执行和误报情况。

强有力的结果应表明，Tenable 能发现孤立工具遗漏的重要暴露风险。它还应表明，分析人员能够理解发现结果，并在无需过多手动工作的情况下完成修复。

第三个信号是竞争性安全平台如何响应。Palo Alto Networks 已通过 Prisma AIRS 提供态势、模型、运行时、红队和智能体安全功能。其他供应商也可以将 AI 控制措施与身份、数据、端点、网络或云遥测连接起来。

如果竞争对手采用相同的以暴露为中心的语言，Tenable 的框架将获得验证。如果它们提供更强的执行能力，而 Tenable 仍专注于分析，市场可能会偏向更接近运行时控制的平台。

合作伙伴关系将塑造这一结果。没有任何暴露管理平台能够原生治理每一个模型、智能体框架、数据存储和业务应用。Tenable 需要可靠地访问第三方遥测和修复接口。

开放接口也能保护客户免受架构锁定。企业将使用多家模型供应商和开发技术栈，需要能够在这些底层服务变化后依然有效的安全策略。

对于安全负责人而言，眼下的行动是进行受控评估。选择几个真实 AI 工作流，包括获批准的助手、自定义应用和具有工具访问权限的智能体。记录每一项身份、数据源、权限和外部连接。

随后分别测试发现、上下文、检测、执行和修复。引入配置错误、过度权限、被禁止的数据传输以及受控的提示词注入场景。记录 Tenable 能观察到哪一步，以及它能够改变哪一步。

将隐私和治理团队纳入这项评估。提示词监控和活动收集可能产生自身的敏感记录。在大规模部署前，确认保留、访问控制、脱敏、审计和区域处理方式。

最后，将结果与云、身份、数据和生产力平台中已有的控制措施进行比较。整合只有在消除盲点或缩短响应时间时才会创造价值。单独新增一个仪表板，两者都做不到。

Tenable One 会成为连接企业 AI 与其他网络安全领域的风险层吗？其架构为此提供了一条可信路径。买家现在应要求看到证据，证明这条路径最终能实现可执行、可衡量的风险降低。