Oracle pushes an agent's read limits down to the row, column and cell

The ticket lands on a DBA and it says: restrict the agent to the caller's own rows. Before the policy syntax matters, someone has to answer which identity shows up on the connection when the agent runs its query. Loaiza described Oracle Deep Data Security as enforcing authorization at the row, column and cell level based on user identity and runtime context, so that a compromised application or a manipulated prompt still limits what the agent can read ^[4]. Whichever identity arrives on the session is the one that filter reads. An agent calling through a shared application account gets everything that account can see, and the cell-level policy is behaving exactly as configured while it happens.

The interview makes two claims and they point at different work. "We've had security teams for literally decades working on securing our product, and yet AI is finding hundreds of security issues. It's very scary and kind of crazy, like nothing I've ever seen before," Loaiza said of Oracle's own code ^[2]. Separately he argued for pushing controls downward: "You got to go fast, but you have to trust the result. Our solution to that is you have to move that trust layer as low as possible," he said ^[5]. Hundreds of freshly found issues in shipped software argues for patching faster and staying on current releases, which is what Oracle is telling customers to do while it runs multiple models across its own code ^[3]. Row-level authorization does something else. It narrows what a caller can reach when the caller is not the one the application was written for.

The prompt-injection version of the case is the tighter one. "If, at that data layer, we enforce that each end user can only see their data, then no matter what kind of prompt you put ... the agent that's acting on behalf of that user can only see that user's data," Loaiza said ^[6].

Both products named in the interview are Oracle's. theCUBE was a paid media partner for the event, and says neither Oracle nor other sponsors have editorial control over its content ^[9]. The count of hundreds is an Oracle executive describing Oracle's code ^[2], and Oracle did not disclose pricing or availability for Deep Data Security ^[12].

Loaiza does not claim the controls hold. "I'd like to tell you that our technology is 100% perfect, that it will never be breached. I can't tell you that," he said ^[7]. Oracle's answer for the minute after is the Zero Data Loss Recovery Appliance, which it says protects database transactions in real time, validates backup integrity and supports rapid restoration ^[8].

Two questions sort the rollout. Does the end user's identity reach the database on an agent's queries, or does a pooled account front them? And how much can that principal read: one tenant's rows, or the schema? Identity propagated with narrow scope is the case Oracle's pitch describes. Pooled with narrow scope contains the damage but hands every user the same window. Identity propagated with broad scope is the case where writing cell policies is the actual job. Pooled with broad scope is where the exposure sits, and no amount of policy authoring helps there until identity propagation lands. That re-plumbing is application work.