Companies are gradually giving autonomy to their AI agents; that is, the ability to plan, decide and act in systems without human approval at each step. In this situation a fundamental question arises: what can prevent an action that has not been explicitly authorized?
These agents run on organizational models and have access to infrastructure data; therefore the responsibility for their outcomes lies with the organization itself. This responsibility cannot be satisfied retroactively or with abstract policies that exist only on paper. Rules must be applied at the moment and in the current context, because agents lack the ability to make independent judgments.
For example, a simple rule says “Never open a car door under any circumstances.” If applied absolutely, the agent can never enter or exit. But in a situation such as an accident or fire, the opposite rule is needed. Thus the instantaneous context determines the entire decision.
The usual approach is to add protective rails (instructions, policies, monitoring) on top of the model; however these mechanisms have structural limitations. Agent‑layer controls are effective as long as the agent’s output is predictable; but autonomy precisely makes the output unpredictable. Governance that checks an action before it occurs cannot keep pace with a system that operates in milliseconds across multiple systems simultaneously.
Therefore governance must be “enforceable” and applied exactly in the operational data layer at the moment of occurrence. Agents interact with data: query, retrieve, transform and even modify it. A policy that says an agent must not have access to a certain class of data only makes sense if the system can deny the access request at that very moment. Also the auditability principle becomes practical only when the organization can reconstruct what the agent did, which data it accessed, for which purpose, and what result was obtained.
Agent behavior can be probabilistic; therefore the organization should not rely on model selection to enforce policy. The policy must be executed by the system; that is, a boundary is built that cannot be crossed from the start. The data‑layer controls that many companies already employ include role‑ and attribute‑based access control, row‑ and column‑level security, classification and masking, policy‑as‑code and full audit trace.
What agents change is their identifier. The identity‑maker must treat the agent as an independent principal; that is, for each agent an identity and a purpose declared at the start of the session are defined. When the purpose is bound to the identity, the policy engine can evaluate it like a role or organizational unit and the event log will show not only who acted and which data was touched, but also what purpose it had.
In practice these items are divided into nine controls that are grouped into three main pillars:
Execution of policies
- Role‑ and attribute‑based access control applied at query time for agents and users.
- Dynamic column masking based on the policy path.
- Agent identity as a core principal with the purpose declared at session start and preserving the active user.
Observation and proof
- Data classification and labeling that drives the policy.
- Row‑level session log that records the agent, the associated user and the declared purpose.
- Lineage tracking to enable back‑tracing to the original request.
Integration and hardening
- Centralized and portable policy management.
- Encryption at rest and in transit.
- Consistent enforcement across on‑premises, cloud, sovereign or isolated environments.
The declared purpose makes the difference; this attribute is added to the access layer and is evaluated in the same policy path just like role and row‑level security. The policy‑enforcement mechanism does not change; only that the agent’s purpose becomes part of the evaluation and final logging, says Priyanka Jain, Vice President of Data Management and AI Governance at EDB.
The further the AI adoption path progresses in an organization, the more data‑layer governance enables faster movement; because these controls are already embedded in the database and the agents only need to pass through them.
The goal is not to block agent functionality, but to define the scope of action, accessible data, permitted modifications, items that require escalation, and the ability to reconstruct events in case of an issue. With this approach agents are identifiable, bounded, monitored and auditable and security, risk and management teams can deploy AI more confidently and quickly.
The EDB Postgres AI platform is built on the open‑source PostgreSQL; this open infrastructure allows organizations to keep storage locations, accesses and policies under their own control, without delegating governance to a layer that is not owned or reviewable. For regulated industries, this combination of open‑source governance and source‑layer governance is a prerequisite for using agents in production environments.
Agent‑centric systems become increasingly powerful and autonomous; therefore we must consciously choose the control mechanism rather than slow down adoption. Organizations that apply governance in the data layer can advance to AI more quickly and with greater confidence.