隐形 AI 正在超出企业网络资产清单的覆盖范围

KnowBe4 让一项长期存在的安全假设再次承受压力：获批的资产清单不再能证明每项活跃资产都已被识别。Google News 报道聚焦于 AI 服务、隐藏设备及其他可能被传统记录遗漏的资产。这种组合将管理层面的薄弱环节转化为现实的安全问题。

关键矛盾并不在于某一家安全供应商与另一家供应商之间，而在于静态记录与持续证据之间。采购数据库描述的是组织认为自己拥有的资产，而网络、终端、身份和浏览器遥测数据则揭示了人们实际在使用什么。

随着 AI 功能通过软件、浏览器扩展、应用程序编程接口和既有生产力套件不断扩散，这一缺口正在扩大。一项服务可能从未以单独采购的产品形式出现。它可能通过更新、个人账户、API 密钥或员工自有设备进入组织环境。

因此，KnowBe4 的观点超出了日常资产管理的范畴。安全团队如今必须在关注实体硬件的同时，发现软件行为、数据流动、身份以及外部服务；同时，也不能将每一条异常连接都视为恶意活动。

Google News 报道揭示了更广泛的资产清单失效问题

核心变化很简单：安全资产清单必须描述观测到的活动，而不只是获批的所有权。

Google News 报道 通过三类资产呈现了这一问题。AI 工具代表外部服务和嵌入式软件。隐藏设备代表绕过常规纳管流程的硬件。未知资产则涵盖所有在遥测数据中可见、却不在权威记录中的对象。

这些类别彼此重叠，却引出了不同的问题。一台个人笔记本电脑可能通过未受管浏览器访问获批的 AI 服务。一台获批笔记本电脑可能通过 API 使用未经批准的模型。一个已获准使用的生产力平台，可能在没有单独采购事件的情况下启用了新的 AI 功能。

传统资产清单可能记录了这台笔记本电脑和生产力套件，却遗漏了风险行为。它也可能记录某个 AI 供应商，却无法显示哪些员工在使用它。这两类记录都无法说明哪些数据跨越了边界。

这正是为何单靠设备清单无法支撑现代风险决策。安全团队需要一张关系图，将用户、终端、应用程序、身份、数据与目标地址连接起来。每一项观测都需要上下文，才能转化为可执行的行动。

问题也不限于生成式 AI。摄像头、打印机、实验室设备、楼宇控制系统、虚拟机、容器以及临时云资源，都可能逃避人工记录。有些缺少标准管理代理；另一些则短暂出现，又在下一次计划审查前消失。

NIST 在 CSF 2.0 中将这一更广泛的范围正式化。其资产管理成果涵盖硬件、软件、系统、服务、供应商、数据和网络流量。该框架还将识别视为持续的风险管理，而非每年一次的盘点工作。

这一差异很重要，因为未知并不等于敌对。新近发现的设备可能是尚待补充文档的获批替换设备。一个陌生域名可能属于已获批供应商的内容分发系统。某个与 AI 相关的终端可能支持员工从未主动启用的功能。

因此，发现机制应当为分类建立待办队列，而不是自动触发惩罚或隔离。团队需要足够的证据来确定所有者、用途、敏感性和业务重要性。

KnowBe4 的标题之所以有力，是因为它将这些情形浓缩为一个令人不安的问题：防御者能保护那些他们无法命名的资产吗？答案与其说取决于再购买一台扫描器，不如说取决于能否协调多个不完整的视图。

Shadow AI 从两个方向向安全团队施压

安全负责人既面临识别未经批准 AI 使用的压力，也必须避免阻碍有价值的工作或造成过度的员工监控。

Shadow AI 指在组织获批技术流程之外使用的 AI 服务或功能。该术语不仅涵盖员工访问公共聊天机器人，也包括个人 API 账户、编程助手、浏览器扩展、嵌入式功能以及运行在本地硬件上的模型。

每种路径留下的证据各不相同。浏览器访问可能出现在 Web 或域名日志中。API 活动可能出现在云端、代码仓库或密钥管理记录中。本地模型在其文件下载完成后，可能不再产生任何外部连接。

这种碎片化使安全团队夹在两种需求之间。高管希望获得可靠的 AI 资产清单，因为机密信息可能进入外部系统。员工则希望使用能够帮助他们研究、起草、编程、分析和沟通的工具。

全面封锁提供了明确政策，却带来薄弱的运营可见性。人们可能转向个人设备、移动网络或更不熟悉的服务。组织也就失去了观察使用情况、引导行为或提供更安全替代方案的机会。

