How data-layer controls set boundaries for autonomous AI agents

AI agents can now plan, decide, and act across several systems without waiting for a person to approve every step. The architecture question therefore becomes concrete: when an agent attempts an action outside its authority, which system can actually stop it? EDB proposes putting final authority in controls at the operational data layer, where access can be evaluated and denied as the action occurs. EDB has a commercial stake in enterprises adopting the data-layer approach it proposes, so its claims about the architecture’s benefits need to be read in that context.

Agent autonomy changes where governance has to take effect

More autonomous agents change the timing of governance because organizations remain responsible for agents running on their models, infrastructure, and data. A rule documented for later review cannot prevent an action already taken, while requiring a human decision before every action removes much of the autonomy the system was designed to provide. Governance therefore has to operate in the immediate context of a request and have authority over whether it proceeds.

That timing requirement turns general ideas about responsible agent behavior into specific system boundaries. An organization needs to decide how far an agent may go, which data it may access, what it may modify, which operations require escalation, and how an incident can later be reconstructed. As agentic systems become more capable and autonomous, those decisions matter more because a growing share of execution happens without individual human approvals.

Those boundaries matter only when a system can enforce them. Instructions can tell an agent what it should do, and monitoring can reveal its behavior, but a production control must be able to stop an unauthorized operation when the agent attempts it. EDB argues that this final decision should happen at the data layer, using controls that evaluate the identity and context attached to the action.

Probabilistic agents cannot be the final enforcement point

Putting enforcement at the data layer addresses a basic property of autonomous agents: their behavior is probabilistic. Instructions, policies, and monitoring can influence and observe that behavior, but final control would then depend on the agent behaving predictably enough to enforce its own boundaries. Autonomy makes that dependency harder to accept because an autonomous agent is allowed to select actions instead of following a fully predetermined sequence.

Execution speed makes the problem harder. EDB says agents can act “in milliseconds” and operate across many systems simultaneously, so governance based on pre-action human review cannot keep pace with that execution model. An agent may query data, retrieve it, transform it and increasingly take actions based on it before a person could inspect each intermediate decision.

A prohibition on access shows what final enforcement requires. Saying that an agent must never access a particular class of data has practical force when the system receiving the query can reject it. If the database applies the access policy, authorization becomes a property of the system holding the data. When compliance depends solely on the agent obeying an instruction, its probabilistic behavior remains part of the security boundary.

Separating those responsibilities allows probabilistic reasoning and deterministic enforcement to coexist. An agent can reason probabilistically about which operation will achieve its goal, while an underlying system makes a definite authorization decision about the operation it requests. Governance can then control the resulting action even when the reasoning that produced the request was difficult to predict.

That authorization decision still needs context because circumstances can change which action is permitted. Policy therefore needs enough information about an action’s context to determine whether it is allowed at that moment. The architectural challenge is to represent that context in a form an enforcement system can evaluate while the operation can still be stopped.

The new inputs are agent identity and declared purpose

Moving authority into the data layer requires existing database security to account for autonomous agents. EDB’s proposal adapts controls that many enterprises already operate: role-based access control (RBAC), attribute-based access control (ABAC), row- and column-level security, data classification, masking, policy as code, and comprehensive audit trails. The change is that those mechanisms must understand the agent participating in a request.

That understanding starts with identity management, which treats the agent as a principal, an entity with its own identity that authorization systems can recognize. The agent consequently enters the same enforceable policy process as other principals and remains visible independently of the application connection carrying its request. Its authorization can then be evaluated at query time against the controls already protecting the underlying data.

Identity establishes who the agent is, while declared purpose adds why it is accessing the data. EDB proposes declaring that purpose when a session begins and binding it to the agent’s identity, making purpose another policy attribute alongside information such as role and department. Context becomes operational because the policy engine receives a declared reason for the session and can use it to decide whether access is allowed.

Purpose also has to remain connected to the person behind the task. An agent may execute a database request under its own machine identity while performing work for a particular person, and preserving both identities strengthens authorization context and later accountability. A record can preserve the agent, the human or other user for whom it acted, its declared purpose, and the data operation that followed.

Priyanka Jain, VP, product management, data & AI governance, EDB, describes purpose as the addition that makes existing policy machinery agent-aware: “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.”

Jain’s description connects these new inputs to familiar enforcement primitives. The agent has a first-class identity, the purpose is declared at session opening, the acting user survives the handoff, and policy evaluates this information where an operation can still be denied. That combination is the mechanism behind EDB’s claim that greater agent autonomy can use an existing governance stack adapted for agent context.

Nine controls turn the principle into an enforceable and provable system

EDB turns this architecture into nine controls organized under three imperatives: enforce the policy, produce evidence of what happened, and make the controls hardened and portable. These groups work as a sequence because preventing a prohibited query addresses the immediate action, while production governance also has to explain the agent’s actions afterward and preserve policy as workloads move among deployment environments.

The first imperative determines what an agent can actually do. Role- and attribute-based access controls make authorization decisions when agents and users issue queries, while dynamic column masking uses the same policy path to determine which values they can see. Classification, identity and purpose can consequently produce different permitted views or operations through controls enforced by the data system.

Within that enforcement group, first-class agent identity supplies the agent-specific context described earlier. The agent declares its purpose when opening the session, and the system retains the identity of the user for whom it acts. Those inputs allow the authorization path to evaluate the machine actor and its stated reason for access before the underlying data operation executes.

