什么是影子 AI？

影子 AI 指在组织内未经授权或无管理地使用 AI 工具、模型、框架、API 或平台，其操作游离于既定的治理框架之外。虽然员工采用这些 AI 工具的初衷可能是好的，旨在提高生产力或更有效地解决问题，但缺乏监督会带来严重的安全、合规和运营风险。

开发人员正在迅速集成 AI，而应用安全团队对此毫不知情或无法监督。几乎所有人都已不再仅仅将 AI 作为内部工具使用，而是在部署 AI 模型。许多人正在试验 AI 代理。开发人员在使用 AI 时不会询问应用安全团队该怎么做。这创造了一个环境，AI 组件在组织代码库的阴影中运行，安全监督无法触及，但在应用程序中功能齐全。

从应用安全 (AppSec) 的角度来看，影子 AI 代表了组织安全态势中的一个重大盲点，因为这些未经审查的 AI 组件可以处理敏感数据、做出自动化决策，并引入传统安全扫描和测试流程无法检测到的漏洞。

影子 AI 与影子 IT

虽然影子 AI 和影子 IT 有共同的属性，但它们带来了组织必须理解的独特技术挑战：

属性	影子 IT	影子 AI
部署机制	未经组织批准，擅自使用任何 IT 系统、解决方案、设备或技术	未经组织 IT 部门控制或不知情的情况下，擅自使用或实施 AI
攻击面	仅限于应用程序的直接功能	通过数据输入、模型行为和 API 访问而扩大
漏洞类型	传统的 CVE、配置错误	模型特定漏洞、提示词注入、投毒攻击
检测难度	网络监控、库存管理	需要具备模型指纹识别能力的 AI 感知扫描工具
数据影响	数据处理方面的担忧	训练数据、推理数据和模型输出风险

关键区别在于所涉技术的性质和潜在影响。影子 IT 的风险通常局限于团队或特定应用程序，而影子 AI 由于其数据需求、学习能力以及大规模影响决策的潜力，可能对整个组织产生更广泛的影响。

常见的影子 AI 实施模式包括在应用程序代码中嵌入 AI 模型导入、对 AI 服务进行外部 API 调用、使用机器学习库构建自定义模型，以及集成向量数据库以实现检索增强生成 (RAG) 模式。这些实施模式中的每一种都带来了传统安全工具可能无法检测或正确评估的不同安全考量。

影子 AI 的成因​

有几个因素促成了现代组织中影子 AI 的兴起：

可访问性和集成简便性

AI 工具现在比以往任何时候都更容易获得，许多工具是免费、廉价或只需最少的设置，这使得非技术用户也能在没有 IT 部门参与的情况下轻松采用它们。

像 ChatGPT、Gemini 和 Claude 这样的平台使 AI 触手可及，而 AutoML 等框架和 Hugging Face 上的预训练模型简化了高级 AI 功能的部署。现代 AI 服务使用简单的 REST API，只需少量代码即可快速集成，但这种便捷性可能会绕过传统的安全审查。像 Mend AI 这样的工具现在对于识别 AI 相关端点和确保安全实施至关重要。

构建流水线和 CI/CD 集成

现代开发实践允许开发人员在没有安全监督的情况下将 AI 模型直接集成到 CI/CD 流水线中。AI 模型可以从公共存储库自动下载，嵌入到应用程序中，并持续部署，这使得安全团队难以跟踪和管理这些组件。

AI 工作负载的容器化

容器化通过将完整的 AI 环境——包括框架、模型和依赖项——打包在自包含的单元中，使部署 AI 系统变得更加容易。这些容器可以在 Kubernetes 等平台上运行，但其封装的性质使得安全团队难以检查其内容，从而导致了影子 AI 的兴起，即未经监控的 AI 组件可以在不被发现的情况下运行。

生产力压力

尽管存在风险，员工仍使用影子 AI，因为它能促进创新并允许快速试验新工具，尤其是在上市时间至关重要的快节奏环境中。开发人员和 DevOps 团队通常依赖 AI 来完成代码自动化、扩展预测或事件分析等任务，当正式的治理流程感觉太慢或限制太多时，他们就会绕过这些流程。当批准的工具不尽如人意时，员工自然会转向那些能立即带来生产力提升的替代方案。

