AI 为 MSP 带来的隐藏身份风险

组织正快速将 AI 集成到日常业务运营中。 团队正在使用 Microsoft Copilot 和 Gemini 来总结会议内容，开发人员正借助代码助手加快软件交付速度，客户服务团队正在部署 AI 驱动的聊天机器人来提高响应速度。 尽管这些举措常从生产力和创新的角度来审视，但它们也在以人们常常忽视的方式重塑着组织的身份环境。

所有 AI 部署都依赖于对业务系统的可信访问。 无论 AI 助手连接到 Microsoft 365、Salesforce、SharePoint 还是内部知识库，它都需要使用必须授予和管理的凭据和权限进行身份验证、检索信息和执行操作。 因此，每次部署都会引入另一个必须保护的身份。

在客户会议和高管讨论中，关于 AI 的对话通常围绕着生产力提升、治理策略和可接受的使用方式展开。 人们对为支持这些技术而创建的身份关注有限。

那么，在这个过程中，我们又创建了哪些新身份？

这一答案的影响远远超出了 AI 的采用范畴。

AI 如何扩大针对 MSP 的身份攻击面

让我们来看看企业部署新的 AI 工具时会发生什么：

营销团队将 AI 写作助手连接至 SharePoint。 销售团队启用了 AI 驱动的 CRM 助手。 客户服务经理推出了一款连接内部文档的聊天机器人。 运营团队利用 AI 驱动的编排实现重复性工作流程自动化。

每次部署似乎都是一次独立的生产力提升。 然而，从安全角度来看，其影响要深远得多。

这些解决方案都需要可信的访问权限，才能执行其设计的任务。 有些设备通过 OAuth 连接进行身份验证，而另一些设备则依赖 API 密钥、服务帐户、机器凭据或访问令牌。 每个设备都获得了检索信息、与业务应用程序交互以及代表用户执行操作的权限。 单独来看，这些身份很少引起太多关注。 从整体上看，他们开始扩大许多组织从未衡量过的东西：其身份攻击面。

AI 在企业中的快速扩张使这一挑战难以忽视。 根据 Microsoft 发布的《2025 年工作趋势指数》，82% 的企业领导者表示，今年是通过 AI 重新思考战略与运营核心要素的关键一年。 该报告还发现，已有 46% 的组织正在使用 AI 智能体来完全自动化工作流或业务流程，这表明 AI 正迅速从实验阶段转向日常运营。

这些数字所体现的远不止 AI 使用率的提高。

他们指出，越来越多的应用程序、工作流和自动化流程需要在企业环境中进行可信访问。

非人类身份 (NHI) 为何会带来隐患

传统的身份认同体系是以人为中心构建的。 员工加入组织后，会获得一个账户，并被授予访问相应系统的权限；但当员工更换职位或离开公司时，这些权限最终会被撤销。 虽然该流程并不总是无缝的，但它遵循可预测的生命周期，并有明确的责任归属。

AI 则不然。

AI 助手可以通过 OAuth 令牌进行身份验证。 工作流自动化平台可能会依赖多个服务账户和 API 密钥。 自主代理可以使用机器凭证访问多个业务应用程序，这些凭据可在无需人工直接干预的情况下持续运行。 与员工帐户不同，这些身份通常是在应用程序设置期间即时创建的，或由将 AI 工具连接到现有系统的单个管理员、开发人员和业务用户创建的。

其中许多身份存在于组织已实施的员工管理流程之外。 其中一些身份在不再需要后很长时间内依然处于生效状态，因为将其移除可能会中断工作流或破坏集成。 随着时间的推移，组织会积累成百上千个与个人无关但拥有关键业务系统合法访问权限的身份。

安全专业人员将这些身份统称为非人类身份 (NHI)：即由应用程序、服务、工作负载和自动化流程（而非员工）使用的数字身份。 虽然某些组织可能不熟悉该术语，但这一概念并不陌生。 代表用户行事的每一个 API 密钥、OAuth 连接、服务账户、机器凭据和 AI 智能体，都代表着另一个具有特权访问权限的身份，必须在其整个生命周期中进行管理。

NHI 的数量并非一成不变。 每一次新的 AI 部署、自动化工作流和系统集成都会引入需要治理的凭证、服务账户和机器身份。 随着越来越多的应用程序、工作流和系统相互连接，保持可见性变得越来越困难。

这不仅是一个清单管理问题。 这也是可见性和控制问题。

组织无法有效保护那些未知的已存在身份，无法定期审查看不见的权限，也无法移除未意识到已授予的访问权限。

不幸的是，攻击者无需担心这一限制。

为什么攻击者会攻击未受管理的机器身份

网络犯罪分子不会区分人类与机器身份。 他们只是在寻找进入有价值系统和敏感数据的最快路径。

多年来，网络钓鱼活动和凭据盗窃主要针对员工，因为用户账户是进入组织环境最直接的途径。 这一现状并未改变，但潜在入口点的数量却发生了变化。

