影子 AI：客户没有告诉 MSP 的那些事

MSP 应当了解其客户的技术环境。 他们清楚哪些终端受到管理、哪些应用程序对业务至关重要、哪些系统需要修补或维护、敏感数据存储在哪里，以及谁有权访问这些数据。 然而，如今越来越多的关键技术决策是在没有 IT 或 MSP 参与的情况下做出的。

在客户环境中，这可能呈现为多种形式：

• 营销团队使用 AI 设计平台制作营销活动视觉素材
• 销售代表将 AI 助手连接到 CRM，以总结客户互动情况
• 人力资源经理将一份简历上传到公共聊天机器人进行评估
• 开发者使用 AI 编程工具排查公司源代码中的问题

而且每种情况都可能在 MSP 完全不知情的情况下发生。

这并不一定意味着客户在故意隐瞒信息。 问题在于，实际上，AI 的使用已经高度分散。 员工和各个部门只需通过浏览器、信用卡或 OAuth 授权即可访问强大的工具，这就是所谓的“影子 AI”。这使得新技术在 IT 团队或服务提供商甚至尚未察觉、更谈不上全面评估之前，就已进入组织。

对 MSP 而言，这会立即带来一个问题：您无法有效保护自己看不见的环境，也无法防御自己不知道存在的事物。

影子 AI 如何给 MSP 带来安全风险

多年来，影子 IT 一直给组织带来挑战，因为员工不断采用未经批准的 IT 渠道之外的技术。 然而，影子 AI 会进一步加剧潜在的风险暴露。 这些应用程序并非只是与业务系统并存；它们还可能与公司敏感数据交互、连接超出其初始范围的现有平台，并以越来越高的自主程度执行任务。

近期研究表明，这种行为已经十分普遍。毕马威《2025 年影子 AI 报告》发现，44% 的受访美国员工明知其使用 AI 的方式违反所在组织的政策或准则，却仍然使用 AI。 其动机不一定出于恶意；往往是为了方便、快捷和提高效率。 如今的工作文化越来越重视这些特质，鼓励员工将重复性任务自动化，并采用他们认为能够帮助自己提升工作表现的工具。

但追求更高效率并不能消除风险。

对 MSP 而言，真正令人担忧的是每个未识别的应用程序会为环境增加什么：另一组在既有监管范围之外运行的连接、权限和潜在访问路径。

AI 工具背后的隐性访问与权限

对于采用这项技术的人而言，使用 AI 所带来的安全影响并不总是显而易见。 看似简单的连接可能会带来远超当前任务所需范围的权限和访问权限。

试想一下，当员工将 AI 应用程序连接到业务平台时会发生什么。

对用户而言，这一过程可能简单到只需点击“允许”按钮。 在这一批准背后，可能涉及一系列权限，例如检索文件、访问联系人、处理客户信息或连接其他应用程序。

这些连接可能在初次交互结束后仍然持续存在，从而形成 MSP 可能并不知情的访问权限。 虽然 MSP 可能仍在管理端点、保护用户账户并保障底层业务应用程序的安全，但它可能并不了解存在于这些环节之间的连接。

这正是 AI 开始重塑传统影子 IT 概念的地方。 未知的不再是正在使用哪个应用程序。 MSP 还需要了解 AI 服务可以访问哪些信息、被授予了哪些确切权限、哪些凭据为其提供支持，以及这些访问权限是否仍有必要。

这种监管缺口带来的后果已经开始显现。 IBM 的《2025 年数据泄露成本报告》显示，在接受调查的遭遇数据泄露的组织中，有 63% 要么没有 AI 治理策略，要么仍在制定相关策略。 在已制定相关策略的组织中，只有 34% 会定期审计未经批准的 AI 使用情况。 影子 AI 使用程度较高的组织，其数据泄露成本平均比极少使用或未使用未经批准 AI 的组织高出 670,000 美元。

为什么 MSP 需要了解 AI 访问情况

对 MSP 而言，首要任务并不是控制客户是否使用 AI，而是了解这种使用如何改变其负责保障安全的环境。

团队之所以采用这些应用程序，是因为它们能够解决实际问题，并简化耗时的任务。 在组织层面，探索能够提升生产力的技术同样具有强大的驱动力。

更有效的应对方式始于重新审视 MSP 所提出的问题。

记录客户正式批准了哪些 AI 应用程序是一个良好的开端，但这只能反映部分情况。 MSP 需要了解以下情况：

