Photo by Valentin Lacoste on Unsplash
What We Found
Picture the log line that opens most of these incident reviews: 3:14 a.m., a scheduled agent run, a tool call that returned a timeout, and four seconds later a second identical UPDATE — because the model concluded the first one had failed. Nothing about that sequence is exotic. It is the most ordinary failure in agentic software, a retry without an idempotency key, and it happens to be aimed at a table customers can see.
As of August 22, 2026, the interesting question for most engineering teams is no longer whether a large language model can write competent SQL. It is who the agent is logged in as when it does. According to Google News, Oracle has published its own retrospective on letting agents touch production data, joining a growing vendor genre of "here is what we learned" posts. The genre has a problem: by the time a lesson reaches a corporate blog, it has been sanded smooth. The rougher version is more useful, and it starts with an identity problem rather than a permissions one.
The Pattern: An Agent Is a Multiplexer, Not a User
The surface takeaway from nearly every write-up on this topic is least privilege. Fine — nobody disputes it. The non-obvious point is that least privilege assumes you know who the principal is, and an agent quietly breaks that assumption.
Expert guidance in this area consistently lands on the same framing: database administrators should treat AI agents as high-privilege users deserving the same rigorous access controls as any DBA account, operating inside the same security perimeter as humans, with role-based access and audit trails. That is correct, and it is also incomplete. A DBA account represents one person. An agent service account represents everyone who talked to the agent that day. Two hundred employees ask questions in Slack; the audit log records two hundred queries from APP_AGENT. The trail exists, and it points nowhere.
This matters because Oracle's own constraint tooling depends on session identity to function. Virtual Private Database — the feature that attaches an invisible WHERE clause to every query based on who is asking — and row-level security policies both evaluate against session context. Collapse two hundred identities into one service account and those policies still run, they just run on a fiction. The control is enabled. It is not protecting anything.
The obvious rebuttal is: give it read-only access and stop worrying. That rebuttal is weaker than it sounds, for two reasons. First, read-only is a write control, not a disclosure control — anything the agent reads enters the context window, and anything in the context window can be summarized, forwarded, or coaxed out by a prompt-injected document three turns later. Second, read-only does nothing about resource exhaustion. An agent that hallucinates a join key and issues an unbounded cross join at 3 a.m. has not violated a single permission while it saturates the box.
Implementation: Four Controls That Do the Work
What follows is the short list that survives contact with a production schema. It is deliberately boring.
Use proxy authentication or, at minimum, set a client identifier per request so the session carries the human who triggered it. Row-level security and VPD policies then evaluate against a real principal, and the audit log answers "who asked for this?" without a forensic reconstruction from application logs.
Oracle's general posture emphasizes read-only access patterns with query result validation before agents earn broader permissions. Treat the read-only phase as an eval window, not a formality: log every generated query, diff it against what a human would have written, and only then discuss writes.
The output looks fine far more often than the query is fine. Parse the generated SQL before execution — reject unbounded scans, reject DDL, enforce a row limit and a statement timeout. Verifying artifacts before they hit a system of record is the same discipline Newslens Legal traced through the AI fake case citation sanctions: the model's confidence is uncorrelated with the citation being real.
Telling a model "do not retry" in a system prompt is not a control. A unique constraint on a request key is. Agents live inside tool-call loops; assume the loop will fire twice and design the table so the second call is a no-op.
Photo by Vitaly Gariev on Unsplash
In-Database Policy vs. Framework-Side Connectors
Here is the comparison the individual vendor posts never make, because each vendor only sells one side of it. Oracle Database 23ai, announced in 2024, shipped with more than 300 AI-related features including AI Vector Search, pushing intelligence and policy into the database. Over the same 2024–2025 window, Microsoft, AWS, and Google introduced AI agent frameworks with database connectors — pushing orchestration and policy into the application layer. NIST's AI Risk Management Framework guidance on AI systems reaching sensitive data repositories sits above both, agnostic about where the enforcement lives.
Who wins depends on one question: how many databases are behind the agent? If the answer is one, in-database policy wins outright — VPD and row-level security are evaluated by the engine itself, so a misconfigured agent, a rogue script, and a curious analyst all hit the same wall. Nothing in the app tier can route around it. If the answer is five heterogeneous stores, framework-side policy wins on maintenance cost, because replicating equivalent row-level rules across Oracle, Postgres, a warehouse, and two SaaS APIs is a permanent synchronization tax. The failure mode differs too: in-database policy fails closed and generates support tickets; framework-side policy fails open and generates incidents. Our read is that most teams should run both — the framework for ergonomics, the engine for the backstop — and should assume the framework layer will be bypassed at least once during the first year.
The $4.45 Million Number Doesn't Mean What It's Used For
Two figures dominate slide decks on this topic. As of August 22, 2026, industry surveys show 60–70% of enterprises are concerned about AI agents accessing sensitive production data, and database security incidents involving unauthorized access cost enterprises an average of $4.45 million per breach in 2024. Both get cited as though they measure agent risk. Neither does.
The 60–70% figure measures sentiment, not incidents — roughly two-thirds of respondents being worried tells you about procurement friction, not breach probability. The $4.45 million average covers unauthorized database access generally, across causes that long predate agents. Attributing it to agentic AI is a category error.
What it is genuinely good for is risk budgeting. Take the $4.45 million average as the loss magnitude and ask what an agent rollout does to probability. Multiply that average by a 1 percentage-point increase in annual breach likelihood and the expected annual cost is $44,500; at 0.5 points it is $22,250, at 2 points $89,000, at 5 points $222,500. (That arithmetic is ours, illustrative, and derived solely from the $4.45 million figure — no source reports agent-specific incremental risk.) The point is the shape of the curve, not the precision: this is ordinary financial planning applied to an engineering decision, and it reframes the debate usefully. If a proper identity-propagation and audit build costs a quarter's worth of one engineer, it pays for itself at well under a single percentage point of added risk.
Chart: Editorial calculation applying the 2024 average of $4.45 million per unauthorized-access breach to hypothetical increases in annual breach probability. Illustrative only; no source reports agent-specific risk deltas.
Where This Breaks in Production
Three failure modes show up before the security ones do. Context window blowups: schema-heavy prompts get expensive fast, and teams respond by trimming table descriptions, which is precisely when the model starts inventing column names. Latency: every policy check, query parse, and identity lookup is another hop, and an agent that answers in nine seconds instead of two gets abandoned by the humans it was built for. And tool-call loops against a rate-limited connection pool, where a retry storm looks identical to a denial-of-service attempt from the database's perspective.
None of these are AI problems. They are distributed-systems problems wearing a new hat, which is exactly why backend teams tend to get agent deployments right faster than data-science teams do.
Bottom Line
On balance, the honest summary of the current moment is that the security controls already exist and the identity plumbing does not. VPD, row-level security, proxy authentication, fine-grained auditing — all mature, all older than the transformer. What is missing in most deployments is the unglamorous work of carrying an end user's identity through an agent's tool call so those controls have something real to evaluate.
Teams running one primary database with a clear read-only use case can start now, this quarter, with the four controls above. Teams with agents spanning multiple heterogeneous stores and no unified identity story should stay in read-only mode until they have one — the expected-loss math above makes the delay cheap and the shortcut expensive. Approach agent permissions the way a disciplined operator approaches an investment portfolio: size each position to what you can afford to lose, and rebalance when the evidence changes.
Disclaimer: This article is editorial commentary for informational purposes only and does not constitute security, legal, or financial advice. It reflects analysis of publicly reported information, not independent product testing. Research based on publicly available sources current as of August 22, 2026.