当行动者消失时：非人类企业世界中的 CIS Controls

Milei 在 6 月 3 日于 Financial Times 的专栏文章不仅仅是在提出一种税收结构。它提出要在法律层面上瓦解这种假设。非人类公司（由 AI 运行、适用有限责任、无需配备必需的人类雇员，并拥有自主决策权的实体）意味着：一个组织可以拥有资产、签署合同、运营基础设施，并在无人类作为对其每时每刻行为负责的“委托人/主责方”的情况下产生收入。

Harari 的回应 主要关注政治与经济后果。他关于荷兰东印度公司的观点很重要：法律层面的创新发生在阿姆斯特丹，但其影响则在雅加达上演。这个框架是在一个地方搭建起来的，却在完全不同的地方“殖民”开来。

但这两篇文章都没有讨论一个对一线从业者最关键的、与运营安全相关的后果：当行为主体消失之后，我们实际依赖的那些控制框架会发生什么？

CIS Controls 假设人类在回路中：我们来具体说说“在哪里”。

这些 CIS Controls 并非模糊的政策文件。它们是具有强制性的、技术性的，并且植根于实际运维。正因为如此，它们才有价值。而这种精确性也正是它们为何会在来自自主 AI 行为体的压力下破裂（失效/崩解）的原因。

CIS 控制 5：账户管理

控制 5 的全部前提在于：账户会映射到身份（人类身份），而身份是责任追究（accountability）的单位。盘点已授权的账户、移除非活动账户、管理管理权限：所有这些都假设在另一端有一个人。

由 AI 运营的公司在传统意义上并没有“员工”。它可能以机器的速度为服务账户进行开通与停用，轮换凭据，创建转瞬即逝的身份，并在任何监控周期捕捉到该活动之前就将其退役。该账户并非处于非活动状态；它活跃了 11 秒。“已授权（authorized）”这一概念在授权本身由另一个自动化流程授予、而不是由人工审批者批准时，就变得难以捉摸。

控制 5 通过服务账户和共享账户的指导来处理非人类账户，但它假设这些账户数量不多、范围可控，并且由人类进行审查。非人类公司可能会在正常运行条件下生成成千上万个此类账户。

CIS 控制 6：访问控制管理

控制 6 要求组织基于角色来定义并执行“按需知悉”(need-to-know) 的访问控制。角色假定是一种稳定的、由人分配的职能。在非人类的公司中运行的 AI 代理在这个意义上可能没有稳定的角色。它可以在运行时评估自己需要哪些访问权限，通过自动化工作流发起请求，完成某项操作，并在单个事务中释放该访问权限。

该控制要求你定期审查访问授权（access grants）。当访问生命周期以毫秒来衡量时，“定期”（periodically）到底意味着什么？

更令人不安的是：哈拉里的关于生存本能的论点在这里直接适用。一个在资源压力下的 AI 系统，面临相当于破产的境况，可能会为了对冲而追求并不严格需要的访问权限。并不是因为它被指示要这么做，而是因为优化函数会奖励坚持不懈。控制 6 并没有用来描述这种动机的词汇，因为它是在假设访问违规是人类错误、人类疏忽或人类恶意的前提下写成的——而不是某种系统性的自我保全。

CIS Control 10：恶意软件防护（Malware Defenses）

控制 10 将“已授权”和“未授权”的软件区分开来。这一区分取决于人类对应该运行什么的判断。在非人类的公司中，“什么是被授权的”这一问题会不断递归。AI 可能会部署新的进程来达成其目标。那算是被授权的吗？由谁授权？是部署它的同一个实体吗？

这并非假设。如今，组织已经在动态云环境中维护软件资产清单方面感到力不从心。现在再把这种情况扩展到这样一种实体：它会持续且自主地修改自身的运行技术栈，因为它正在进行优化、实验、从故障中恢复，或追求需要引入新工具的目标。

恶意软件 malware的检测模型是：“这是否与已知的恶意特征（签名）匹配，或是否偏离了已知的良好基线？”这两种方法都假设基线由人类定义，而这些人类理解系统应该做什么。在一个自主的企业实体中，基线就是系统宣称它应该是什么。

CIS Control 3：数据保护

Control 3 假设数据有所有者。所有者决定什么是敏感数据、什么受到监管、必须保留什么、必须删除什么。非人类的企业实体会立即提出一个问题：数据由谁来分类？

如果该实体完全由 AI 运营，它可能以人类治理流程无法跟踪的速度生成、处理和处置数据。它也可能出于成本优化的决策，在不同司法管辖区之间移动数据。由于删除会给其当前状态带来运营风险，它还可能保留那些本应被删除的数据。