缺乏意识

开发人员经常在未经许可或未通知安全团队的情况下使用 AI，而许多员工低估了未经授权工具的风险。即使是安全团队也可能错误地认为预训练的公共模型没有合规风险，忽略了数据沿袭、知识产权和监管风险等问题。这种治理的缺失导致了“影子 AI”的出现，员工因政策不明确、培训不足和内部选择有限而转向未经批准的工具。没有适当的监督，组织将面临严重的安全、合规和准确性漏洞。

影子 AI 的风险

虽然影子 AI 凸显了未经批准使用 AI 的风险，但经批准的 AI 系统本身也面临着从提示词注入到不安全插件设计的安全挑战。如果您的组织正在构建或与 LLM 集成，请确保您也熟悉 2025 年 OWASP LLM 应用十大风险，其中概述了现代 AI 应用中最关键的漏洞。

您应主要关注以下风险：

数据安全

最大的风险是敏感数据缺乏保护。墨尔本商学院 2025 年 4 月的研究发现，48% 的员工曾将敏感的公司或客户数据上传到公共生成式 AI 工具中，44% 的人承认在工作中违反公司政策使用 AI。

当员工使用未经授权的 AI 工具时，他们可能会无意中与外部系统共享机密的商业信息、知识产权或受监管的数据。一旦这些数据离开组织的可控环境，就几乎不可能对其进行跟踪、管理或保护。

像 2023 年三星数据泄露事件，工程师在寻求编码帮助时意外与 ChatGPT 共享了专有源代码，这说明了使用影子 AI 的潜在后果。虽然如今的 LLM 更加复杂，并具备更强的企业控制功能，但对于那些没有内置企业安全功能的影子 AI 来说，类似事件仍然是完全可能发生的。此类数据泄露可能导致竞争劣势、违反法规以及损害客户信任。

对于应用安全团队来说，这构成了一个重大挑战，因为敏感数据可能会在没有适当安全控制、数据保护协议或合规验证的情况下被外部 AI 服务处理，而他们可能直到为时已晚才发现。

模型特定的攻击向量

影子 AI 模型也可能以其他微妙的方式泄露敏感数据。通过提示词注入攻击、从训练集中泄露数据或模型反演技术。想象一个代码生成 LLM，它在专有代码片段上进行了微调，但也在包含恶意软件的未经审查的 GitHub 存储库上进行了训练。

AI 模型引入了传统安全扫描工具无法检测的独特攻击向量：

1. ​提示词注入攻击 (Prompt Injection Attacks)：旨在通过嵌入覆盖系统提示或安全约束的指令来操纵 AI 行为的恶意输入。这些攻击可能导致模型泄露敏感信息、生成有害内容或绕过安全控制。
2. ​模型权重投毒 (Model Weight Poisoning)​：在训练或微调期间篡改模型权重以引入漏洞或后门。当使用来自不受信任来源的预训练模型或训练过程缺乏适当的安全控制时，可能会发生这种情况。
3. ​训练数据提取 (Training Data Extraction)：通过精心设计的查询来利用模型对其训练数据的知识，从而提取敏感的训练数据。通过系统性的探测，攻击者可能重建用于训练模型的专有或敏感信息。
4. ​后门触发器 (Backdoor Triggers)​：由特定输入激活的隐藏功能，旨在在触发时导致模型行为异常。这些后门可以在模型开发期间或通过对模型存储库的供应链攻击插入。

API 密钥管理漏洞

AI 服务通常需要 API 密钥，而这些密钥可能在代码存储库或配置文件中未得到妥善保护。实施影子 AI 的开发人员可能会无意中在代码、配置文件或日志中暴露 API 密钥，从而产生安全漏洞。

暴露的 API 密钥可能导致未经授权的使用、潜在的数据泄露以及因意外服务费用而造成的财务影响。由于这些实施发生在治理框架之外，标准的秘密管理安全控制可能未被应用，从而增加了暴露的风险。

