当 Agent 自主行动时，治理必须落在数据层

由 EDB 提供

随着企业赋予 AI Agent 更高的自主权——即能够在无需人工逐步审批的情况下，跨系统进行规划、决策和行动——一个棘手的问题开始成为每次架构评审的核心：当 Agent 尝试完成一项它从未获得授权的操作时，究竟是什么能真正阻止它？

这些 Agent 属于你，运行在你的模型上，接触的是你基础设施中的数据——而它们行为的责任由你承担。这种责任不能靠事后补救来履行，也不能依赖一套只停留在纸面、没有落地实践的抽象政策。Agent 需要基于当下情境的规则，因为它们无法自行对自身行为作出凌驾于规则之上的判断。

设想一条简单规则：永远不要打开车门。如果严格照字面执行，Agent 将根本无法上下车。但一旦情境发生变化——汽车刚刚发生事故、车辆起火，或者有人受伤需要离开车辆——你真正希望执行的规则恰恰相反。实时情境决定一切。我们要求 Agent 做智能的事情；这也要求规则足够智能。

人们本能的做法是在 Agent 周围增加护栏：在模型之上叠加指令、政策和监控。这些机制很重要，但它们有共同的结构性局限：在你真正需要决定是否打开车门之前，“不要打开车门”这条规则看起来一直都很合理。Agent 层的控制，其可靠性取决于 Agent 输出的可预测程度；而自主性恰恰意味着输出难以预测。依赖于在操作发生前审核操作的治理方式，无法跟上一个能够在毫秒间、同时跨多个系统行动的系统。

治理必须变得_可执行_，并且应在 Agent 实际开展工作的地方执行：在运营数据层中，结合上下文，并且恰好在操作发生的那一刻。

数据层是执行点

Agent 通过接触数据创造价值。它们查询、检索、转换数据，并且越来越多地对数据采取行动。一项规定 Agent 不应访问某类数据的政策，只有当系统能在 Agent 发出请求的那一刻拒绝访问时才有意义。同样，一项要求 AI 必须可审计的原则，只有当组织能够重建 Agent 做了什么、接触了哪些数据、代表哪位用户行动，以及产生了什么结果时才有意义。当治理落在数据层时，无论 Agent 是如何构建或如何行为，治理都能成立，因为控制是数据库本身的属性，而不是 Agent 作出的承诺。

Agent 的行为可能是概率性的，治理不能如此

企业不应依赖模型自行选择遵守政策。政策必须由系统强制执行。这就是希望行为者不越界，与从一开始就建立其无法逾越的边界之间的区别。

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

Agent 带来的变化并不在于机制本身，而在于这些机制需要识别的对象。身份管理必须将 Agent 视为独立的主体，赋予其自身身份，并在会话开启时声明其任务目的。

一旦任务目的与身份绑定，策略引擎便可像如今评估角色或部门一样对其进行评估；而事件记录不仅可以捕获谁采取了行动、接触了什么，还能记录其声明的行动目的。

在实践中，这可归纳为九项控制措施，分属三项关键要求：

强制执行

• 在查询时强制执行基于角色和属性的访问控制，适用于 Agent 和用户

• 由同一策略路径驱动的动态列脱敏

• 将 Agent 身份作为一等主体：在会话开始时绑定其声明目的，并保留实际操作用户的信息

可见且可证明

• 驱动策略的分类和标签机制

• 会话级审计日志，记录哪个 Agent 代表哪位用户行动，以及其声明的目的

• 覆盖数据管道的数据血缘能力，使结果能够追溯到生成该结果的请求

统一与加固

• 集中化、可移植的策略管理

• 静态与传输中的加密

• 在本地部署、云环境以及主权或物理隔离环境中保持一致的强制执行

“声明目的带来了关键差异。它成为访问层已经能够理解的一项属性，并沿着与角色和行级安全相同的策略路径进行评估。强制执行机制本身并未改变。改变的是，Agent 的目的成为系统评估内容的一部分，也成为事后记录能够证明内容的一部分。”EDB 数据与 AI 治理产品管理副总裁 Priyanka Jain 表示。

无论你的 AI 采用之旅处于哪个阶段，在数据层实施强制执行，都能让你加快而非放慢推进速度。控制机制已经存在于数据库中。不同之处在于，Agent 现在必须通过这些控制机制。

数字缰绳，而非上锁的门

目标不是阻止 Agent 完成有价值的工作，而是界定 Agent 能走多远、能够接触什么、能够修改什么、哪些操作需要升级处理，以及在出现问题时组织如何重建事件经过。以这种方式治理后，Agent 具备明确身份、权限范围、监控机制和可审计性。企业能够更_快速_地采用它们，因为安全、风险和管理团队信任其底层运行模式。

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

基于开源 Postgres 构建，这一开放基础使企业能够持续掌控数据存放位置、谁能够访问数据以及适用何种策略，而无需将治理权让渡给一个自身不拥有或无法检查的层。对于受监管行业而言，数据主权与源头级强制执行的结合并非锦上添花，而是将 Agent 投入生产环境的前提条件。

Agentic 系统将持续变得更强大、更自主。这是应当审慎决定控制权部署位置的理由，而不是放慢脚步的理由。在数据层强制执行治理的企业，可以积极推进 AI，因为保护其数据的机制不只是美好的愿望。

