从资产发现到风险修复，企业如何建立AI攻击面管理闭环？

生成式AI正在进入企业的应用开发、客户服务、数据分析和日常业务流程。有的团队调用外部模型API（应用程序编程接口），有的在云上训练或部署模型，还有的开始让AI Agent连接代码库、数据库和业务系统并执行任务。

AI的普及并没有让传统网络安全问题消失。软件漏洞、云错误配置、互联网暴露资产、身份权限以及Web和API风险依然存在，只是它们可能与新增的AI应用、模型、数据和Agent形成新的连接关系。企业面对的问题因此不再只是“模型是否安全”，还包括AI部署在哪里、由谁管理、能够访问哪些资源，以及哪些风险组合最可能影响关键业务。

专注漏洞与暴露风险管理的网络安全公司 Tenable 指出，AI正在同时改变攻防两端：攻击者可以利用AI提高攻击效率，而企业自身不断增加的AI工具、Agent和云端AI工作负载，也需要被纳入现有网络安全治理体系。

因此，AI时代的安全重点并不是另建一套孤立的“AI安全体系”，而是把新增的AI风险与原有的云、身份、漏洞、Web和互联网攻击面统一管理。企业需要持续发现资产，关联漏洞、配置、权限、数据和攻击路径，再把有限的处置资源用于真正可能影响业务的暴露风险。

AI时代，企业的攻击暴露面新增了哪些资产和风险？

AI扩展了企业已有的攻击暴露面，而不是替代原有攻击面。AI应用、模型、Agent、训练和推理环境，以及支撑它们运行的云资源、身份权限和数据，都需要进入统一的资产与风险视角。

企业攻击暴露面包括哪些AI相关对象？

企业攻击暴露面并不只是服务器、终端和软件漏洞的集合，而是攻击者可能利用的资产、身份、权限、错误配置、网络入口及其连接关系。

AI进入业务环境后，企业至少需要关注以下新增或快速扩张的对象：

员工使用的公共生成式AI服务、AI办公工具和浏览器插件；
AI编程助手、AI原生集成开发环境以及开发团队引入的AI软件包和依赖库；
企业自建、微调或部署的模型，以及模型权重、训练数据和推理数据；
云上的AI服务、容器、对象存储、向量数据库和机器学习运维组件；
与AI应用连接的API、插件、连接器和模型上下文协议（Model Context Protocol，MCP）组件；
Agent使用的服务账户、API密钥、令牌、证书和其他非人类身份；
提示词、响应与运行日志，以及其中可能包含的源代码、客户信息和内部文档。

Tenable将应用、基础设施、身份、Agent和数据之间缺乏可见性与关联分析的情况概括为“AI暴露风险管理缺口”。问题不只是企业增加了多少AI工具，而是安全团队未必知道这些工具位于哪里、触达什么数据、拥有哪些权限，以及它们如何与原有环境连接。

为什么AI风险不能只看模型本身？

现实中的AI系统通常是一条由多个组件组成的业务链路。一个AI应用可能同时连接互联网入口、云工作负载、服务账户、企业数据库、用户身份系统和第三方组件。

单个问题未必代表最高风险。一个公开的推理API、一个存在漏洞的容器或一个权限偏大的服务账户，分别看可能只是普通告警；如果三者相互连接，并且能够访问敏感数据，就可能组成一条通向关键业务资产的攻击路径。

这也是暴露风险管理与单纯寻找“AI漏洞”的区别：前者不仅确认风险项是否存在，还要判断多个弱点能否被组合利用、攻击者能否沿着关系到达关键资产，以及优先修复哪一处最能降低业务风险。

企业如何发现未经管理的AI应用和互联网暴露资产？

AI时代的资产发现需要同时建立内部和外部两种视角。内部侧要发现未经批准的AI软件、组件和使用行为；外部侧则要从攻击者视角持续确认哪些域名、服务、云资源和AI相关系统能够被互联网访问。