通过模型输入和输出造成的数据泄露

AI 模型处理的数据可能包含敏感信息。当这些模型在治理框架之外运行时，可能会产生数据泄露风险。开发人员可能会无意中将敏感数据发送到外部 AI 服务进行处理，包括个人可识别信息 (PII)、知识产权或机密商业信息。

发送到外部 AI 服务的数据可能会被服务提供商记录、存储或用于模型训练，从而带来重大的数据隐私和安全风险。许多 AI 服务提供商会保留数据以改进模型，这可能将敏感信息暴露在组织边界之外。

技术差距

你无法保护或治理你不知道的事物。影子 AI 组件可能不遵守以下安全标准：

• 输入验证和净化
• 输出编码和过滤
• 访问控制约束
• AI 操作的审计日志记录
• 遵守数据驻留要求

这在安全态势中造成了可被攻击者利用的技术差距。缺乏可见性意味着安全团队无法确保这些组件满足组织的安全标准或合规要求，从而在安全态势中产生潜在的盲点。

合规违规

健全的安全原则在 AI 面前并未改变。组织必须确保公共 AI 模型不会在可能导致无意数据泄露的敏感或专有数据上进行训练。

随着围绕 AI 的监管框架不断发展，未经授权的 AI 使用会带来重大的合规风险。许多政府正寻求规范 AI 发展的“狂野西部”。欧盟 AI 法案于 2024 年 8 月 1 日生效，禁止某些类型的 AI 应用并限制许多其他应用，为 AI 产品的开发者带来了沉重的合规义务。在美国，最重要的行动 来自关于安全、可靠和可信赖的人工智能开发与使用的第 14110 号行政命令 (EO)。

没有适当的治理，这些模型生成的输出可能与组织的目标或道德标准不符。数据偏见、过拟合和模型漂移是 AI 风险的例子，可能导致糟糕的战略选择并损害公司声誉。

从技术角度看，合规要求可能包括：

• 数据驻留和主权控制
• 透明度和可解释性文档
• 偏见测试和公平性评估
• 隐私影响评估
• 安全测试和漏洞管理
• 审计日志记录和可追溯性

根据定义，影子 AI 在这些治理框架之外运作，为受 GDPR、HIPAA 和行业特定要求约束的组织带来了重大的合规风险。

运营中断

未经管理的 AI 系统可能给企业带来严重风险。以下是关键挑战：

• ​模型漂移 (Model Drift)：用于容量规划或欺诈检测等任务的预测模型，如果输入发生变化，可能会悄无声息地退化，导致服务中断、违反 SLA 或损害客户利益。
• ​缺乏监控 (Lack of Monitoring)：在生产环境中未经验证的模型，如果没有重新训练或监控，可能导致关键故障，直到造成损害才被发现。
• ​运营效率低下 (Operational Inefficiencies) ​：集成不佳的 AI 解决方案可能产生技术债务、数据孤岛以及与现有系统的不兼容，使其随着需求变化而变得不可持续。
• ​数据管理问题 (Data Management Issues)​：分散在未经授权的 AI 工具中的数据可能损害准确性、集成和治理，导致洞察力差和糟糕的业务决策。
• 系统可靠性风险 (System Reliability Risks): 影子 AI 的实施可能会破坏系统的可靠性、性能和维护，成为 DevOps 和运营团队的关键故障点。

影子 AI 的示例

影子 AI 在不同的组织环境中可以有多种形式：

影子 AI 最常见的形式之一是使用像 ChatGPT、Claude 或 Gemini 这样的生成式 AI 平台。员工可能会在没有组织监督的情况下使用这些工具来起草邮件、创建内容、生成代码或分析数据。虽然这些工具提供了令人印象深刻的功能，但在用于处理敏感业务信息时也带来了重大风险。

一位市场营销实习生可能因急于快速撰写新闻稿而感到压力。他们使用 ChatGPT 获取灵感，复制了包含机密客户细节的信息。虽然 ChatGPT 生成了一份令人印象深刻的草稿，但该平台的数据政策允许其保留用户输入以改进模型，这意味着敏感的客户信息现在被存储在外部服务器上，而公司对此毫不知情。

