跳转到主要内容

策略驱动的隔离:操作系统执行层能决定什么,不能决定什么

主机级隔离能够强制执行资源与文件系统边界,但无法判断某个 agent 操作是否获得授权。应将执行层与授权层分离。

A close-up view of a neoclassical building facade featuring detailed arches and columns.

隔离所混淆的两个问题

隔离回答的是一个狭窄的、机械性的问题:这个进程能触碰什么?授权回答的是另一个问题:这个操作是否在委托授权范围之内?这不是同一个问题,而操作系统执行层并不具备回答第二个问题的能力。

诸如 Windows Execution Containers 这样的主机级原语,或它所基于的更早的 Job Object 和 AppContainer 机制,作用于系统调用、句柄、令牌和 SID。它看到的是一个进程请求文件句柄、注册表项、网络套接字、内存分配。它看不到意图、任务范围、用户同意,也看不到 agent 在其被分配的工作区内合法编辑文档与同一 agent 因 prompt injection 被重定向而将该文档外泄之间的区别。内核没有"此操作在授权范围内"的表示。它只有"此句柄被授予或被拒绝"的表示。

这一区分之所以重要,是因为在交付压力下的团队经常将其混为一谈。配置了一个沙箱,沙箱阻止了对目录之外的写入,团队便认定治理已经到位。而实际上构建出来的只是一个隔离边界。授权的审计轨迹——谁在哪个任务下、针对哪些数据类别批准了什么——如今存在于沙箱配置中,或者更糟,根本不存在于任何一层中。当事件复盘追问为什么某个 agent 读取了它本无权读取的客户记录时,答案并不在隔离日志中。隔离日志只显示一次读取成功了。

边界实际位于何处

Close-up of hands signing a contract on a desk with office supplies, symbolizing legal agreements.

这两层具有相反的优势。内核级原语在隔离上强,在语义上弱。容器可以可靠地阻止进程写入 C:\\Windows\\System32、打开原始套接字,或派生一个继承其令牌的子进程。它无法告诉你该进程是否本应做这些事。策略引擎则相反:语义上强,执行上弱。策略引擎可以评估"此 agent 持有针对任务 invoice-reconcile-4417 的授权,范围限定为 finance 数据类别,十五分钟后过期",并判定对供应商账本的读取在范围内。但它本身无法阻止一次系统调用。如果策略引擎被绕过,或者是在事后才被查询,写入早已落地。

因此,两者之间的接口才是真正重要的设计面。静态允许列表——沙箱允许的一组固定路径和主机——是错误的形态,因为它没有任务的概念、没有过期时间,也无法表达同一 agent 在不同任务中应拥有不同权限。正确的形态是签名能力授权:一种由策略层签发、提交给执行层、并在使用点进行校验的结构化令牌。授权至少携带任务标识符、范围(哪些数据类别、哪些路径、哪些网络目的地)、过期时间以及终止状态。执行层校验签名和范围;它不重新解释授权内容。

这接近于操作系统数十年来一直使用的能力模型,只是应用于 agent 工作负载。策略层成为能力的签发者;操作系统层成为引用监视器。两者单独都不充分。

分层隔离的设计规则

每项授权都携带任务范围、数据类别和终止状态。 一项写着"此 agent 可以读取 D:\\data"的授权不是授权,而是一个永久漏洞。一项写着"任务 invoice-reconcile-4417 可以读取数据类别 finance-vendor-ledger,直到 UTC 14:32,之后该能力被撤销且进程被终止"的授权才是可审计的。终止状态与范围同样重要:完成任务的 ag

Explore the stunning architecture of Budapest's Parliament Building, a UNESCO World Heritage Site in Hungary.

在操作系统层默认拒绝;在策略层按例外授权。 容器应以无文件系统、网络或设备访问启动,仅通过授权接口获得能力。策略层也应从拒绝姿态出发,仅当任务定义、数据分类标签以及用户或服务同意记录三者一致时才签发授权。这颠倒了常见模式,即沙箱是宽松的,而策略层只是事后日志。

将授权与执行决策分开记录。 这是两个不同的事件,有两个不同的归属方。授权日志记录策略层基于同意记录 W 的授权,为任务 X、范围 Y、过期时间 Z 签发了一项能力。执行日志记录操作系统层在该能力下允许或拒绝了某个具体的句柄请求。当事件发生时,授权日志回答"这是否获得授权?",执行日志回答"边界是否守住了?"将它们合并为一条流会丧失将故障归因于策略层或执行层的能力,而这恰恰是复盘时所需的归因。

诚实的权衡

分层隔离会带来延迟和复杂性。每一次能力检查都是一次到策略层的往返,或是对签名令牌的一次校验,而每个任务都需要一个包含签发、刷新和撤销的授权生命周期。跳过这些、依赖单一宽松沙箱的团队交付更快,并且在一段时间内看起来运转正常。其失效模式不是戏剧性的入侵;而是无人能够枚举的常驻权限缓慢累积,随后发生一次事件,其中隔离日志完整无缺,而授权记录一片空白。

令人不安之处在于,操作系统执行层永远无法决定授权,因为授权是关于人类意图和组织授权的陈述,而内核无法访问其中任何一项。它最多只能忠实而迅速地执行在别处做出的决定。设计两层之间的接口——授权格式、校验点、撤销路径、分离的日志——才是真正的工程工作。将沙箱视为治理控制,是一条捷径,它把审计轨迹从策略层移出,搬进一个无人审阅的配置文件。

一个有用的测试:选取你的系统今天允许的任意一个 agent 操作,问两个问题。哪一层判定它被允许,哪一层使它成为可能?如果同一层回答了这两个问题,那么边界并未分层,而下一次事件复盘将不得不从从未被设计来承载授权的执行日志中重建授权。

分享XLinkedIn永久链接5 分钟阅读

相关阅读

这能回答的问题

Can a sandbox alone govern what an LLM agent is allowed to do?

No. A sandbox enforces what a process can touch at the syscall and handle level. It cannot determine whether an action was within a delegated mandate, because it has no representation of task scope, data classes or user consent. Governance requires a separate policy layer that issues and revokes capabilities.

What should a capability grant contain?

At minimum a task identifier, a scope covering data classes and reachable paths or destinations, an expiry, and a terminal state that revokes the capability when the task ends. The enforcement layer validates the signature and scope; it does not reinterpret the mandate.

Why log grants and enforcement decisions separately?

The grant log answers whether an action was authorised and by which consent record. The enforcement log answers whether the boundary held. Keeping them separate preserves attribution during an incident review; merging them loses the ability to tell a policy failure from an enforcement failure.