不受限制的访问则带来相反的问题。员工可能将客户信息、合同、源代码、会议纪要或内部战略提交给保留规则不明的服务。即使是信誉良好的服务提供商，也可能不适合处理某一类特定数据。

Microsoft 的 AI 应用发现 指南体现了向行为层面控制转变的趋势。它描述了对访问、上传、粘贴内容及其他高风险交互的可见性。这与检查某个应用是否出现在采购清单上，是完全不同的任务。

身份又增加了一层复杂性。公司账户和个人账户可以通过同一终端访问同一服务。域名级监控或许能识别目标地址，却无法确定适用的合同、保留设置或用户授权情况。

嵌入式 AI 进一步增加了分类难度。一个熟悉的应用程序可能通过例行更新增加摘要、转录、预测或内容生成功能。底层产品依然获批，但其数据处理行为已经改变。

因此，安全团队面临维护两类相关资产清单的压力。第一类涵盖技术资产和服务；第二类涵盖获批使用场景、数据类别、身份、责任人和控制要求。

第二类资产清单不能只由安全部门负责。采购部门了解合同；法务部门理解使用条款；隐私团队评估数据处理；部门负责人知道员工为何需要某项工具；平台所有者了解配置和日志记录。

被迫作出的回应既是组织层面的，也是技术层面的。安全部门必须建立可重复的流程，将发现结果转化为所有权决策。否则，检测系统只会产生告警，而不会形成治理。

员工也需要一条易用的报告路径。发现有帮助的 AI 功能的员工，应能够申请审查，而不必预期会被自动拒绝。这一流程能在需求完全转移至受管渠道之外前，将其暴露出来。

这种压力将持续存在，因为 AI 的采用速度快于年度审查周期。即使按季度盘点，也可能错过一项在数天内就获得数千次内部交互的服务。持续发现必须为更快速的审批和补救流程提供输入。

持续证据正在取代静态资产清单

成功的方法是汇集多个不完美的信号，再衡量它们之间的不一致。

没有任何单一传感器能够识别全部资产。主动扫描会探测可访问系统，但可能干扰敏感的运营设备。被动监控可以安全地观察流量，但静默设备仍可能无法被发现。终端代理能够提供细节，但未受管硬件没有这些代理。

可靠的发现计划将每个来源视为部分证据。网络记录显示连接情况；身份系统显示账户和认证；终端平台显示已安装应用程序、进程、扩展和本地文件；云控制平面显示资源及服务关系。

采购和配置数据库依然重要。它们提供所有权、合同、生命周期和业务上下文。其弱点并非毫无用处，而是往往描述意图，而非当前行为。

第一个实际步骤是定义权威预期。团队需要获批设备、服务、身份、AI 工具、数据类别和网络路径的清单。这些清单构成基线，但绝不应成为唯一版本的现实。

第二步是持续收集观测数据。DHCP 和地址解析记录能够暴露已连接硬件。域名和代理日志能够揭示外部服务。认证日志可以将活动关联到身份。终端数据能够识别发起流量的进程。

云环境需要自身的发现路径。资源可能通过自动化出现，并在工作负载完成后消失。容器、无服务器函数、托管数据库和临时开发环境，可能并不像传统设备。

AI 使用还增加了应用层证据。团队可以查找已知服务类别、浏览器扩展、OAuth 授权、与模型相关的 API 密钥，以及向外部目标地址进行的异常传输。他们还可以审查哪些获批产品近期新增了 AI 功能。

第三步是核对。每个观测到的对象都应与预期记录进行匹配。每条预期记录都应有近期证据表明其仍然存在。差异即构成待办队列。

该队列需要清晰的分类。资产可以是已授权且有文档记录、已授权但未记录、未经授权但无害、可疑，或已不再存在。未知应是临时分类，而不是永久存放区。

优先级应依据暴露程度和后果确定。未知的互联网暴露网关应比隔离的测试设备更快接受审查。接收受监管数据的服务，应比处理公开营销文案的服务获得更多关注。

运营技术需要额外谨慎。这些系统通常生命周期长、协议专用，并且对主动扫描的容忍度有限。多机构发布的 OT 资产清单指南 建议结合文档、实地检查和基于网络的信息。

该指南还列出了有用的属性，包括设备角色、主机名、网络地址、制造商、型号、操作系统、位置、协议、端口、服务和用户账户。这些属性有助于将一个观测到的地址转化为风险决策。

这一机制改变了衡量成功的方式。庞大的资产清单并不自动意味着优质的资产清单。一个有用的计划应衡量覆盖范围、时效性、核对时间、所有权以及未解决未知项的存续时间。