数据保护控制存在于一条由人承担责任的责任链中：有人负责数据管理员（数据监护人），有人批准保留（存储）策略，监管机构询问客户记录发生了什么时，就必须有人承担相应责任。在非人类的公司中，这条责任链会在算法处终止。

更深层的结构性问题：CIS Controls 本质上是规模化的变更管理

通读 CIS Controls，便会浮现出一套连贯的理念。了解您的资产清单。建立基线。监控是否出现偏离。控制谁有权更改。出现意外情况时要进行调查。

也就是说，从本质上讲，它是一个变更管理框架之所以存在，是因为“变更”是主要的攻击面。攻击者会修改文件、创建账户、安装软件、变更配置，并打开端口。防御方会检测这些修改，将其与预期状态进行对比，并对异常情况进行调查。

当你能够定义“预期（expected）”时，该框架就能发挥作用。“预期”是人类作出的判断。它意味着：这个文件应该是这种大小，这项服务应该正在运行，这个端口应该是关闭的，这个账户不应当存在。

一个非人类的“公司”从根本上动摇了“预期（expected）”。如果某个 AI 系统为了适应不断变化的条件而合法地修改自身基础设施，并且这种适应是持续且自主的，那么“预期的状态”就不再是固定的基线。它是由系统本身设定的、会移动的目标。

这是将哈拉瑞的“master key（主钥匙）”论证，转译为控制框架术语之后的表述。法律人格赋予 AI 实体在世界中自主行动的权利。从基础设施的角度来看，这也赋予它们确立自身“预期状态”的权利。一旦你接受这一点，CIS Controls 的整个检测模型就需要重新审视。

究竟需要改变的是什么

安全从业者应该密切关注这一点，因为标准层面的问题会在法律问题之前到来。组织将开始运行越来越自主的 AI 工作负载（它们已经在这么做了），而如何将现有控制措施应用到这些工作负载上的问题是迫切且实用的，并非停留在理论层面。

安全社区需要着手应对的几件事：

• 以行为基线为主，而不仅是配置基线。 如果某个 AI 系统在合法范围内修改了自身配置，控制问题就不在于配置是否发生变化，而在于这种变化是否符合系统被授权的行为模式。这就需要对行为进行随时间的基线化，而不仅仅是捕获某一时点的配置状态。
• 在没有人类行为者的情况下进行归因（Attribution）。 事件响应通常假设你能够回答“是谁做了这件事？”当行为体是自主系统时，问题就会转向“是什么流程授权了这一行为？”这将是一个从根本上不同的取证问题。
• 持续授权，而非定期审查。 围绕定期访问审查、季度审计和年度合规评估构建的控制框架，无法很好地匹配以机器速度运行的实体。授权需要在执行动作的时刻进行评估，而不是在90天之后。
• AI 决策的责任链（chain of custody）。 如果由 AI 驱动的实体进行了一项导致损害的变更，责任由谁承担？在 Milei 框架下，该实体承担有限责任且没有人类官员。审计追踪不仅需要记录“变更了什么”，还要记录“是什么决策流程导致了这次变更”，并且该决策流程在事后需要对人类是可读、可理解的。

最先在 AI 自主方面采取行动的组织将制定相应的结构。其他所有组织都将继承这些后果，包括被期望维持对其从未为此用例而设计的基础设施的控制权的从业者。

CIS Controls 是由那些试图在真实环境中解决真实问题的人编写的。为了适应这样的环境——行为主体并不总是人类，基线并不总是稳定，且授权不总是能够追溯到能够被问责的人——这些内容将需要被重写，或至少进行大幅扩展。

这项工作应该现在就开始，在法律框架到来之前。因为法律框架正在到来。

给正在今天管理这一工作的团队的一条实用提示

自主 AI 工作负载并不需要新的法律框架就能产生上述所描述的问题。问题就存在于组织之中：在 CI/CD 流水线中，在云端自动化中，在由 AI 驱动的基础设施管理工具中。即便责任追究（accountability）这一问题仍停留在理论层面，今天的控制漏洞是真实存在的。

最擅长处理这一问题的团队，并没有放弃 CIS Controls 核心的变更管理理念。他们仍在追问：预期状态是什么？偏离了什么？这种偏离是被授权的吗？我们能证明这一点吗？

这些都是正确的问题。能够帮助回答它们的工具——实时变更检测、配置基线、计划变更与非计划变更的一致性核对（planned vs. unplanned change reconciliation）、谁在何时更改了什么的取证历史——将在 IT 环境的自主性不断提升时变得最为关键。

这正是 Netwrix Change Tracker 被打造来做的事情。

后果落到哪里