Every major platform is now answering the same question in its own way: when an AI agent touches enterprise data, whose authority is it using, and what stops it from going further than it should?

Oracle’s answer to AI agent security is worth studying because it doesn’t rely on the model behaving well. It puts the controls in IAM policy and, most interestingly, inside the database itself.

Framing

Why agents change the security model

Traditional applications follow fixed code paths. Review the code and you know what the application can do.

Agents are different. They decide at runtime which tool to call, and they often write their own SQL. That turns an agent into a new class of non-human identity, one whose behavior you cannot fully predict from its configuration.

An agent should be governed like a privileged user, not trusted like a piece of code.

Risk

The threat model

Oracle frames agent risk around three OWASP concerns for AI systems: prompt injection, excessive agency and sensitive data disclosure (Deep Data Security technical brief). In a database, all three end in the same place: unauthorized SQL. I would add a fourth that matters just as much to auditors, which is losing track of which person an agent acted for.

Multi-agent systems widen the blast radius. Oracle notes that one compromised agent can pass actions on to others, which makes attacks harder to detect and contain.

Architecture

Oracle AI agent security in four layers

Every agent request has to clear four independent checks before it reaches data. A failure in one does not open the others.

Layer 1

IAM for people

OCI IAM decides which humans can create, change and call agents, and it starts closed. By default only the Administrators group can touch Generative AI Agents resources. Everyone else must be granted access by policy (OCI documentation).

The quick-start grant covers the whole service with manage genai-agent-family in tenancy. That is fine for a sandbox and too wide for production. The service has separate resource types for agents, knowledge bases, data sources, ingestion jobs, endpoints, sessions, tools and work requests, so access can be split by role and pinned to a compartment.

# Quick start: every agent resource, whole tenancy
allow group GenAI-admins to manage genai-agent-family in tenancy

# Production: split by role, pinned to one compartment
allow group Agent-builders to manage genai-agent in compartment AI-Dev
allow group Agent-builders to manage genai-agent-knowledge-base in compartment AI-Dev
allow group Agent-operators to manage genai-agent-endpoint in compartment AI-Prod
allow group Agent-users to use genai-agent-endpoint in compartment AI-Prod
allow group Agent-users to manage genai-agent-session in compartment AI-Prod

Oracle’s Fusion guidance makes the same point for AI Agent Studio: keep builder, run and service-account privileges separate, so least-privilege reviews stay manageable (Identity and Security in AI Agent Studio).

Layer 2

Agent identity

An agent never borrows a person’s OCI credentials. It authenticates as a resource principal, belongs to a dynamic group, and gets only what IAM policies grant that group. An agent reading from Oracle AI Database 26ai, for example, needs its dynamic group allowed to read database-tools-family in one compartment.

I would treat every dynamic group exactly like a service account: one per agent or workload, a named owner, the narrowest matching rule you can write, and a line in the periodic access review.

Inbound and outbound are two different questions

For agent applications hosted on OCI Generative AI, Oracle splits authentication in two (OCI documentation: Authentication).

OAuth is the only supported authentication type for agentic tasks, and it needs an application registered in an OCI identity domain beforehand (Permissions to Generative AI Resources). The same page covers private endpoints with zero trust packet security, which keep agent traffic off the public internet.

Generative AI API keys also go through IAM, with a policy restricted to that key’s principal type and ID. Oracle recommends narrowing those policies to specific models or endpoints, or to chat-only access (Adding Key Permissions).

Layer 3

Tool access

Tools are where an agent’s decisions become actions, so every tool is a permission. OCI Generative AI Agents supports RAG, SQL and function-calling tools, and an Agent tool attaches another agent as a subagent (Agent Tool Guidelines).

Oracle’s Fusion guidance breaks least privilege into three scopes, and I find it the clearest way to review any agent (Fusion AI Agents: Secure by Enforcement):

• Identity scope: which principal and token the agent uses.
• Tool scope: which APIs or actions it may invoke.
• Data scope: which records and fields each action can see.

Oracle’s example: a reporting agent that summarizes procurement exceptions does not need to submit supplier changes.

Supervisor agents and cross-tenancy calls

A supervisor agent routes queries to collaborator agents and merges their answers. Collaborators can sit in a different tenancy, which is where trust quietly crosses an organizational boundary.