从更技术的角度来看，开发人员在没有进行秘密扫描的情况下将 GitHub Copilot 集成到安全的代码库流水线中，可能导致内部 API 密钥在自动建议的代码片段中泄露。同样，工程师使用像 OpenAI API 这样的工具生成文档时，可能会在生成的内容中意外暴露内部项目代号或路线图项目。

AI 驱动的代码生成和审查

随着开发人员越来越多地使用 AI 根据自然语言描述生成代码片段、SQL 查询或应用程序逻辑，他们可能会引入多种风险。

AI 生成的代码可能包含安全漏洞、不安全的模式或实现错误，开发人员可能在没有适当审查的情况下就实现了这些代码。通过 AI 生成代码的便利性可能导致开发人员在不了解安全影响或未进行充分安全审查的情况下实施解决方案。

数据科学家和分析师可能会部署机器学习模型来分析公司数据并生成预测。这些模型可能会访问敏感信息，创建未经审查的输出以影响业务决策，或引入未经适当验证流程而未被发现的偏见和错误。

一位急于证明预测分析对销售部门价值的数据科学家，可能会在不了解其可能导致有偏见的推荐从而疏远某些客户群体的情况下，使用外部 AI 平台。

从技术角度看，这些工具可能引入多种风险：

• 未经授权的数据访问和处理
• 没有适当监控的模型漂移和退化
• 影响业务决策的有偏见或不准确的输出
• 缺乏模型文档和可复现性
• 与未经授权的数据源或服务集成

AI 聊天助手

团队可能会在未经适当审查的情况下，将 AI 聊天助手集成到客户服务运营、内部支持系统或协作平台中。这些助手可能引入多种技术风险：

• 在没有适当数据保护的情况下处理敏感的客户查询
• 通过对抗性输入可能导致的社交工程或操纵
• 缺乏内容过滤或安全机制
• 不一致或不正确的响应导致运营问题
• 在没有适当安全控制的情况下与后端系统集成

AI 浏览器扩展

员工可能会安装声称能提高生产力、总结内容或自动化任务的 AI 浏览器扩展。这些扩展通常拥有访问浏览器数据的广泛权限，可能暴露敏感信息或造成安全漏洞。

浏览器扩展可能引入重大风险，例如：

• 访问所有浏览器内容，包括敏感的内部系统
• 在没有适当安全控制的情况下向外部服务传输数据
• 伪装成 AI 工具的恶意扩展的可能性
• 缺乏更新管理或漏洞修补
• 通过基于浏览器的操作绕过网络安全控制

在应用程序中嵌入 LLM 工作流

开发人员经常在没有适当安全审查的情况下将大型语言模型直接集成到应用程序中。一种常见的实现模式是检索增强生成 (RAG)，它结合了向量数据库、嵌入模型和大型语言模型，以利用上下文信息增强 AI 的响应。

这种模式结合了多个 AI 组件，如果管理不当，每个组件都会带来安全风险。嵌入过程可能泄露敏感数据，向量数据库可能在没有适当访问控制的情况下存储信息，而外部 LLM 可能会在没有适当安全措施的情况下处理和保留敏感信息。

本地模型部署

开发人员可能会在没有安全评估的情况下从像 Hugging Face 这样的存储库下载和集成开源模型。这些模型通常使用机器学习框架直接实现到应用程序中，允许开发人员在没有外部 API 依赖的情况下在本地执行 AI 推理。

这些模型可能包含漏洞、后门或生成可能危及应用程序安全的意外输出。由于这些模型通常缺乏商业产品所受的审查，它们可能包含在实施过程中未被发现的意外行为或安全问题。

DevOps 工作流中的自主 AI 代理

DevOps 团队可能会实施与基础设施、监控或部署系统交互的自主 AI 代理。这些代理可以分析系统性能、检测异常，甚至在没有人工干预的情况下实施补救措施。