Shadow AI为什么会成为新的资产盲区？

Shadow AI（影子AI）是指未经企业正式批准、未登记或缺乏统一治理的AI工具、服务和组件。它既可能来自员工主动使用，也可能随着开发工具、第三方库、浏览器插件和API悄然进入企业环境。

常见场景包括：员工使用公共生成式AI服务处理工作资料，开发人员自行安装AI编程插件，业务团队未经统一评估便接入第三方模型API，或者测试阶段的AI服务和管理界面在项目结束后仍留在互联网侧。

这类问题首先造成的是可见性缺口。如果安全团队不知道环境中存在哪些AI组件，就无法继续判断其软件漏洞、配置状态、数据访问范围和外部连接。

企业可以先通过资产清单回答五个问题：

当前正在使用哪些AI工具、模型和平台？
哪些已经批准，哪些属于Shadow AI？
哪些主机、应用或浏览器安装了AI软件和依赖组件？
哪些AI服务能够处理或访问敏感数据？
哪些Agent和机器身份拥有访问业务系统的权限？

Tenable提到，Security for AI的起点不是简单禁止员工使用AI，而是先建立可见性，再根据业务用途、数据类型和风险水平进行分类治理。在具体能力上，Tenable AI Aware可以识别AI软件、软件库和浏览器插件，并呈现相关漏洞；Tenable One AI Exposure则将AI使用、云基础设施和身份风险放入更广的暴露风险视角。

这些能力仍有明确边界。具体检测范围取决于软件指纹、平台支持、传感器、集成方式和部署环境，因此不应笼统声称任何产品能够读取所有AI交互，或覆盖所有国内外AI应用与Agent。

企业如何找到自己不知道的互联网暴露资产？

内部资产台账不一定等于企业真实的外部攻击面。在多域名、多云、业务并购、快速开发或海外业务扩张过程中，企业可能遗留测试系统、旧域名、云服务和其他面向互联网的资产。

外部攻击面管理（External Attack Surface Management，EASM）用于从攻击者视角持续发现这些公开可见的资产与变化。Tenable Attack Surface Management可以作为这类能力的例子：它从互联网侧识别域名、主机、服务和相关连接，帮助企业发现传统台账中没有记录的外部资产。

内部AI发现与EASM解决的是不同问题。前者关注企业环境中安装或使用了什么，后者关注互联网能够看到什么。两类信息需要汇入统一资产清单，并补充所有者、业务用途、数据类型、互联网可达性和计划下线时间，否则“发现更多资产”只会转化为更多无人认领的工单。

一家汽车制造企业如何从一次性盘点转向持续发现？

一家大型汽车制造企业在业务扩张过程中，内部资产和对外业务系统持续增加。由于缺少持续发现机制，部分未登记资产和历史遗留系统长期暴露在公网；与此同时，对外应用更新频繁，原有安全检测难以及时跟上开发节奏。安全团队虽然掌握了大量漏洞信息，却缺少一个能够统一判断内网、外部边界和Web应用风险的视角。

该企业通过Tenable Attack Surface Management从攻击者视角持续发现互联网上的未知资产，包括域名、子域名、云资源和对外服务；同时使用Tenable Web App Scanning对Web应用和API开展动态应用安全测试，并结合内部漏洞数据统一确定风险优先级。

在建立持续发现机制后，企业形成了动态更新的资产台账，能够更快识别未登记的公网资产和高风险端点，并将有限的处置资源优先投入可能影响关键业务的暴露路径。资产管理也由依赖人工盘点，逐步转向持续发现、风险排序和处置验证。

随着AI应用、推理API和测试服务不断进入企业环境，原有的未知资产和互联网暴露问题只会更加复杂。企业只有先持续掌握真实攻击面，才能进一步判断哪些AI相关资产需要被保留、限制或关闭。

AI工作负载运行在云上，会带来哪些配置、权限和数据风险？