Oracle’s documented setup gives the supervisor a dynamic group that matches every agent resource and grants manage genai-agent-family in tenancy. That default is broad. In production I would scope it to named compartments and to the individual resource types the supervisor actually uses.

Read-only tools can run unattended. Tools that change records, move money or send messages outside the organization should wait for a person to approve them, the pattern Oracle recommends for AI Agent Studio.

Layer 4

Database-enforced authorization

This is the part of Oracle’s approach I find most significant. Oracle Deep Data Security, in Oracle AI Database 26ai, enforces the end user’s authorization inside the database, even when an agent writes the query (Oracle Deep Data Security).

Why does the location matter? Agents often connect with highly privileged service accounts and generate SQL on the fly. If authorization lives only in application code or model guardrails, one bad query gets around it. Enforced in the database, the same rules apply to every app and every agent that shares the data.

The building blocks

Oracle describes four parts (Building Trusted GenAI Experiences with Oracle Deep Data Security):

• Application identities: trusted apps and agents that connect with their own identity or on behalf of users.
• Data grants: declarative SQL policies that allow operations on specific rows, columns or individual values.
• Data roles: named groups of grants, mapped to identities in an external provider such as OCI IAM or Microsoft Entra ID.
• Secure identity propagation: carries the user’s identity and attributes into the database at runtime, for enforcement and audit.

In practice, the user signs in through an OCI identity domain or another supported provider. The application passes the user’s context and token on the database connection. The database validates the token, sets up an end-user security context and activates the mapped data roles. Users don’t need database accounts.

Nothing is visible unless a grant allows it. Oracle’s own example is a sales manager who sees only customers in their region, even if the agent generates a broader query (Introducing Oracle Deep Data Security). The controls also cover JSON duality views and vector data, so RAG retrieval only pulls authorized documents into the prompt.

Put authorization where the model cannot argue with it: in policy, and in the data.

Driver support is already in the common stacks. Oracle names JDBC and python-oracledb for passing OAuth2 tokens, and ODP.NET 23.26.2 adds extension methods for the context payload (Database-Enforced Authorization for Agentic AI .NET Applications).

Walkthrough

One request, end to end

Take a sales manager asking an agent for this quarter’s at-risk accounts. Here is what each layer checks along the way.

1. The user signs inThe identity domain issues an OAuth 2.0 token carrying her identity and group claims.
2. The endpoint validates the tokenInbound authentication rejects any caller without a valid token. IAM limits who may use the endpoint at all.
3. The agent picks a toolOnly the tools configured for this agent are available. Its read-only SQL tool runs; anything that writes waits for approval.
4. The agent calls OCI as itselfAs a resource principal, its dynamic group’s policy lets it reach only the approved database.
5. The database enforces her rightsDeep Data Security validates her token, activates her data roles, filters to her region and masks sensitive columns.
6. Audit records both identitiesThe log names her and the agent that acted on her behalf.

If a prompt injection tried to widen that query, steps 3 and 5 would still hold. That is the point of enforcing controls outside the model.

Evidence

Compliance mapping and audit evidence

Each layer produces evidence an auditor can test, and each maps to access-control requirements most programs already cover.

These mappings are indicative. Confirm the exact control IDs against the framework versions your organization is audited on.

Interactive

Is this Oracle agent ready for production?

Nine questions I would want answered before an OCI agent gets access to real data. Answer honestly; the result tells you what to fix first.

Action

Three things to do before your next agent goes live

1. Inventory every agent identity and give each an ownerList every dynamic group, Generative AI API key and cross-tenancy Endorse or Admit statement. An agent identity nobody owns is the new orphaned account.
2. Replace the quick-start policiesTenancy-wide manage genai-agent-family grants belong in sandboxes. In production, split access by role and pin it to compartments and individual resource types.
3. Push authorization into the data, then test it like an auditorWhere agents query Oracle AI Database 26ai, use Deep Data Security so the database enforces the user’s rights. Run the same agent query as two users and keep the results as evidence.

None of that depends on which model the agent runs.

The organizations that get agent security right will be the ones that stopped asking the model to behave and started making the infrastructure enforce it.

FAQ

Common questions

This perspective reflects Oracle documentation and product blog posts as of 28 September 2026. Policy syntax, resource types and product availability change, so verify current documentation before making architecture decisions. Figure 5 uses illustrative data, and framework mappings are indicative.