这些代理可能拥有过多权限或在没有适当监督的情况下进行基础设施更改，从而产生安全和稳定性风险。这些系统的自主性如果操作时没有适当的约束和监督，可能导致意外行为或级联故障。

影子 AI：检测与管理策略

组织需要全面的策略来应对影子 AI 的挑战：

5. 监控 AI 使用情况

好消息是，我们有工具可以检测应用程序中的 AI。AI 模型和代理的文件和代码具有某些特征，可以被训练用于该任务的其他 AI 模型发现。同样，这些模型也可以检测开源 AI 模型的许可证。

例如，像 Mend AI 这样的工具可以扫描代码库、应用程序清单和依赖树，以查找隐藏的 AI 组件。然后，它会生成一份意识报告（影子 AI 报告），提供整个组织 AI 使用情况的详细地图，从而了解不同产品、项目和组织单位的 AI 使用量。

实施能够检测跨网络、应用程序和云服务的 AI 相关活动的监控工具是至关重要的第一步。这些监控解决方案应能够识别：

• 对外部服务的 AI 相关 API 调用
• 应用程序中的机器学习库和框架
• 容器镜像中的模型文件和 AI 组件
• 向 AI 服务和平台的数据传输
• 向量数据库和嵌入服务

6. 审计和盘点 AI 工具

进行全面的审计以识别整个组织中使用的所有 AI 工具和模型，为治理工作奠定了基础。这份清单应包括哪些 AI 系统正在被使用、由谁使用、用于何种目的以及它们处理什么数据的详细信息。这还应包括对模型文件、配置文件、训练数据集、LLM 微调检查点的 AI 工件发现。

然后，利用这份审计结果，维护一个内部的 AI 资产注册表或每个 AI 模型和部署的“事实来源”。

使用像 Mend AI 这样的工具，您可以检测各种 AI 技术，包括像 OpenAI 和 Azure 这样的第三方 LLM API、来自 Hugging Face 和 Kaggle 等注册表的开放 ML 模型以及嵌入库。这为您代码中使用的 AI 组件（包括影子 AI）提供了全面的可见性，从而识别并标记出未经注册表批准的使用实例。这份清单为组织的 AI 攻击面提供了关键的可见性，从而实现了更有效的风险评估和缓解策略。

7. 建立明确的 AI 政策

员工需要关于可接受的 AI 使用的明确指导，这使得定义明确的负责任 AI 政策至关重要。该政策应概述可以处理的数据类型、禁止的活动以及每个人都必须遵守的安全协议。

这些政策应涉及：

• 经批准的 AI 工具和平台
• 允许的 AI 使用案例
• 数据处理要求和限制
• 安全和隐私标准
• 合规义务
• 新 AI 实施的审批流程
• AI 开发和使用的道德准则

8. AI 治理的技术实施

应用安全团队需要实施全面的治理控制：

• ​CI/CD 流水线集成​：在 CI/CD 流水线中实施 AI 安全检查，以在构建和部署过程中检测和评估 AI 组件。这些检查可以在部署前识别未经授权的 AI 组件、验证安全配置并强制执行治理政策。
• ​依赖项治理​：实施 AI 感知的依赖项控制，限制哪些 AI 包、库和模型可以在应用程序中使用。这包括经批准的存储库配置、版本锁定以及对 AI 组件的自动漏洞扫描。
• ​网络控制​：对 AI API 端点实施出口过滤，以控制应用程序可以与哪些外部 AI 服务通信。这包括强制执行 AI 服务交互访问控制的网络策略、API 网关和代理。

9. 实施技术护栏

从技术角度来看，护栏，正如 IBM 所指出的，可以包括有关外部 AI 使用的政策、用于测试 AI 应用程序的沙盒环境或用于阻止未经授权的外部平台的防火墙。

AI 使用的技术护栏包括：