当今的攻击者越来越多地利用 API 密钥、服务帐户、访问令牌和机器凭据，因为这些身份在运行时通常拥有广泛的权限、持久访问权限，且相比传统用户帐户受到的监管要少得多。 与员工帐户不同，服务帐户不会质疑意外请求，API 密钥不会报告可疑活动，AI 智能体也无法识别它正在与恶意系统交互。 如果这些身份信息泄露，攻击者通常就能获得他们真正需要的东西：合法的访问权限。

根据 Red Canary 发布的《2025 年威胁检测报告》，身份攻击较 2024 年增长了 850%，占 2025 年整体检测量的 53%，凸显出攻击者日益依赖凭据窃取和基于身份的攻击技术。

每次新的 AI 部署都会在环境中引入另一个机器身份、服务帐户或凭证。

挑战并不仅仅在于存在更多身份。 问题在于，许多用户获得的权限超出了实际所需、有效时间超出了预期，或在缺乏持续监控的情况下运行。 单独来看，这些问题可能显得微不足道。 它们共同创建了一个不断扩大的受信任身份集合，攻击者可以加以利用。

随着越来越多的组织选择自动化，不仅要了解谁有权访问关键系统，还要了解哪些对象有权访问，这一点变得越来越重要。

为何 AI 身份安全对 MSP 至关重要

对于大多数组织而言，管理这个不断增长的身份生态系统不仅仅是一个技术挑战，更是一个可见性挑战。

许多企业根本不知道在其环境中存在多少个 NHI、它们可以访问哪些系统，以及这些权限是否仍有必要。 AI 项目通常由专注于解决眼前挑战的单个部门、开发人员或业务部门推动。 长期身份治理很少被纳入讨论范围。

对于 MSP 而言，这正是专业知识转化为差异化优势的关键所在。

从历史上看，MSP 一直在帮助客户保护终端安全、管理基础设施并部署网络安全解决方案。 随着客户不断将 AI 整合到其运营中，他们将依赖值得信赖的顾问来帮助管理这些技术所带来的凭据、权限和机器身份。

帮助客户应对这一转变，首先要提出一系列不同的问题：

• 目前有哪些 AI 应用程序拥有对关键业务系统的访问权限？
• 目前仍需要哪些服务账号和 API 密钥？
• 每个机器身份的所有者是谁？
• 权限是否符合最低特权原则？
• 如何轮换、监控和保护凭据？

通过发起这些讨论，并在 AI 环境演进的过程中重新审视这些问题，MSP 可以将其角色从技术提供商提升为战略顾问。 通过帮助客户管理与 AI 相关的身份，MSP 可以在推动负责任的 AI 应用的同时，最大限度地降低长期风险。

KeeperMSP 如何帮助客户构建安全的 AI 基础架构

理解问题只是第一步。 帮助客户解决这一问题需要合适的身份安全基础。

对于 MSP 而言，这意味着帮助客户实施一个能够统一管理人类身份和机器身份的特权访问的框架。 这意味着要保障凭据安全、强制执行最低特权访问、保护机密信息、监控特权会话，并在整个身份生命周期中保持可见性。

MSP 不应将与 AI 相关的访问视为独立的安全挑战，而应鼓励客户将其纳入更广泛的身份安全战略中。 无论访问权限属于员工、应用程序、AI 智能体还是自动化工作流，都应适用相同的核心原则：验证访问权限、实施最低特权、保护凭据并持续监控活动。 统一的方法可以降低复杂性，同时确保客户在环境不断发展的过程中保持一致的安全控制措施。

KeeperMSP 在构建时考虑了这些挑战。 Keeper 通过其零知识安全架构、企业密码管理、特权访问管理 (PAM)、机密管理和安全远程访问功能，能够帮助服务提供商协助客户保护攻击者最喜欢攻击的凭据、机密和特权访问路径。 MSP 无需依赖彼此独立的工具，即可通过基于零信任原则和持续访问治理构建的单一平台来管理人类身份与机器身份。

对于 MSP 而言，其价值远远超出了技术本身。 它提供了所需的可见性、控制力和可扩展性，帮助客户拥抱 AI，同时避免其身份攻击面超过安全策略的发展速度。

每一次 AI 部署都会带来新的身份安全风险

每一次 AI 部署都会扩展组织的身份生态系统，随之而来的，是必须以与管理人类身份同样的严格标准来管理每个新身份的责任。 尽早认识到这一关联的组织将能够更好地进行创新，而不会不必要地扩大其攻击面。

对于 MSP 而言，帮助其托管的公司理解并治理这些身份，远不止是部署另一项技术那么简单。 这使得 MSP 处于自云计算兴起以来网络安全领域最重大变革之一的前沿。 通过帮助客户应对 AI 带来的挑战，MSP 可以巩固其作为不可或缺的顾问的角色，同时使组织能够在不削弱可见性或控制力的前提下跟上创新的步伐。

因为每一次 AI 部署，带来的都不仅仅是一项新功能。 它引入了另一个需要保护的身份。

探索 Keeper MSP 合作伙伴计划，了解其如何帮助 MSP 应对 AI 日益扩大的身份足迹。