EDB Postgres AI 是一个开放、企业级的主权数据与 AI 平台，将事务处理、分析和 AI 工作负载统一起来，并在数据所在之处强制实施治理。完整框架请参阅 EDB 白皮书 《以企业级速度治理 Agentic AI》。

Max Romanenko 是 EDB 首席技术官。

Presented by EDB

As enterprises give AI agents more autonomy — the ability to plan, decide, and act across systems without a human approving each step — a hard question moves to the center of every architecture review: When an agent tries to complete an action that it was never authorized to do, what actually stops it?

These are your agents, running on your models, touching your data in your infrastructure — and the responsibility for what they do sits with you. That responsibility can’t be met in hindsight or with a set of abstract policies that live on paper but not in practice. Agents need rules in the context of the moment, because they don’t exercise overriding judgment of their own actions.

Consider a simple rule: Never open the car door. Followed literally, an agent could never get in or out of the car at all. But if you change the context (the car has just crashed, there’s a fire, someone is hurt and needs to get out), then the rule you actually want is the opposite. Context in the moment is everything. We are asking agents to do intelligent things; that requires intelligent rules.

The instinct is to add guardrails around the agent: instructions, policies, and monitoring layered above the model. Those mechanisms matter, but they share a structural limit: The car-door rule is plausible right up until the moment you actually have to decide whether to open the door. Controls at the agent layer are only as reliable as the agent’s output is predictable, and autonomy is precisely the property that makes that output hard to predict. Governance that depends on reviewing an action before it happens cannot keep pace with a system that acts in milliseconds, across many systems at once.

Governance has to become executable , and enforced where agents actually do their work: at the operational data layer, in the context, and exactly at the moment it is happening.

The data layer is the enforcement point

Agents create value by touching data. They query it, retrieve it, transform it, and increasingly act on it. A policy that says an agent should not reach a certain class of data is meaningful only if the system can deny that access at the moment the agent requests it. Additionally, a principle that says AI must be auditable is meaningful only if the organization can reconstruct what the agent did, what data it touched, which user it acted for, and what resulted. When governance lives at the data layer, it holds regardless of how the agent was built or how it behaves, because the control is a property of the database itself, not a promise made by the agent.

Agent behavior may be probabilistic. Governance cannot be

The enterprise should not rely on a model choosing to follow policy. The policy has to be enforced by the system. That is the difference between hoping an actor stays in bounds and constructing bounds it cannot cross to begin with.

The controls that make this real are ones many enterprises already run at the data layer: role- and attribute-based access, row- and column-level security, classification and masking, policy as code, and complete audit trails.

What agents change is not the mechanism, but who the mechanism has to recognize. Identity management has to treat the agent as a principal in its own right, with its own identity and a purpose declared when the session opens.

Once purpose is bound to identity, the policy engine can evaluate it the same way it evaluates role or department today, and the record of what happened can capture not just who acted and what they touched, but what they declared they were there to do.

In practice, this resolves into nine controls, grouped under three imperatives:

Enforce it

• Role- and attribute-based access control enforced at query time, for agents as well as users

• Dynamic column masking driven by the same policy path

• Agent identity as a first-class principal, with declared purpose bound at session start and the acting user preserved

See it and prove it

• Classification and tagging that drives policy

• Session-level audit logging that records which agent acted, for which user, and under what declared purpose

• Lineage across pipelines, so a result can be traced back to the request that produced it

Unify and harden

• Centralized, portable policy management

• Encryption at rest and in transit

• Consistent enforcement across on-prem, cloud, and sovereign or air-gapped environments

“Declared purpose is what makes the difference. It becomes an attribute the access layer already understands, evaluated in the same policy path as role and row-level security. The enforcement mechanism does not change. What changes is that the agent's purpose is part of what it evaluates, and part of what the record proves afterward,” says Priyanka Jain, VP, product management, data & AI governance, EDB.

Wherever you are in your AI adoption journey, enforcement at the data layer is what lets you move faster rather than slower. The controls are already in the database. The difference is that agents now have to pass through them.

A digital leash, not a locked door

The goal is not to stop agents from doing useful work. It is to define how far an agent can go, what it can touch, what it can change, what requires escalation, and how the organization can reconstruct events if something goes wrong. Governed this way, agents are identified, scoped, monitored, and auditable. The enterprise can adopt them faster , because security, risk, and leadership teams trust the operating model underneath.

Open, sovereign, and enforceable at the source

Built on open source Postgres, this open foundation keeps enterprises in control of where their data lives, who can reach it, and under what policy, without ceding governance to a layer they don’t own or can’t inspect. For regulated industries, that combination of data sovereignty and source-level enforcement isn’t a nice-to-have; it’s the precondition for putting agents into production at all.

Agentic systems will keep getting more capable and more autonomous. That is a reason to be deliberate about where control lives, not a reason to slow down. The enterprises that enforce governance at the data layer can move aggressively on AI, because the thing protecting their data is more than just wishful thinking.

EDB Postgres AI is an open, enterprise-grade sovereign data and AI platform that unifies transactional, analytical, and AI workloads — with governance enforced where the data lives. For the full framework, see EDB’s white paper Governing Agentic AI at Enterprise Speed .

Max Romanenko is Chief Technology Officer at EDB.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com .