• ​AI API 的代理服务​：为 AI 服务实施组织代理，以协调应用程序和外部 AI 服务之间的交互。这些代理可以强制执行安全策略、过滤敏感数据、记录交互，并为 AI 使用提供集中治理。
• ​容器安全策略​：实施像 Open Policy Agent (OPA) 这样的策略引擎，以强制执行 AI 工作负载的安全控制。这些策略可以限制哪些 AI 模型可以部署、强制执行安全配置并确保符合组织标准。
• ​安全的 AI 开发环境​：为 AI 开发提供经批准的环境，包括预先批准的工具、库和服务。这些环境可以在为开发人员提供所需功能的同时强制执行安全控制，从而减少采用影子 AI 替代方案的动机。

10. 实施访问控制

组织应为处理安全敏感任务的 AI 工具实施基于角色的访问控制 (RBAC)，并定期审计输入和输出日志以检测潜在的数据暴露。

限制对敏感数据的访问并实施防止与外部 AI 服务进行未经授权数据共享的控制，可以显著降低影子 AI 的风险。从技术角度看，这些控制可能包括：

• 检测和阻止敏感数据传输的数据丢失防护工具
• 针对 AI 服务端点的网络流量过滤
• 强制执行 AI 服务访问控制的 API 网关
• 限制 AI 工作负载的容器安全策略
• 用于敏感 AI 处理的安全区域
• 监控对 AI 模型托管平台（例如，AWS SageMaker、Azure AI）的未经授权使用。

11. 员工教育与培训

教育员工了解 AI 风险和最佳实践是减少影子 AI 最有效的方法之一。重点关注适合其角色的实用指导，例如如何保护敏感数据和避免高风险的影子 AI 应用。

提高对影子 AI 风险的认识并提供关于正确使用 AI 的培训对于各个团队至关重要。这种教育应涵盖：

• 未经授权使用 AI 的安全和合规风险
• 如何请求和实施经批准的 AI 解决方案
• 使用 AI 工具时的安全数据处理实践
• 组织的 AI 治理政策和程序
• AI 组件的安全开发实践
• AI 实施的道德考量

对于开发团队，此培训应包括关于安全 AI 实施模式、数据保护技术以及如何在现有治理框架内集成 AI 功能的实用指导。

12. 事件响应规划

专门为 AI 相关安全事件制定事件响应协议，可确保组织在影子 AI 导致数据暴露或其他安全漏洞时能够有效应对。这些协议应包括：

1. 检测机制： 实施对 AI 特定异常的监控，例如异常的 API 使用模式、可疑的数据传输或意外的模型行为。
2. 隔离程序： 定义隔离受损 AI 组件的步骤，包括网络隔离、服务暂停和遏制措施。切断 API 密钥，撤销访问令牌，对受影响的资源进行快照。
3. 根除： 移除未经授权的模型、扩展或服务，并清理来自存储库、容器和云存储的残留工件。
4. 取证分析方法： 开发用于分析 AI 组件的专门程序，包括模型检查、数据流分析和行为评估。这些工具可以帮助安全团队了解涉及 AI 系统的安全事件的性质和范围。
5. 补救步骤： 建立处理涉及 AI 系统的安全事件的明确流程，包括模型更新、数据恢复和安全增强。
6. 沟通协议： 定义如何向利益相关者沟通 AI 相关的安全事件，包括监管报告要求。
7. 事后分析： 确定此问题的根本原因。是训练数据差距？交付压力？缺乏工具？相应地更新检测规则、政策文件和访问控制。

影子 AI 是组织中日益增长的一个担忧。如果没有系统的发现、治理和教育，这些未经监控的模型很可能已经带来了不可接受的风险。问题在于，要在坏人之前找到它们。

使用 Mend AI 控制影子 AI 风险

像 Mend AI 这样的工具可以为您代码和基础设施内部隐藏的 AI 组件提供可见性和控制，帮助组织从被动发现转向主动管理。

最后但同样重要的是，运用基本原则。安全编码、风险管理、合规和政策执行——这些都没有改变。如果您的组织已经遵循安全编码实践、访问控制政策和合规框架，那么您就已经为应对 AI 做好了充分准备。

通过以技术严谨性解决影子 AI 问题，并将治理集成到现有的安全框架中，组织可以在整个开发生命周期中利用 AI 的好处，同时保持安全性、合规性和运营完整性。

提高对您应用程序中 AI 组件的可见性和控制力