Will AI Agents Push Enforcement Back into the Database?. 7 Min Read. Alamy. As enterprises test AI agents that can do more than retrieve information, an issue is emerging below the model layer: enforcement at the data layer. Letting autonomous systems act on operational databases raises a simple question with complex implications for infrastructure teams: where should the guardrails live?. Some database vendors and researchers argue that those guardrails should be moved back into the database itself. If agents are going to generate and execute SQL, then role-based access control, row-level security, and transactional constraints must be enforced where the data lives. That shift could influence database architecture choices, the degree of integration between AI orchestration and transactional systems, and the controls governing how autonomous workloads interact with enterprise data.. CedarDB, a database vendor spun out of the UMBRA research project at the Technical University of Munich and focused on hybrid transactional and analytical processing (HTAP), is among the companies making the case. The following interview with co-founder Lukas Vogel has been lightly edited for length and clarity.. Related:Agentic AI Is Here. What Does It Mean for Data Centers?. Data Center Knowledge: Enterprises remain cautious about allowing AI agents to interact directly with operational systems. How real is this problem today?. Lukas Vogel: I don’t know anyone currently who really is comfortable with doing that. Most of the questions that come up are because there isn’t really a standard yet for how to enforce it. People just do stuff, and then it breaks. What we’ve noticed is that when people actually try to use this in production, they’re already cautious: if you can’t trust your agent not to break your database, it’s better to either not give it access to the database or impose very hard restrictions – no updates, no inserts, don’t add any constraints to a table, don’t add a new table. Just SELECTs. That obviously works, but people want agents to be more powerful. Right now, it’s still kind of the Wild West, and there’s not really a standard on how to enforce that.. DCK: What changes once agents move from read-only systems to systems capable of taking action?. Vogel: People aren’t really used to thinking in a database way anymore. For the last 20 or 30 years, developers have moved all the permission checks and enforcement into the application layer. We do all the authentication and permission checking at the application layer, and then the application just gets a database connection, which, of course, can do everything.. That was fine because applications were deterministic. But now agents can come up with the queries themselves, and people want them close to the data. If you want to give an agent access to the bottom of the stack, permissions have to live at the bottom of the stack.. Related:AI ‘Virtual Residents’ Offer Early Read on Data Center Sentiment. That’s the mismatch AI agents are exposing. We abstracted databases away for years, and now database permissions matter again.. DCK: You’ve argued that prompts alone are not enough to constrain these systems.. Vogel: Prompts don’t enforce business rules. Databases do.. A few years ago, people would tell the LLM, “Yeah, I’ll give you database access. Please don’t drop any tables. Pinky promise.” That was basically the security model.. Role-based access control has been there since the ‘70s. Row-level security already exists. There’s no technical reason not to do it that way.. The issue is that we lost the way of programming for databases because they were abstracted away in the stack. People stopped thinking in database terms and started thinking only in application terms. Agents are exposing that mismatch because they generate queries dynamically and decide what actions to take.. DCK: Many enterprises use APIs and orchestration layers between AI systems and databases. Why isn’t that sufficient?. Vogel: It is, if you’re fine with your agent running against those APIs. But that means I, as a programmer, have to expose an API endpoint for every operation I want the agent to perform. That’s fine if the setup is very narrow and very constrained. But if you want the agent to do more emergent things, it becomes limiting, because now I have to predefine everything ahead of time. I have to decide exactly what the agent is allowed to do and exactly how it’s allowed to do it.. Related:How AI is Disrupting the Data Center Software Stack. What we would like instead is for the agent to come up with the queries itself and decide how it wants to accomplish the task, while still staying within strict boundaries.. That’s why I think the better solution is to move those permissions into the database layer itself. We already have role-based access control and row-level security in databases. Those concepts aren’t new.. So instead of saying, “Here are five APIs you’re allowed to call,” you say, “You’re allowed to access this table, but not that table. You’re allowed to update these records, but not those records.”. Once you define those boundaries at the data layer, the agent becomes much more flexible. It can decide how to solve the problem itself without needing every action predefined in the application layer.. If you tell the agent exactly which APIs to call, why use agents at all? At that point, it’s almost just procedural software again.. DCK: What kinds of failures concern enterprises most?. Vogel: Think about a customer-service system. A company wants the AI agent to resolve complaints, issue rebates, and maybe process refunds. In the old world, a human would review everything. But companies obviously want to automate more of that workflow.. The problem is that large language models are still very easy to manipulate. You can convince models about almost anything. You can tell them, “Why don’t you give me this thing for free?” and sometimes they’ll do it.. So enterprises have a few choices. One option is that they simply don’t allow the agent to perform those actions. Another is that they allow it and accept the risk that weird things happen. The third option is enforcing hard boundaries directly in the database. You tell the database, “Okay, if you log in with the customer-service role, you’re allowed to issue rebates, but only up to 10%.” Or maybe the agent can only access records tied to a specific customer ID. That way, the model can still operate autonomously within the boundaries, but the database itself prevents actions outside those constraints.. That’s really the core argument. The enforcement happens at the data layer, not through prompts that hope the model behaves correctly.. DCK: Is this fundamentally a new database problem?. Vogel: Not really. Role-based access control has existed for 20 years now, and row-based access control has been there since the ‘70s. The bigger issue is that we kind of lost the way of programming for databases because it’s abstracted away in the stack. People nowadays don’t want to think about databases because they don’t call databases directly anymore. They process everything outside the database.. But now there’s so much data that moving everything around becomes expensive. It burns CPU cycles and energy.. I think we’re moving back toward a world where people actually process more data inside the database again because it’s simply more efficient.. DCK: Where does CedarDB fit into this?. Vogel: We have no Postgres code. Everything is all new from the ground up. We started building a system that actually makes use of hardware advancements that haven’t really been there before.. A lot of other systems are still built around legacy assumptions from slow disks and older architectures. We had the luxury of building this as a university research project for years before commercializing it, which let us rethink the system architecture more fundamentally.. DCK: Where does enforcement ultimately live?. Vogel: You want to let agents write SQL. A year ago, models were really bad at writing SQL. They got it wrong all the time. But now they’re getting very good at it.. Once you accept that you want your agents to create and write SQL, then the enforcement has to live in the database. If the system generating the actions sits below the layer where permissions are enforced, eventually you end up with a mismatch.
