ai/ml
**Interview: **What do regulated enterprises need at the data and infrastructure layer to keep agentic AI from exposing sensitive data or taking actions that surpass compliance controls?
Multi-model database supplier EDB’s Chief Engineering Officer Max Romanenko has ideas about what is needed and we explored them in an interview.
Blocks & Files**: AI agent use is here and growing. Is an AI agent equivalent to a human user accessing data and/or an application accessing data? What are the pertinent differences between these three from an IT systems perspective?**
**Max Romanenko: **It’s radically different for one simple reason.
What we call speed and fidelity: Agents work 24/7/365, humans cannot.
We are about to increase the global workforce by 34 percent+ in less than three years with agents and that took 20+ years with humans. These agents need a whole new set of access, decision making, and governance requirements from day one. IT infrastructure has to be built for unified data, governance at the data layer capabilities and performance predictability (delivery, consumption). That demands a sovereign first architecture, unified data architecture and governance inside the context and data and not as an afterthought. Observability and orchestration become existential and not nice to haves.
An AI agent isn't just playing the same song on a different fiddle; it's a whole new performance. Whereas a person has an actual role and business context, an application is predictable because it operates within predetermined parameters. An agent isn't confined to those same boundaries, but instead reads a task, figures out what context is necessary, and pulls live data without someone approving every step of the way. This changes the game a bit for IT systems. It's no longer enough to check whether a credential is valid; IT also has to look at whether the agent's behavior matched the job it was given in the first place.
One good example of this is a fraud-support agent at a bank that needs to pull up a customer's account history. That agent shouldn't be able to reach into records that have nothing to do with the case in front of it. The access has to be scoped as tightly as the task itself, not left wide open just because the agent is capable of moving fast. Agents can move across systems quickly, but the information they touch needs to be well governed ahead of time, so they don't end up tapping into records they have no reason to need.
Blocks & Files**: Do agents need identity access management (IAM) like people? Can IAM for humans be used or is agent IAM different from human IAM?**
**Max Romanenko: **Agents absolutely need identity management but also contextual access controls that define their capabilities in a context of the task and data needs. We are going to ask agents to do hundreds of very different jobs in a day or an hour. The permissions will change from task to task. Imagine the old world was monolithic, the new world is almost infinitely heterogeneous for each agent. Specificity is the key here, specific identities related to the specific task they are doing then and now.
Agent IAM has to start with what the agent is supposed to do. This distinction sounds small, but it changes the entire model because the agent may be acting on behalf of a person, inside an application workflow or across multiple systems at once. In practice, that means giving the agent its own identity and limiting its access to the specific data and actions required for the task.
One common mistake many teams make when deploying agents is granting agents permissions that let them operate through a broad service account or simply letting an agent inherit a human user’s full permission. But that doesn’t answer the more important question of whether the agent had a legitimate reason to access that data for that task.
A fraud-support agent shouldn’t share the same access boundary as a customer-service agent just because both touch banking data. The identity and governance that guides the agent has to reflect the work it’s performing and the system it came from to be secure and successful. There have to be clear guardrails in place to protect the data.
Blocks & Files**: Do AI agents need their own access boundaries once they start acting across enterprise systems? How are they to be defined and enforced?**
**Max Romanenko: **Agents that act across systems need boundaries that are clearly tied to a purpose and enforced before data's even touched. Agents should be allowed to access the data required for the task assigned and blocked from everything else, even if the human user or application that invoked it has broader privileges. The boundary should account for what the agent is doing in that moment and not beyond that moment. This is vital because context and moment drive agent success and not generic rules.
If that context only lives in a generic policy in the application layer, it becomes harder to maintain once the agent starts moving through APIs, retrieval systems, and operational databases. You need enforcement close to the data because the database is where the sensitive record actually lives and where the final access decision should be made. This is where the existing foundation becomes most important, and where Postgres becomes a great protection of sensitive data and boosts agent efficiency. Postgres already has mature primitives around roles, policy definitions and row-level security. EDB PG AI puts those primitives to work today, enforcing agent access through the database's own roles and row-level security. The work now is extending those native Postgres primitives into an agentic environment where the actors are no longer only humans and traditional applications, with a full governance layer coming later this year. That's a cleaner path than trying to add on a separate control plane after the agent has already been given access to the data.
Blocks & Files**: What should we do about the risk of sensitive data being exposed when agents inherit permissions that were designed for human users or broad application access?**
**Max Romanenko: **Most enterprise access models were built for trusted employees or predictable applications, but agents don’t behave that way and, as a result, shouldn’t inherit broad permissions. This can be especially dangerous in regulated industries where agent exposure to sensitive data may be technically permitted by a credential but still unacceptable from a compliance standpoint. We see this when a healthcare agent helps with an administrative workflow but shouldn't see more patient detail than a task requires. Or when a banking agent helps resolve a customer’s inquiry, but shouldn’t have open-ended access to account data outside that customer or workflow.
The fix is to give each agent a unique identity and guardrails, limit its access to the workflow it serves, separate read access from write authority, and use database controls, so the agent only sees the records it is allowed to see. The agent should never become a shortcut around the controls the enterprise already relies on for regulated data.
Blocks & Files**: What should stronger audit trails, row-level controls and agent-specific access policies should look like in regulated environments?**
**Max Romanenko: **A stronger agent audit trail should be completely comprehensive, showing which agent acted, what invoked it, what data it accessed, which policy allowed that access, and what happened next. That context matters, especially in highly regulated industries, because a basic access log is not enough for agentic systems.
Agent governance should be enforced at the data layer itself, using native Postgres primitives like roles and row-level security, rather than through a separate control plane bolted on top. The goal isn’t a separate layer watching from above and trying to reconstruct what happened after the fact. I see the goal as policy enforcement where the access decision happens and where the audit record can be tied back to the data that was touched.
Agent-specific policies also need to distinguish between reading and acting because those are very different levels of risk. For a bank, this looks like different access based on different risk profiles that are tailored to each respective case. The same customer record may be accessed for fraud review or for a general service workflow. In healthcare, accessing patient information for a clinical task is not the same as accessing it for an administrative process. The audit trail has to explain the business context, not just the technical event. Row-level controls are how you prevent the wrong access before it happens. Instead of granting an agent broad access to a table, the system should limit access to the specific records that match the agent’s task, customer relationship or regulatory boundary.
Blocks & Files**: How can banks, telecom carriers and healthcare organizations use AI in production while keeping regulated data inside infrastructure they control?**
**Max Romanenko: **They have to bring AI to the data rather than moving regulated data into an external environment just so an agent can use it. Regulated organizations can’t just treat core customer data like generic application context that can be copied and pasted onto wherever the agent framework happens to run. This introduces the threat of exposing sensitive network operations data to a platform it doesn’t fully control or govern, while still claiming the same level of operational sovereignty.
The best strategy that prioritizes security, efficiency, and deployment flexibility is to let organizations add AI and analytics around that foundation without forcing regulated data into a separate cloud-native platform first. In practical terms, that means transactional data, analytical workloads and agentic systems can operate closer to the same governed foundation, rather than being spread across disconnected platforms with different control models. The AI architecture has to support those choices from the beginning instead of assuming that everything moves into one vendor-controlled runtime.
Blocks & Files**: Should sovereignty function as a technical control for AI, and not just be a legal or procurement requirement?**
**Max Romanenko: **For agentic AI, sovereignty must be baked into the system. Contracts can say where data should reside and who is responsible for protecting it, but they don't enforce runtime behavior or stop an agent from querying the wrong dataset, combining data in a way policy does not allow or sending regulated context into a workflow that should never have seen it.
Banks, telecom carriers, healthcare organizations and other regulated spaces need sovereignty; the company can keep regulated inside infrastructure it owns and controls, govern agent access at the data layer and enforce policy through native Postgres primitives like roles and row-level security.
Blocks & Files**: Could AI Agents enforce sovereignty?**
**Max Romanenko: **Agents can operate inside a sovereign environment, but they shouldn't be the final authority over sovereignty. They’re useful for specific and well-defined tasks, like identifying unusual access patterns, helping teams understand where regulated data is being used, and surfacing configurations that no longer match the organization’s data rules. That kind of assistance has value because modern data environments are too complex for most teams to manually inspect in real time.
But it’s vital that the final hard boundary should depend on the judgment of a human and the architecture they created. An agent should not be the authority in deciding whether it’s allowed to break a sovereignty rule. Agents can help teams manage the environment, but they should operate within rules the enterprise sets rather than becoming the authority that defines or overrides those rules.