• 员工实际使用哪些 AI 服务
• 这些服务可以访问哪些业务应用程序和数据
• 已授予哪些 OAuth 权限
• 哪些 API 密钥或服务账户支持这些连接
• 这些工具连接后获授权执行哪些操作

最重要的是，这些访问权限的范围有多大，是否超出了实际所需？

这些问题将讨论重点从制定策略转向评估实际风险。 即使是经批准的 AI 使用，也可能产生安全漏洞：

• 连接到 CRM 的 AI 助手可能会被授予超出其执行预期任务所需范围的客户记录访问权限。
• 同一个 AI 服务可能在一个部门被限制为仅访问经批准的数据源，而在另一个部门则被授予更广泛的访问权限。
• 为临时项目授予的访问权限可能在项目结束很久之后仍保持有效。

仅凭审批并不能保证访问权限设置得当。

要跟上这些变化，仅进行一次性清查是不够的。 新的应用程序不断涌现，现有的 SaaS 供应商不断添加 AI 功能，而自主代理则开始执行直到最近还需要人工直接参与的任务。 监控此类活动应成为 MSP 安全审查和持续客户沟通中的标准做法。

业界日益重视 AI 发现，反映出这一需求的紧迫性。 越来越多的专用安全功能不断涌现，用于识别未经 IT 批准使用的生成式 AI 应用程序、分析使用模式、评估应用程序风险以及监控潜在的数据暴露。 对于内部缺乏同等资源的小型组织而言，这为 MSP 提供了一个可以发挥作用的领域，帮助其提供有价值的可见性和指导。 AI 发现正迅速成为保持客户环境整体可见性的重要组成部分。

管理员可以审查使用模式、识别未经批准的应用程序、评估应用程序风险、检查访问权限并监控潜在的数据暴露。 这些功能可以发现原本可能处于传统 IT 监管范围之外的 AI 活动。

对 MSP 而言，AI 发现正迅速成为保持客户环境整体可见性不可或缺的一部分。

MSP 如何与客户共同提升 AI 治理

对于大多数组织而言，弥合这一差距不仅是技术挑战，更是沟通挑战。

当员工未意识到哪些与 AI 相关的决策会带来安全影响或需要 MSP 介入时，这种脱节往往会进一步加剧。 最初看似简单的应用程序、集成或部门采购，都可能引入新的权限、凭据和访问要求，而这些要求的范围可能远远超出其预期用途。

对 MSP 而言，加强 AI 治理始于明确客户应在何时以及如何沟通与 AI 相关的变更。 这些讨论应涵盖以下问题：

• 各团队正在尝试哪些新的 AI 工具，这些工具是否已获批用于业务？
• 是否有任何部门将 AI 工具直接连接到敏感系统或业务关键型应用程序？
• 正在与这些工具共享哪些公司、客户或其他敏感数据？这些数据提交后又会流向何处？
• 每个 AI 集成由谁负责，并由谁长期管理其访问权限？
• 自引入该工具以来，权限是否有所扩大或发生变化？
• 先前批准的集成是否仍有必要，还是在最初的业务需求结束后，访问权限仍然存在？

通过发起这些讨论，并随着客户环境的变化持续开展沟通，MSP 可以在 AI 活动为环境增加另一层未受管理的复杂性之前，及时发现这些活动。 更重要的是，MSP 可以帮助客户快速推进 AI 应用，同时避免访问权限和监管跟不上变化。

目标很简单：MSP 需要在这些工具访问公司数据或系统之前，实时了解 AI 的部署情况。

MSP 如何保障各客户环境中的 AI 访问安全

发现此前未知的 AI 使用情况只能解决部分问题。 一旦发现这类活动，MSP 就需要一种一致的方法，在各个客户环境中对其进行管控。

AI 助手、集成和智能体最终都依赖于凭据、权限以及与业务系统的连接。 必须保护这些访问路径，将特权限制在必要范围内，并根据需求变化调整权限。 对于开展规模化运营的 MSP 而言，挑战在于随着客户环境不断演进，如何在多个客户环境中始终如一地应用这些原则。

Keeper 为 MSP 提供统一的平台，帮助其实现这一目标。 通过在零信任、零知识架构中整合凭据安全、特权访问、机密管理和端点特权管理，Keeper 可帮助 MSP 大规模治理人类和机器身份，同时无需在安全技术栈中引入另一个孤立的层级。

最严重的 AI 风险可能并非来自 MSP 已经管理的应用程序。

它或许来自那些没人想到要提及的应用程序。

了解 Keeper MSP 合作伙伴计划，看看 Keeper 如何帮助 MSP 弥补各客户环境中的 AI 可见性缺口。