云上AI的主要风险通常不是一种全新的漏洞，而是软件漏洞、错误配置、身份权限、敏感数据和网络可达性的重新组合。企业不能只检查模型文件，还要管理支撑训练、推理和Agent运行的整个云环境。

企业需要同时检查哪几类云上AI风险？

配置风险：公开对象存储、暴露的模型或推理端点，以及不安全的基础设施即代码模板；
权限风险：高权限角色、跨账户信任、长期凭证，以及没有落实最小权限的服务账户；
数据风险：训练数据、向量数据、模型权重，以及提示词和响应中的敏感信息；
应用与API风险：薄弱的身份验证、授权、输入验证、输出处理、传统Web漏洞和业务逻辑缺陷。

这些风险需要结合关系判断。例如，一个可从互联网访问的推理API连接了存在漏洞的容器，而容器使用能够读取敏感数据库的高权限服务账户，入口、漏洞、权限和数据便共同形成了更值得优先处理的暴露路径。

CNAPP为什么仍然是保护云上AI的基础？

云原生应用保护平台（Cloud-Native Application Protection Platform，CNAPP）用于整合云环境中的配置、工作负载、身份权限、漏洞和数据风险。AI训练、推理和Agent运行在云上之后，这些既有云安全能力仍然构成AI基础设施的安全基础：

云安全态势管理（Cloud Security Posture Management，CSPM）发现云资源错误配置；
云基础设施权限管理（Cloud Infrastructure Entitlement Management，CIEM）分析云身份和授权关系；
工作负载安全能力用于发现虚拟机、容器和软件组件中的漏洞；
数据安全能力用于识别敏感训练数据和业务数据；
AI安全态势管理（AI Security Posture Management，AI-SPM）进一步聚焦AI资源、配置、访问关系和相关数据风险。

在Tenable的云安全体系中，Tenable One Cloud Exposure中的AI-SPM用于发现多云环境中的AI资源和软件，分析配置、访问权限与相关数据，并支持最小权限治理。

AI-SPM并不等同于模型运行时防火墙，也不能代替所有应用、身份和数据安全控制。它解决的是云AI资源的可见性与安全态势问题，而不是承诺阻止所有模型攻击或审计第三方模型供应商的内部环境。

AI时代为什么仍要单独测试Web应用和API？

AI不会消除传统Web和API风险。面向用户的AI应用通常仍然包含Web前端、身份验证、API、第三方组件和后端服务，因此仍可能出现授权缺陷、注入问题、软件漏洞和不安全的业务逻辑。

Tenable One Web App Scanning使用DAST（Dynamic Application Security Testing，动态应用安全测试）测试正在运行的Web应用，并提供API扫描方式。它可用于企业拥有或获准测试的应用边界，但不应被表述为能够扫描任意第三方大模型供应商的内部系统。

AI Agent为什么也需要关注身份和访问权限？

Agent能够持有凭证、调用工具、访问数据并执行操作，因此应被视为NHI（Non-Human Identity，非人类身份）纳入身份治理。需要控制的不是它“像不像员工”，而是它可以使用什么身份、访问什么资源、执行什么动作。

Agent风险为什么不只是“回答错误”？

普通聊天机器人主要生成内容，Agent则可能连接工单系统、代码仓库、数据库、云控制台或业务API。它可能持有API密钥、访问令牌、云角色、数据库连接权限，以及软件即服务（Software as a Service，SaaS）系统和代码库的访问权限。

如果Agent凭证泄露、配置不当，或者攻击者通过提示词注入等方式影响其行为，风险可能从错误回答扩大为读取数据、修改配置或触发业务操作。Tenable也提醒到，分析Agent风险时不能只看提示词或模型，还要把Agent所使用的身份、凭证、权限和网络可达性纳入攻击路径。一个入口本身风险不高，并不意味着它无法借助高权限身份到达关键系统。

企业如何减少Agent的过度权限？

