Share with your CISO
EDB is making a pointed architectural argument: AI agent governance that lives at the prompt, policy, or monitoring layer is structurally insufficient, and enforcement has to live at the data layer itself, inside the database, at query time. The piece, authored by EDB CTO Max Romanenko, frames nine concrete controls across access, auditability, and policy portability as the minimum viable governance stack for agentic AI. The central mechanism is “declared purpose,” binding an agent’s stated intent to its session identity so the same policy engine that governs human users governs agents too.
What this means for your business
Whether your organization has autonomous agents in production or is still evaluating them, the governance question this piece raises is already live in your architecture. Most enterprises built their data access controls assuming a human, or at most a service account, was the requester. Agents break that assumption because they act at machine speed, across many systems simultaneously, with outputs that are probabilistic rather than deterministic. If your current controls require a human review step before an action completes, they don’t work for agents. That’s the exposure this piece is pointing at, and it’s real regardless of who’s selling the solution.
The “declared purpose” concept is the most operationally interesting idea here, and also the one that will stress-test your identity and access management stack the hardest. The argument is that an agent should announce what it’s there to do when a session opens, and that declaration becomes an attribute the access control layer evaluates alongside role and row-level permissions. That’s a meaningful extension of how most enterprises think about identity today, where the principal is a person or a fixed service account with static permissions, not an entity whose scope varies by stated task. Implementing this well requires your database, your IAM layer, and your agent orchestration framework to agree on a schema for purpose that none of them currently share.
EDB sells exactly the platform this argument concludes you need, which puts a thumb on the scale toward database-native enforcement over other architectural approaches, like policy layers enforced at the API gateway or the agent runtime itself. That’s worth naming, but it doesn’t invalidate the underlying logic. The falsification condition is straightforward: if your agent runtime can guarantee deterministic, auditable behavior at the enforcement layer without touching the database, the argument collapses. No one has shipped that yet. Until they do, the case for pushing governance down to where data actually lives is the stronger architectural bet.
Concept deep-dive: Row- and column-level security
Row- and column-level security are database-native controls that restrict which rows or columns a given identity can see at query time, think of them as a filter the database applies automatically before returning any result, invisible to the requester. They exist because application-layer access checks can be bypassed if someone queries the database directly. For agents, the business connection is precise: even if an agent is compromised or misbehaving, it physically cannot retrieve data its identity isn’t cleared to see, because the restriction lives below the application in the database engine itself.
Based on reporting from When agents act on their own, governance has to live in the data layer, originally published 2026-08-27 08:01:00.