它还应跟踪已知资产在变更后变为未知资产的频率。该指标能够暴露入职、离职、采购和配置流程中的缺陷。随后，资产发现工作可以改进造成这些缺口的系统。

结果并非完美可见性，而是一套可辩护的流程：它能检测变化、记录不确定性并明确责任归属。这比一份看似精美、却无人能证明准确性的电子表格更有价值。

AI 工具和隐藏设备会留下不同线索

当团队根据资产类型调查其信号时，未知资产便能够得到有效管理。

隐藏的物理设备通常会留下网络层证据。它会请求地址、解析名称、发布服务、与对等设备通信，或连接外部目的地。有时可根据其硬件地址推断制造商，但这一线索并非定论。

随后，团队可以提出具体问题：是哪个网段观测到了它？它首次出现是什么时候？它是否按某种规律重新出现？它使用哪些协议？其流量特征是否像打印机、摄像头、手机、服务器或控制器？

网络访问控制可要求身份验证，或将不熟悉的设备置于受限网段。不过，隔离措施应考虑业务影响。未知的医疗、制造或楼宇控制设备即使文档不足，也可能支撑关键功能。

未知云资产则呈现另一种模式。它可能拥有账户、所有者标签、部署模板或服务身份。调查人员应将其创建事件与用户、自动化流水线、工单、代码仓库或项目关联起来。

隐藏的 AI 服务可能更难分类，因为目标地址或许可见，但具体使用场景仍不明确。看到某个模型提供商的域名，并不能说明用户提交的是公开文本还是机密源代码。

浏览器和端点上下文有助于弥合这一差距。受管浏览器能够区分访问、上传、粘贴内容、下载和账户类型。端点控制则可识别发起请求的应用程序，并根据数据敏感性执行规则。

基于 API 的使用需要不同类型的证据。安全团队应检查密钥存储、源代码仓库、持续集成系统、云网关、费用记录和出站服务调用。个人密钥可以绕过集中管理的账户和使用限制。

OAuth 授权同样值得关注。OAuth 允许一项服务代表用户访问另一项服务。即使没有新增设备，具备邮箱、日历、网盘或代码仓库访问权限的 AI 助手，也可能形成重要的资产关系。

本地模型则反转了可见性问题。其推理活动可能始终留在端点上，但模型下载和配套工具会产生可观测事件。存储空间增长、软件包安装、进程执行和图形处理器使用情况，都能提供有用的上下文。

嵌入式功能需要进行供应商审查。团队应关注已获批准应用的发布说明、管理设置、分包处理方和合同变更。一个已知供应商可能在不改变熟悉产品名称的情况下引入新的数据路径。

知识工作者也会带来文档挑战。他们可能在一次任务中组合使用多种工具，在会议记录工具、聊天机器人、文档编辑器和项目平台之间传递内容。每个工具都可能已获批准，但组合后的工作流却可能违反政策。

维护清晰的 AI 知识库，可帮助团队记录获批准的工作流、负责人、证据和数据边界。文档应支持调查，而非取代技术观测。

分类流程应以行动收尾。获批准的资产进入受管清单；不必要的服务被撤销访问权限；配置不当的工具获得更安全的设置；可疑系统转入事件响应流程；情况不明的案例则继续保持受限访问，直至出现负责人。

这种方法避免将所有未知项一视同仁。它也承认，扫描器生成一个名称并不意味着资产发现已完成。组织必须了解其用途、控制方式和数据暴露情况。

更高可见性本身也可能带来安全和隐私风险

当收集范围超出明确的安全目的时，持续发现就会适得其反。

对广泛监控最有力的反对意见涉及隐私。浏览器、端点、身份和网络记录能够相当详细地揭示员工行为。将这些记录结合起来会提升调查价值，但也会增加被滥用的可能性。

组织应明确收集哪些数据、收集原因、谁可以访问以及保留多久。影子 AI 项目应聚焦与安全相关的事件，而不应演变为对员工活动进行普遍排名的系统。

个人设备形成了一条尤其棘手的边界。企业可以控制对公司数据的访问，但不应声称能够全面查看员工的整个设备。受管应用、受保护工作区和条件访问能够维护这种界限。

误报会带来另一种风险。共享基础设施、内容分发网络、供应商集成和后台服务都可能让正常流量显得陌生。基于域名或标签的自动阻断可能中断正当工作。

分类数据库也会迅速老化。新的 AI 服务不断出现，供应商会重命名产品，既有平台也会增加由模型驱动的功能。依赖静态供应商列表的检测规则会漏掉新服务，并错误分类旧服务。