为每个Agent建立可追踪的独立身份，避免多个应用长期共享凭证；
落实最小权限，只授予完成当前任务所需的资源与操作；
优先使用短期凭证，并建立密钥、令牌和证书的生成、轮换与撤销机制；
对删除数据、修改生产配置和执行外部操作等高风险动作设置人工审批；
记录Agent调用的工具、访问对象、输入和操作结果，支持审计与追溯；
持续检查权限变化，及时回收闲置身份，并验证权限调整是否真正切断攻击路径。

在云环境中，Agent使用的服务账户和权限可通过CNAPP及CIEM能力进行分析；在Active Directory和Microsoft Entra ID等身份环境中，Tenable Identity Exposure可用于持续分析错误配置、权限关系和身份攻击路径。

具体Agent能否被直接识别，仍取决于它使用的身份系统、云平台、集成方式和部署架构。因此，身份可见性不能被写成单一产品能够自动治理所有Agent生命周期。

AI新增的云、身份、Web和漏洞风险，如何纳入持续暴露风险管理？

企业不需要不断增加彼此孤立的AI安全检查，而应把AI相关资产纳入CTEM（Continuous Threat Exposure Management，持续威胁暴露面管理）的范围界定、发现、优先级分析、验证和动员五个阶段，并通过循环执行持续缩小攻击面。

暴露风险管理与传统漏洞管理有什么区别？

传统漏洞管理主要从信息技术（IT）系统的软件漏洞、风险评分和补丁着手；暴露风险管理的范围更广，还要处理云错误配置、身份权限、互联网暴露资产、Web应用以及不同问题之间形成的攻击路径。

两者并不是替代关系。Tenable Vulnerability Management可以作为软件漏洞发现、评估和优先级管理的基础能力；暴露风险管理则进一步回答：这个漏洞是否位于互联网暴露资产上，能否连接高权限身份，攻击者是否可能利用它到达关键数据，以及修复它能否切断高影响路径。

Tenable关于CTEM的网络安全指南也将漏洞管理视为CTEM的重要基础，同时强调CTEM需要覆盖IT、云、运营技术、物联网和身份等攻击面，并结合关系与业务上下文确定优先级。

CTEM五个阶段如何应用到AI攻击面？

范围界定：明确哪些关键业务、AI应用、Agent、云环境、互联网资产、身份和数据需要优先纳入管理；
发现：持续识别Shadow AI、外部暴露资产、软件漏洞、云错误配置、身份权限及Web和API风险；
优先级分析：结合利用可能性、资产关键性、互联网可达性、身份关系、数据敏感性和业务影响确定处置顺序；
验证：确认暴露是否可以被实际利用、多个问题能否形成攻击路径，以及现有控制是否有效；
动员：将风险结论转化为具体任务，由安全、IT、云平台、应用开发和业务责任方协同处置，并在修复后重新验证。

完成一轮整改并不意味着流程结束。新的AI工具、代码、云资源和权限会持续进入环境，企业需要重新回到发现和评估阶段。CTEM因此不是一次性项目，也不是某个单一产品，而是一套需要人员、流程和技术共同参与的持续管理方法。

AI还能怎样加快从发现风险到实际修复？

Tenable谈到，Security for AI解决的是如何保护企业使用和开发的AI；AI for Security则可以帮助安全团队缩短查询、分析和跨团队协调所需的时间。AI的价值不应只是生成更多告警，而应帮助团队把暴露风险情报转化为可验证的后续行动。

例如，Tenable Hexa AI是Tenable One中的代理式AI引擎，它面向暴露风险管理，能够理解安全团队以自然语言提出的问题，并结合Tenable One中的资产、漏洞、身份、云和攻击路径等上下文，帮助用户调查风险、分析影响范围、确定处置优先级并生成后续行动建议。它的重点不是单纯生成安全摘要，而是将分散的风险信息转化为可执行的工作流。

这里的核心并不是让AI代替安全人员做所有决策，而是把大量重复操作自动化，并保留必要的人工控制，把更多时间留给风险判断和关键业务决策。