AI代理治理应放在数据层

关键信息

文章强调了现有控制手段，包括基于角色和属性的访问控制、行级和列级安全、分类与脱敏、策略即代码以及完整审计日志。文章还认为，应将代理视为具有独立身份和声明目的的主体，这样策略引擎才能在查询时对其进行评估。

资讯摘要

文章认为，企业正在赋予 AI 代理更高的自主性，使其无需人类逐步批准，就能在多个系统之间规划、决策并执行操作。这样一来，架构评审中最关键的问题就变成了：当代理尝试执行一项它根本没有被授权的动作时，究竟是什么能真正阻止它？作者强调，责任不能靠事后补救，也不能靠只写在纸面上的抽象策略来承担。相反，治理必须变成可执行的规则，并在代理真正查询和操作数据的业务数据层强制落实。

文章用“永远不要打开车门”的类比说明，规则的含义会随着上下文变化而改变，因此代理需要的是具备上下文感知能力的规则，而不是僵硬的指令。文章还指出，放在模型之上的控制手段有其局限，因为自主行为本身就更难预测，尤其是在代理能在毫秒级跨多个系统行动时。随后，文章把访问控制、脱敏、策略即代码和审计日志等数据层机制描述为真正的执行点。文章最后提出，身份系统应把代理本身视为一个主体，并在会话开始时声明目的，这样策略既能判断是谁在操作、碰了什么数据，也能记录它自称为何而来。

资讯正文

<p><i>由 EDB 提供 </i></p><hr /><p>随着企业赋予 AI agents 更大的自主性——即无需人工逐步审批，就能跨系统进行规划、决策和行动的能力——一个棘手的问题正成为每次架构评审的核心：当某个 agent 试图完成一项它从未被授权执行的操作时，到底是什么真正阻止了它？</p><p>这些是你的 agents，运行在你的模型上，在你的基础设施中接触你的数据——而它们所做事情的责任在你身上。这种责任无法事后补救，也无法依靠一套只存在于纸面而非实践中的抽象政策来承担。Agents 需要在当下语境中适用的规则，因为它们不会对自己的行为作出覆盖性判断。</p><p>想想一个简单的规则：永远不要打开车门。如果机械地照字面执行，agent 便永远无法上下车。但如果改变语境（车刚刚撞车起火，有人受伤需要撤离），那么你真正想要的规则恰恰相反。此刻的上下文就是一切。我们要求 agents 做智能的事；这就需要智能的规则。</p><p>直觉上，人们会想在 agent 周围加上护栏：在模型之上叠加指令、政策和监控。这些机制固然重要，但它们有一个结构性限制：车门规则在你真正必须决定是否开门之前都显得合理。位于 agent 层的控制措施，其可靠性只和 agent 输出的可预测性一样高，而自主性恰恰是使这种输出难以预测的特性。依赖在动作发生之前进行审查的治理，无法跟上一个能在毫秒级、同时跨多个系统行动的系统。</p><p>治理必须变得<i>可执行</i>，并且要在 agents 真正开展工作的地方强制实施：在运营数据层，在上下文中，并且就在事情发生的那一刻。</p><h2>数据层就是执行点</h2><p>Agents 通过接触数据来创造价值。它们查询数据、检索数据、转换数据，并且越来越多地直接对数据采取行动。一项规定 agent 不应接触某类数据的政策，只有在系统能在 agent 请求访问的那一刻拒绝它时才有意义。同样，一条要求 AI 必须可审计的原则，也只有在组织能够重建 agent 做了什么、接触了哪些数据、代表哪个用户采取行动以及最终结果如何时才有意义。当<a href="https://www.enterprisedb.com/products/data-ai-governance">治理</a>存在于数据层时，无论 agent 是如何构建的、行为如何，它都能成立，因为控制能力是数据库本身的属性，而不是 agent 做出的承诺。</p><h2>Agent 的行为可以是概率性的。治理不能是</h2><p>企业不应依赖模型自行选择遵循政策。政策必须由系统强制执行。

这就是“希望一个行为体会守规矩”和“从一开始就构建它无法跨越的边界”之间的区别。

让这一切成为现实的控制措施，很多企业其实已经在数据层运行：基于角色和属性的访问控制、行级和列级安全、分类与掩码、代码即策略，以及完整的审计追踪。

代理带来的变化不是机制本身，而是这个机制必须识别的对象。身份管理必须把代理视为一个独立的主体，为它分配自己的身份，并在会话开启时声明其目的。

一旦目的与身份绑定，策略引擎就可以像今天评估角色或部门一样评估它，而发生了什么的记录也不仅能记下是谁采取了行动、接触了什么，还能记录它声称自己来这里要做什么。

在实践中，这可以归纳为九项控制措施，分为三项要务：

**强制执行**

- 在查询时对代理和用户都强制执行基于角色和属性的访问控制

- 由同一路径的策略驱动动态列掩码

- 将代理身份作为一等主体，在会话开始时绑定声明的目的，并保留实际操作的用户

**可见且可证明**

- 驱动策略的分类与标签

- 会话级审计日志，记录哪个代理采取了行动、为哪个用户、以及在什么声明目的下行动

- 跨管道的血缘追踪，以便将结果追溯到生成它的请求

**统一并加固**

- 集中式、可移植的策略管理

- 静态和传输中的加密

- 在本地部署、云端以及主权或空气隔离环境中保持一致的强制执行

“声明的目的正是关键所在。它会成为访问层已经理解的一项属性，并在与角色和行级安全相同的策略路径中被评估。强制机制本身并没有改变。变化的是，代理的目的成为它所评估内容的一部分，也成为事后记录所能证明的一部分，”EDB 数据与 AI 治理产品管理副总裁 Priyanka Jain 说。

无论你处于 AI 采用旅程的哪个阶段，在数据层实施强制执行，都会让你更快而不是更慢地推进。这些控制措施本来就已经在数据库中。不同之处在于，如今代理也必须通过它们的约束。

**不是一扇上锁的门，而是一条数字牵引绳**

目标不是阻止代理完成有用的工作。而是定义一个代理可以走多远、它可以接触什么、可以更改什么、什么情况需要升级处理，以及如果出了问题，组织如何重建事件经过。以这种方式治理时，代理是可识别的、范围受限的、可监控的，并且可审计。

企业可以更快地采用它们，因为安全、风险和领导团队信任其下方的运行模型。

开放、主权，并且可在源头强制执行

基于开源 Postgres 构建，这一开放基础使企业能够掌控数据存放的位置、谁可以访问数据，以及数据适用的政策，而无需将治理让渡给自己不拥有或无法审查的某一层。对于受监管行业而言，数据主权和源头级强制执行的这种组合并不是锦上添花；它是将智能体投入生产环境的前提条件。

Agentic systems 将会变得越来越强大、越来越自主。这恰恰说明要审慎决定控制权应当放在哪里，而不是说明应该放慢脚步。那些在数据层强制执行治理的企业，可以更激进地推进 AI，因为保护其数据的东西不只是空想。

EDB Postgres AI 是一个开放、企业级的主权数据与 AI 平台，将事务型、分析型和 AI 工作负载统一在一起——并在数据所在之处强制执行治理。完整框架请参见 EDB 的白皮书《Governing Agentic AI at Enterprise Speed》。

Max Romanenko 是 EDB 的首席技术官。

来源与参考

1. 原始链接
2. When agents act on their own, governance has to live in the data layer