加密限制了网络检查能力。网关通常可以看到目标地址和连接元数据，却不一定能确定用户提交了什么内容。解密流量会提高可见性，同时也会引发隐私、证书、性能和运营方面的顾虑。

端点监控能填补部分空白，但也带来覆盖问题。承包商、非受管系统、移动设备和专用设备可能没有安装代理。安全团队应报告这些盲区，而不是把部分覆盖描述为确定事实。

将发现等同于控制也存在治理风险。发现某项 AI 服务并不能解释其使用是否必要、是否曾获得非正式批准，或是否已被现有协议覆盖。技术证据需要一位承担责任的业务负责人。

因此，KnowBe4 的表述应被视为可见性警示，而非每项未识别资产都危险的证明。所提供的来源并未证实发生过可量化的数据泄露、普适的检测率，或存在一种能解决该问题的单一产品。

NIST 的框架提供了重要约束。它要求组织根据分类、关键性、资源和任务影响对资产进行优先级排序。这能避免团队在每个异常项上投入同等精力。

成熟的项目还会衡量传感器的局限性。每份报告都应说明覆盖了哪些网络、端点、身份、云账户和远程用户，并区分“未被观测到”与“实际不存在”。

安全团队可以通过受控演练来检验自身主张。他们可引入经授权的测试设备、临时云资源、浏览器扩展和 AI API 调用。目标是衡量哪些信号能检测到各类案例，以及分析人员完成分类的速度。

这些测试还应涵盖失败条件：设备保持静默时会怎样？个人 API 流量能否绕过受管网关？嵌入式 AI 功能会否显示为独立服务？团队能否识别其数据负责人？

不同环境中的答案会有所不同。这种差异正是组织应抵制“完全可见性”主张的原因。可辩护的目标是可衡量的覆盖范围、已知的盲区，以及持续缩短的不确定期。

三个信号将显示网络发现是否正在跟上变化

接下来的考验在于，组织能否将更多遥测数据转化为更快、更安全的决策。

第一个信号是核对速度。团队应衡量从首次观测到完成分类之间的时间间隔。更短的间隔表明，发现、责任归属和响应流程正在协同运作。

该指标应按资产类别分别统计。物理设备、云资源、SaaS 应用和 AI API 集成都需要不同证据。将它们合并为单一平均值，可能掩盖严重延迟。

如果核对时间缩短，同时误报仍得到控制，持续证据模型便获得支持。如果待处理队列增长速度超过分析人员的处理能力，新增传感器产生的就是噪声，而非有用可见性。

第二个信号是对嵌入式和基于 API 的 AI 的覆盖范围。许多控制措施从网站分类开始，因为浏览器流量更容易识别。但这会遗漏个人密钥、开发者工作流、本地模型以及获批准平台内的 AI 功能。

组织应将网络日志中的发现与端点、身份授权、云系统、代码仓库和供应商审查的结果进行比较。若差异很大，就说明监控架构仍不完整。

更广泛的覆盖将强化 KnowBe4 的核心警示及本文提出的应对方案。若持续依赖网页域名列表，则会削弱企业了解其 AI 暴露面的说法。

第三个信号是治理是否能更快推进，而不默认采取全面阻断。安全团队需要证据证明，有用的服务能够从未知状态转为已审查、已批准状态；也需要证明，高风险使用可按身份、数据类别或功能加以限制。

健康的审批流程应有明确的负责人、既定的证据要求和清晰的决策时限。当申请的服务无法满足政策时，它还应提供更安全的替代方案。沉默或无限期审查会促使员工绕过控制措施。

关注供应商如何提供管理设置、审计事件、模型目标地址和数据保留选项。更好的产品遥测将使嵌入式 AI 更易于治理。日志有限则会让客户继续依赖间接的网络线索。

这篇 Google News 报道带来的更广泛启示，并不是每项不可见资产都具有恶意，而是每项尚未解决的资产都代表着一个关于所有权、访问权限、数据和责任的问题尚未得到回答。

安全负责人应在本季度提出一个实际问题：一台未记录的设备或一项 AI 服务可以运行多久，才会有人为其指定负责人？然后应使用受控示例检验答案。

如果结果以数周计算，组织仍存在静态资产清单问题。如果结果以数小时计算，并有记录在案的证据和相称的控制措施，那么资产发现正成为一种运营安全能力。

下一步很明确：选择一个网段、一个云环境和一项高频员工工作流。将预期记录与观测到的活动进行核对，分类每一处差异，并记录盲区。这项演练将比再制作一份资产清单表格揭示更多信息，也将显示组织是否真的能够识别其既有控制措施无法看见的对象。