Product1 publisher3 min readPublished
Oracle moves the entitlement check to the moment the query hits the database
Vipin Samar and David Knox showed an indirect prompt pulling salary data past an application's guardrails, then failing once the rule lived in the database, and argued that no agent should be trusted to police its own access.
The Product Desk · Product desk
What happened
- Oracle's Secure at Source approach puts encryption, access controls and other protections inside the database instead of leaving individual applications to enforce them, senior vice president Vipin Samar said.
- David Knox said Oracle sits at the point of execution, intercepting every query and running it through all of the security capabilities rather than inspecting behaviour from outside the database.
- The interview was recorded at Oracle's "AI Cyberattacks Are Escalating: How to Secure Your Data Now" event, for which theCUBE is a paid media partner.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- decision Teams that filter rows in service code now choose whether to re-express those rules as database policy, because a control at the query only applies the policy it has been given.
- exposure If a prompt can reach data through a path that skips the application, every internal app whose only protection is its own filtering is reachable by whoever can talk to the agent.
- constraint Permissions that follow the user require the database to know which user an agent is acting for, so shared service accounts cap how fine the enforcement can get.
- cost Fleet-wide posture tooling produces findings, and the drift and excess privileges it names are then fixed one database at a time by the people who own the schemas.
The person who has to answer for this owns the HR schema. On Monday the question is narrow: an agent connects with a valid credential and asks for salaries, and something has to say no. Oracle's position is that the something sits at the query. Knox said Oracle intercepts each SQL statement as it runs and puts it through the security capabilities [7].
Two separable propositions are inside the pitch. The first is about trust boundaries. "We really cannot depend upon agents to enforce their own security," Samar said [3], and he described the scope of the limit as "any agent you want, any swarm of agents you want" [4]. He also said "I tell them security is not synonymous with encryption" [14]. The second proposition is a product line: Data Safe for cloud-based assessment and monitoring, Database Security Central for a self-managed view of users, sensitive data, configurations and policies across a fleet [9]. Agreeing with the first costs nothing; the second means work for whoever owns the schema.
The demonstration is the part that carries over to other stacks. An indirect prompt got past the application's guardrails and returned salary data, and with the access restriction enforced inside the database the same prompt could no longer retrieve it [5]. The demo shows one failure mode, and the vendor showed it at its own event, where theCUBE is a paid media partner [13].
What teams tell themselves is that the application is the only way in, because for years it was the only thing holding a connection. The stated aim of enforcement in the database is that permissions follow the user and the data across different applications and agent access paths [2]. The interview does not say how the end user's identity reaches the database when an agent holds the connection. Anyone sizing the work has to establish that first.
This lands hardest on shops that have already handed an agent a connection string or a read replica, while a team whose agents only call reviewed service endpoints is being sold insurance against a path it has not opened yet.
Fleet-wide visibility is the expensive claim. Samar said "AI can move very easily and naturally from one database to the other" [10], and by the account given at the event, fleet-wide visibility helps surface configuration drift, excessive privileges and inconsistent policies [11]. Somebody then fixes each of those findings by hand, database by database.
The grid has two columns and two rows. Columns: an agent can reach this table without passing through the application, or it cannot. Rows: the rule protecting it exists as database policy, or only as code in a service. The box where the agent has a path and the rule lives only in code is what the salary demo was about [5]. Knox said he wants a control that holds "irrespective of why something bad happened" [6], and the checkable version of that in your own stack is whether each sensitive table's rule still applies when the application is skipped.
What to watch
- Whether Oracle documents how an end user's identity is propagated from an agent session into database policy evaluation.
- An independent reproduction of the indirect-prompt salary demo outside an Oracle-sponsored event.
- Whether Oracle attaches pricing or licensing terms to Database Security Central alongside Data Safe.