EDB argues AI agent governance must live in the data layer

VentureBeat published this piece as sponsored content, credited to Max Romanenko, Chief Technology Officer at EDB. It argues that as enterprises give AI agents more autonomy, the ability to plan, decide, and act across systems without a human approving each step, governance can no longer live only in guardrails layered above the model. It opens with a thought experiment about rules and context: a rule like 'never open the car door' holds until the car has just crashed, there is a fire, and someone hurt inside needs to get out. Agents, the article argues, need rules that hold up in the context of the moment, because they do not exercise overriding judgment of their own actions.

The piece argues that agent-layer controls (instructions, policies, and monitoring layered above the model) share a structural limit: they are only as reliable as the agent's output is predictable, and autonomy is exactly what 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, so governance has to become executable and enforced at the operational data layer, in context, at the moment an action is actually happening.

Concretely, that means a policy denying an agent access to a class of data is meaningful only if the system can deny that access the moment the agent requests it, and a claim that AI is 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. The article frames this as a matter of identity: agents need to be treated as principals in their own right, with their own identity and a purpose declared when a session opens, so the existing policy engine can evaluate that purpose the same way it already evaluates a human user's role or department, and the resulting record can show not just who acted and what they touched, but what they declared they were there to do.

The article resolves this into nine controls grouped under three imperatives. Under '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, and agent identity as a first-class principal with declared purpose bound at session start and the acting user preserved. Under '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, and lineage across pipelines so a result can be traced back to the request that produced it. Under 'Unify and harden': centralized, portable policy management, encryption at rest and in transit, and consistent enforcement across on-prem, cloud, and sovereign or air-gapped environments.

Priyanka Jain, EDB's VP of product management for data and AI governance, is quoted arguing that declared purpose becomes an attribute the access layer already understands, evaluated in the same policy path as role and row-level security, so the enforcement mechanism itself does not change; only what it evaluates, and what the audit record proves afterward, does. The piece closes by pointing to EDB Postgres AI, built on open source Postgres, as the product that enforces this model, and links to EDB's white paper, 'Governing Agentic AI at Enterprise Speed,' for the full framework. It names no enterprise or customer running the framework in production, cites no external study, survey, or benchmark, and names no specific competing product or agent-layer tool it is arguing against; the case is made entirely in the abstract, by the vendor whose product it promotes.

Key facts

The article argues that governance for autonomous AI agents has to be enforced at the operational data layer, because guardrails layered on top of the agent (instructions, policies, monitoring) cannot keep pace with a system acting in milliseconds across many systems at once.
It proposes treating each AI agent as a distinct identity principal with a purpose declared when its session opens, evaluated by the same policy engine that already handles a human user's role and row-level security.
The proposed framework resolves into nine controls under three imperatives: Enforce it (query-time role- and attribute-based access, dynamic column masking, agent identity as a principal), See it and prove it (classification and tagging, session-level audit logging, cross-pipeline lineage), and Unify and harden (centralized policy management, encryption at rest and in transit, consistent enforcement across on-prem, cloud, and sovereign environments).
The piece is sponsored content credited to Max Romanenko, EDB's Chief Technology Officer, and quotes EDB VP Priyanka Jain; it promotes EDB Postgres AI, a governance platform built on open source Postgres, and points to EDB's white paper 'Governing Agentic AI at Enterprise Speed' for the full framework.
No enterprise case study, external benchmark, or independent data is cited to back the framework, and no specific competing product or agent-layer guardrail tool is named as what the article argues against.

Why it matters

As enterprises hand AI agents more autonomy (the ability to plan, decide, and act across systems without a human approving each step), the article argues that the usual response, layering instructions, policies, and monitoring on top of the model, cannot hold up. Agent-layer controls are only as reliable as the agent's output is predictable, and autonomy is exactly what makes that output hard to predict; a rule that looks sound in the abstract, like 'never open the car door,' can be exactly wrong once the real context includes a crash and a fire. Governance that depends on reviewing an action before it happens cannot keep pace with a system acting in milliseconds across many systems at once, so the article's case is that enforcement has to move down into the data layer itself, where a policy either blocks an action the moment it is requested or it does not, regardless of what the agent decides to do.

Who it affects

The piece targets enterprises putting AI agents into production, and specifically the security, risk, and data teams responsible for what those agents can reach. It singles out regulated industries, for which it calls data sovereignty and source-level enforcement not a nice-to-have but 'the precondition for putting agents into production at all.' Given the sponsorship, it also functions as a pitch to anyone evaluating EDB Postgres AI or a comparable Postgres-based governance layer, since EDB describes its own product as enforcing exactly the model the article lays out.

How to use it

The article turns its argument 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 on the same policy path, and 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, and lineage across pipelines so any result can be traced back to the request that produced it. Unify and harden: centralized, portable policy management, encryption at rest and in transit, and consistent enforcement across on-prem, cloud, and sovereign or air-gapped environments. EDB positions its own EDB Postgres AI platform, built on open source Postgres, as the implementation of this model, and points readers to its white paper, 'Governing Agentic AI at Enterprise Speed,' for the full framework.

How solid is it

This runs on VentureBeat under the sponsored-content label 'Presented by EDB,' credited to EDB's own Chief Technology Officer and quoting EDB's own VP of product management. VentureBeat's standard disclosure at the foot of the piece states that sponsored articles are produced by a company that is either paying for the post or has a business relationship with the outlet. The argument itself is made entirely in the abstract: no enterprise, customer, or case study is named as having run this nine-control framework in production, no external study, survey, benchmark, or incident report backs any of the claims, and no specific competing product or agent-layer guardrail tool is named as what the piece is arguing against. EDB's own white paper is pointed to for the full framework but is not quoted or summarized here beyond the controls already listed. Read this as a vendor's argued position and product pitch, not as independent research or a reported result.

Risks and caveats

The five controls it lists (role- and attribute-based access, row- and column-level security, classification and masking, policy as code, and audit trails) are, by the article's own account, ones many enterprises already run at the data layer; what the piece adds is treating the agent as an identity principal with a declared purpose, not a new enforcement mechanism. No date or version number is attached to either EDB Postgres AI or the nine-control framework, and no enterprise is named as having deployed it, so there is nothing here to check the pitch against in production. Anyone evaluating this for their own stack is being asked to weigh a vendor's framing of established database security practices against their current tooling, not an externally validated methodology.

“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.”

— Priyanka Jain, VP of product management, data and AI governance at EDB