Once enforcement can identify the actor and context, policy also needs to understand the data involved. That requirement leads to EDB’s second imperative: seeing and proving what happened. Classification and tagging identify data in terms a policy can evaluate, giving the policy information about the data itself. Those classifications can then contribute to access and masking decisions when an agent requests particular information.

The same context has to survive execution, which is the role of session-level auditing. For agent activity, EDB’s framework records which agent acted, which user it acted for, and the declared purpose under which the session operated. The resulting record connects a database operation to the identities and intent attached to the session that produced it.

Lineage carries that evidence beyond the individual operation and across pipelines. A result may emerge after information has moved through several processing steps, so reconstructing the final event requires a connection back to the originating request. EDB’s lineage control is intended to preserve that connection, allowing an organization to trace a result through the processing path that generated it.

Together, auditing and lineage define what “auditable” means for an autonomous agent in EDB’s framework. The organization needs an evidentiary chain connecting agent identity, the acting user, declared purpose, accessed data, subsequent lineage and resulting output. That chain supports the questions a security or risk team will ask after an incident: what did the agent do, what did it access, for whom was it acting, and what resulted?

After enforcement and evidence, the final imperative addresses whether the controls survive real deployment constraints. Centralized, portable policy management provides a way to manage rules across environments, while encryption protects data both at rest and while moving between systems. Consistent enforcement then carries the same governance requirement into on-premises, cloud, sovereign and air-gapped deployments, making the controls applicable across different hosting models.

Those nine controls give EDB’s governed-agent model an operational form. The agent’s identity and scope feed authorization and masking, its activity enters audit records, and logs and lineage preserve evidence for later reconstruction. Governance in this model covers both the decision made before access and the record used to understand what happened afterward.

Control at the data layer matters most when control of the environment matters

The portability requirement becomes particularly consequential for organizations that need authority over the infrastructure itself. EDB bases its approach on open source Postgres and argues that this foundation lets enterprises control where data resides, who can reach it, and which policy applies. For an organization running on-premises, in a sovereign environment or in an air-gapped deployment, data-layer governance keeps those decisions within infrastructure the organization can own and inspect.

From that infrastructure argument, EDB makes a stronger claim for regulated industries: data sovereignty combined with source-level enforcement is a precondition for putting agents into production. In EDB’s view, enforcement must travel with the data architecture across on-prem, cloud, sovereign and air-gapped environments. Security, risk and leadership teams can then evaluate the agent operating model while retaining governance over infrastructure under their control.

That operating model places a defined scope around autonomous action. Teams define what an agent can reach and modify, when escalation is required, and which evidence will be available after a failure. EDB argues that an agent operating inside those boundaries can receive greater autonomy because the underlying systems remain capable of enforcing limits independently of its behavior.

The defined boundaries also support EDB’s broader adoption claim, from which the company stands to benefit commercially. EDB presents data-layer enforcement as a way for enterprises to move faster with AI because security, risk and leadership can trust the operating model beneath the agent. On that reasoning, organizations can permit more autonomy while the underlying data system remains responsible for enforcing access boundaries.

What the architecture establishes

EDB’s broader adoption claim follows from a more specific technical mechanism. Autonomous agents can produce unpredictable behavior and act faster than human review, while data-layer systems can make authorization decisions when those actions reach protected data. The nine-control framework then specifies how identity, purpose, policy enforcement, auditing, lineage, encryption and deployment portability fit around those decisions.

The mechanism also explains the role of changing circumstances. A contextual rule scenario used to show why circumstances affect a decision illustrates how the policy must receive enough context to evaluate an operation at action time. In EDB’s design, agent identity and declared purpose provide part of that context, while classifications and other policy attributes determine how the data system responds.

Greater autonomy therefore sharpens a decision that engineering and governance teams have to make: which component possesses final authority when an agent requests an operation? EDB’s answer is to make that authority executable in the data system, with agent identity and declared purpose available to policy at action time. The enforceability of that boundary is an architectural property teams can evaluate directly, while faster enterprise adoption remains EDB’s claimed consequence of the design.

Main highlights

• Put enforcement where actions occur: Security and data teams can govern autonomous agents at the data layer, where access policies can approve or deny operations at execution time. This preserves autonomy while keeping enforceable boundaries around protected data.
• Separate agent reasoning from authorization: Probabilistic AI behavior makes the agent itself an unreliable final enforcement point. Architecture teams can place deterministic authorization beneath agents so requested operations remain subject to enforceable policy.
• Give agents identity and purpose: Identity teams can treat each agent as a distinct principal and bind its declared purpose and acting user to the session. Those attributes give access controls the context required for authorization and accountability.
• Build enforcement and evidence together: EDB’s nine controls combine access control, masking, identity, classification, auditing, lineage, portable policy, encryption and consistent enforcement. Security teams can use this model to connect runtime decisions with evidence showing who acted, for whom, why and with what result.
• Preserve governance across deployment environments: Organizations operating across cloud, on-premises, sovereign or air-gapped environments need policies that travel consistently with their data architecture. Infrastructure teams can assess whether controls remain enforceable as workloads move between environments.
• Define who has final authority: Engineering and governance teams need to identify which system can actually stop an unauthorized agent operation. EDB’s model assigns that authority to the data layer, using identity, purpose and policy context to make the decision when access occurs.