为你工作的 AI 代理很可能比你拥有更多的访问权限

AI 并没有在做销售代表的工作。它只是销售代表使用的一种工具。但是，这个工具最终能触达系统的范围，往往比它所服务的那个人更广。正是这种差距——一个具有范围性权限的人类，使用一个 non-human identity 且拥有更广访问权限的主体——正在成为企业部署 AI 的常见形态，而几乎没有人会像审查个人权限那样去审查它。

Netwrix 的 2026 Data & Identity Security Report 基于对 2,317 位安全与 IT 领导者的调研，给出了这一趋势背后的数据。72% 的组织表示与身份相关的数据暴露风险有所增加。58% 表示，与以前相比，现在拥有企业数据访问权限的身份数量更多。41% 已在生产环境中运行 agentic AI，这些代理会代表人类对敏感数据采取行动。non-human identities 不是未来才会出现的问题；在许多环境中，它们已经是多数关键相关方。

在访问审查中看不到的那部分

大多数身份治理（identity governance）计划都是围绕“入职-调岗-离职”的节奏构建的。有人入职——访问权限随之增加或变动；最终他离职，权限就会被撤销。 Service accounts、API 密钥、证书和自动化令牌并不遵循这种模式。它们是在部署过程中创建的，继承自当时最快搭建起来的任何模板，然后由于没有人负责后续维护，就被放任不管。

该报告对此提供了佐证。只有 19% 的组织表示能够完全治理非人类身份（non-human identities）。当不再需要时，76% 的组织无法立即撤销持续（standing）的访问权限。64% 的组织至少有一部分对关键数据的访问权限被过度配置（overprovisioned）。把这些情况叠加起来，你会发现：凭证（credentials）的数量比人类劳动力还要庞大，更难追踪，而且几乎从不被复核。

这个问题还有一种值得特别点明的具体形态：基于证书的身份验证（certificate-based authentication）正在成为 AI 代理（AI agents）和自动化的主要信任机制，但大多数组织对其背后所依赖的证书基础设施（certificate infrastructure）缺乏足够的可视性。配置错误的模板（Misconfigured templates）、过于宽松的注册权限（overly permissive enrollment rights）以及 Active Directory Certificate Services 中继承的信任关系（inherited trust relationships），都可能让攻击者在不接触任何密码的情况下冒充特权身份（privileged identity）。

为什么这不是“身份（identity）”问题，而是变更管理问题

这里有一个容易被忽视的关键点。服务账户（service account）的权限、证书的信任链（trust chain）、API 密钥（API key）的权限范围（scope）——它们都不只存在于某个身份平台（identity platform）中。它们存在于真正运行该账户的系统上的配置文件、注册表项（registry keys）、证书存储区（certificate stores）以及计划任务（scheduled tasks）。当合规要求发生变化时，无论是新的 PCI DSS 要求、更新后的 NIST 控制（NIST control），还是 NERC CIP 的修订（revision），访问审查（access review）和撤销步骤（revocation step）都应该一起进行。实际上，往往只有“身份”侧受到关注，而“配置”侧则在后台悄悄偏离。

这种偏离（drift）正是未授权变更（unauthorized change）隐藏的地方。例如：一个注册表项（registry key）给服务账户（service account）授予了比其所需更宽松的注册权限（enrollment rights）；一个配置文件仍指向已退役（decommissioned）的集成（integration）；以及一个在六个月前被编辑过的证书模板（certificate template），却从未被任何人标记为需要复核（review）。这些都不会出现在访问认证（access certification）的电子表格中。只有当有人去查看系统上实际发生了什么变化时，它们才会浮现出来。

关注系统，而不仅仅是名单

正是在这里，file integrity monitoring 和安全配置管理才能真正融入讨论。 Netwrix Change Tracker 不负责管理身份，但会监控这些身份及其凭据所驻留的系统。它会对配置文件、注册表项和系统设置建立基线，然后在实时发现任何偏离该基线的更改时发出告警。当存在“Planned Change”规则时，无论该规则是与补丁窗口绑定，还是与已批准的 ServiceNow 请求关联，匹配的变更都会自动被过滤掉。剩下的就是未计划的活动：无人批准的注册表编辑、没有匹配变更请求的配置变更、以及原本会一直潜伏无声的漂移——直到审计或事件迫使有人去查找。

这种闭环模式通过 ServiceNow、BMC Remedy 和 Cherwell 等 ITSM 集成，将观测到的变更与已批准的变更进行匹配，为安全与合规团队提供了仅靠访问审查无法做到的东西：系统级的记录，明确发生了什么、何时发生，以及是否在预期之内。再结合与 PCI DSS、NIST、HIPAA、DISA STIG 等框架对齐的 250+ 份预置合规报告，这份记录就能把“我们认为控制措施在起作用”转化为审计人员可以真正核查的证据。

责任依然会落到销售代表身上

如果这个 Salesforce 集成遭到入侵，或者助手悄悄从其原定范围之外拉取数据，事故报告不会点名 AI 供应商。它只会点名完成认证的账号，以及与该账号关联的那个人。Identity governance 可以制定该账号应该被允许接触哪些内容的策略。但它无法单凭自身告诉你，去年周二系统里到底发生了哪些实际变更。这是另一个问题，而且仍然需要有人持续盯着，等着答案出现。