The instinct to solve AI governance by stacking more guardrails around the model is understandable, but it misses the structural problem. If you ask an agent to follow a rule like "never open the car door," you quickly realize the rule is only sensible in a context where the car isn't on fire. Autonomy, by definition, makes the agent's next move hard to predict, so any policy that depends on reviewing an action before it happens is already too slow. That is why the argument from EDB, presented in Governing AI Agents: Embedding Control Within Your Data Layer, lands with such clarity. The point is not that model-level instructions are useless. It is that they are aspirational, and aspiration is not an enforcement mechanism.
What EDB is proposing reframes where control actually lives. Instead of hoping an agent chooses to stay within bounds, you build the bounds into the database itself, where the agent must pass through row-level security, column masking, and policy-as-code checks at the exact moment it touches data. This is a meaningful shift from the common enterprise reflex of treating governance as a separate layer that watches from above. If you think about the practical reality, an agent that can query, transform, and act on data in milliseconds cannot be governed by a human reviewing a log after the fact. The control has to be concurrent with the action. That is why the idea of treating the agent as a first-class principal, with its own identity and a declared purpose bound at session start, feels like the missing piece. It turns a vague concern about "what will the AI do" into a concrete architectural question: does this agent have the right to read this row, for this user, under this stated intent?
For our readers, the takeaway is not that you must adopt EDB's specific product. It is that the conversation about AI safety has been too focused on the model and too little on the data layer that the model touches. If you are building agentic systems, the question to ask is not "how do we make the model safer" but "where does the enforcement point actually sit?" If it sits only in a prompt or a policy document, you are relying on probability. If it sits in the database, you have a deterministic backstop. That distinction matters because the cost of a failure is not an abstract risk. An agent that reads a restricted record or triggers an unauthorized write is not a hypothetical scenario; it is a matter of when, not if, as you scale autonomy across your infrastructure.
The open question that remains is whether enterprises will treat agent identity with the same rigor they treat human identity. A human user has a role, a manager, and a review process. An agent, left unchecked, has none of that unless you build it. The detail to watch is how quickly organizations start binding a declared purpose to every session, not because it is a nice governance feature, but because it is the only way to make an audit trail mean anything when the actor is a piece of software. If you cannot reconstruct which agent did what, under whose authority, and for which user, then you do not have governance. You have a hope. EDB's argument is a reminder that hope is not a control, and the data layer is where that control either exists or it does not.