Oracle began its AI transformation with three goals: improve employee productivity, strengthen security, and improve customer experience. IAM was central to putting these goals into practice. AI agents needed access to enterprise systems, and we needed to enforce limits on what they could read, change, and delegate.

For Enterprise ChatGPT, we built security for Model Context Protocol (MCP) connections so employees could authorize access and their permissions would remain in effect at the backend. With Codex and operations agents, we introduced just-in-time access, least-privilege reviews, and human approval for sensitive actions. For autonomous code scanners, workload identity federation let agents running in OKE call frontier models without storing long-lived provider API keys.

Console AI added service-specific Deny policies to restrict destructive operations, even where a covered user had broader permissions. DB Tools is extending the MCP foundation to database access and delegation between agents, with user context preserved and each participant limited to its part of the task.

These deployments established two complementary control layers: OCI IAM Policy governs permitted actions and explicit restrictions on OCI resources; MCP Security secures connections and delegated identity across MCP-compliant services. The following examples explain how we introduced these controls as AI moved from retrieving information to performing operations and delegating work, and how each shaped our principles for secure AI adoption.

OCI IAM Policy and MCP Security govern access across Oracle’s AI initiatives. Dashed lines show authorization relationships; solid lines show runtime calls

Figure 1. OCI IAM Policy and MCP Security govern access across Oracle’s AI initiatives. Dashed lines show authorization relationships; solid lines show runtime calls

Connecting ChatGPT to Internal Systems without giving it “God Mode” access

Oracle made Enterprise ChatGPT available to employees to improve productivity. Employees could use it to draft content, explain concepts, and analyze information they supplied. But it could not answer questions about release decisions or project status without access to the documents and conversations inside Oracle.

Consider an employee asking: “Why was this release postponed, what needs to be resolved before it can ship, and who owns each action?”

The answer might be spread across a discussion in Slack, a design decision in Confluence, a readiness checklist in SharePoint, and an approval thread in Outlook. ChatGPT needed to find the relevant information across those systems and assemble an answer with supporting sources.

We built an MCP layer to connect those systems. Our first requirement was to preserve the employee’s permissions across every connection.

We could have given an MCP server a privileged account with access to every connected workspace. But an employee using ChatGPT could then retrieve information through that account that they were not authorized to see themselves.

To address this, we built MCP security capabilities in OCI IAM:

OAuth authorization-server discovery lets clients discover where to authenticate and request access.
PKCE and public-client support protect authorization flows for clients that cannot safely hold a shared secret.
Client ID Metadata Documents, or CIMD, support client identification and metadata without distributing shared client secrets.
Resource indicators let a client identify the MCP server or resource it is requesting access to.
User consent and identity propagation let employees approve the requested scopes and carry their authenticated context into backend authorization.

Before ChatGPT acts on an employee’s behalf, the employee approves the access being requested. Consent to read information does not authorize sending messages or changing records. It also cannot grant permissions the employee does not already have.

The backend receives trusted user context and checks the requested operation against that user’s permissions. The MCP server also checks whether the client is authorized to invoke the tool.

For the release question, ChatGPT can combine the Slack discussion, Confluence decision, SharePoint checklist, and Outlook correspondence that the employee is allowed to access. A restricted discussion or document remains unavailable. If the employee approved only read access, the assistant cannot update the release checklist or send an approval email.

This established least privilege for the assistant: its access is limited by both the employee’s permissions and the scopes the employee approves. The employee gets an answer grounded in internal information while restricted records remain inaccessible.

Rolling out Codex without creating a path to unsupervised production changes

With Codex for developers and agents for operators, access extended beyond retrieving information to executing tasks. Coding assistants could inspect code, propose changes, and run development tools. Operations agents also needed access to infrastructure configuration and health information.

Preserving a user’s permissions was only a starting point when those permissions already included production access. An agent could encounter an operator’s credentials and use them to reach production. A request to investigate a problem could turn into an infrastructure change if those credentials carried broad permissions.

We addressed this through three programs.

Just-in-time access. We moved the production access covered by the developer and operator rollout to just-in-time access. Privileged access is granted for approved work and a limited period, reducing the standing authority available to an agent operating in the environment.
Human approval for sensitive actions. We placed these actions behind human-in-the-loop controls. An agent attempting a protected deletion operation cannot execute it without the required human approval.
Least-privilege analysis. We reviewed access and removed permissions beyond those needed for the assigned work. Those restrictions apply when an agent acts using the person’s delegated authority as well.

For example, an operator can ask an agent to investigate an unhealthy load balancer. The agent may inspect the permitted configuration and health information. It cannot turn that investigation into an unsupervised deletion.

These programs added zero standing access and human oversight to the rollout requirements. A coding assistant can work on an application without automatically receiving authority over its production infrastructure. When a task needs additional access, the grant is limited to the approved work and duration, and protected actions still require human approval. The agent’s credentials and execution tools must enforce those limits.

Giving autonomous scanners trusted access to frontier models

Autonomous code scanners introduced a different identity problem: they needed to call external models without an employee signing in for each scan. The scanners used frontier models to help identify potential vulnerabilities in code, but the services running the scans were using API keys to call Anthropic and OpenAI.

Those keys had to be stored, distributed, and rotated. If exposed through a container, configuration file, or execution log, a key could be copied and used outside the intended scanner to make calls under Oracle’s provider account for as long as it remained valid.

We built workload identity federation support so that an agent could authenticate using the identity of the workload running it.

For a scanning agent running in an Oracle Container Engine for Kubernetes (OKE) container, the model-access flow is:

The agent authenticates using its OKE workload identity and obtains an IAM-issued JWT.
It presents that JWT to the configured federation endpoint at Anthropic or OpenAI.
The provider validates the issuer and required claims, then maps the workload to an approved provider service account.
The provider issues a short-lived access token with the permitted authority.
The agent uses that token to call the model.

The provider’s trust configuration determines which workload may obtain a token. The mapped service account and applicable scopes determine what the token permits. OpenAI and Anthropic document these federation and service-account mapping mechanisms. [1], [2]

This established no standing credentials for model access. We removed long-lived provider API keys from the scanner’s configuration; the workload obtains temporary access when it runs. The agent can assume only the permissions defined for its approved provider identity.

Our broader WIF work also addresses standing users and claims-based authorization for OCI resource access. As described in Workload Identity Federation with Ephemeral, Zero-Footprint Principal, a trusted workload can receive a temporary OCI principal session without creating a permanent OCI user for every workload. Validated claims—such as the service account, namespace, repository, or environment—can become inputs to IAM policy. [3]

For the scanner, the result is specific: it can obtain temporary access to an approved model using its runtime identity. It still needs permission to read the repository being scanned, and model access does not authorize merging a fix, deploying code, or changing infrastructure.

Restricting destructive operations through Console AI

Oracle also introduced Console AI in the OCI Console. A user can ask a question in natural language, receive a proposed plan, and use supported workflows that execute through the MCP gateway.

The workload identity and temporary-access controls established who could act and for how long. Console AI added a decision about the calling service itself: some operations available to the user had to remain unavailable through the AI service.

To enforce that distinction, we built IAM Deny guardrails that can evaluate both the user’s context and the context of the calling service. We also use Deny guardrails to restrict operator access.

For Console AI, on-behalf-of authorization preserves whose authority is being used. Trusted service context identifies that the operation originates from the AI service. A policy can therefore restrict an operation through Console AI even when an Allow policy grants the user broader management permissions.

The public Console AI documentation provides a concrete example: a Deny policy matching the oci-mcp-server service and the AUTONOMOUS_DATABASE_DELETE permission. [4]

Under that policy, a covered user can inspect a database and approve other supported operations they are authorized to perform. A direct request to delete the Autonomous Database through Console AI is rejected. Human approval does not override an applicable Deny.

The documented policy applies to direct Console AI requests and non-exempt identities. Default-domain Administrators are exempt, and downstream calls by other services need their own restrictions. Console AI is currently a pre-production preview. [4], [5]

This applies least privilege to the calling service as well as the user. Knowing who authorized an operation is not sufficient; IAM also needs to know which service is acting. The applicable Deny policy enforces that service’s restrictions even when the user has broader Allow permissions.

Extending the same MCP foundation to DB Tools and delegated work

The DB Tools team is connecting agents to Oracle Database through MCP. A database agent can use exposed tools to perform authorized database work. More complex tasks can involve one agent delegating part of the work to another.

This uses the MCP authentication and consent foundation introduced for enterprise assistants. Delegation extends the least-privilege requirement: each agent needs authority for its part of the task, and passing work to another agent must not expand that authority.

Consider a user asking: “Create a PDF report of the overnight batch failures and save it in the approved operations folder in Object Storage.”

That request can involve three steps:

Step	Authority needed	Authority the step does not require
1. A database agent retrieves the permitted batch-execution records.	Read the approved database records.	Change job results, read unrelated data, or administer the database.
2. A reporting agent converts the approved results into a PDF.	Process the supplied report data.	Receive the database agent’s credentials or query additional tables.
3. An agent stores the report in Object Storage.	Write the report to the approved location.	Delete existing objects or write to unrelated buckets.

We built delegation support so that the user’s context can survive these handoffs while each acting agent remains identifiable. Each service call obtains the appropriate time-bound authority for its target and task. A token used to access the database is not passed around as a general credential for PDF generation and storage.

Several IAM capabilities support this workflow.

RFC 8693 token exchange represents the original subject and the agent acting on that subject’s behalf. [6]
Delegation metadata records whether an application or user permits delegation and how far delegation may extend. IAM policy controls which permissions can be granted at each exchange.
Agent and MCP-server application classification lets administrators identify the participants and apply the appropriate configuration.
Cross-App Access and identity assertions address handoffs to another application or authorization domain: the receiving system validates trusted identity context and issues access under its own policy.

The Database Tools MCP documentation also makes runtime identity an explicit choice. Requests can run under the authenticated principal or the MCP server’s workload identity. That choice must be reflected in the backend authorization so that using a server identity does not give callers broader database access. [7]

For the report example, the database agent can retrieve the permitted records, the reporting agent can produce the PDF, and the storage step can write it to the approved destination. None of those handoffs should expand the user’s original authorization.

Multiple agents also make continuous audit a requirement across the workflow. For this report, the audit trail needs to identify who requested it, which agent queried the database, which agent generated the PDF, and which identity wrote the object. The authorization and service records must let us connect those operations to the permissions used at each step.

IAM at the center of AI transformation

IAM is central to Oracle’s AI transformation because it enables assistants and agents to use enterprise systems within explicit limits. OCI IAM Policy governs permitted actions and restrictions on OCI resources. MCP Security secures connections to MCP-compliant service and preserves user and agent context across handoffs.

Together, these layers support the controls introduced throughout Oracle’s adoption: employee data permissions, temporary privileged access, approval for sensitive actions, trusted workload identities, and constrained delegation. These controls help Oracle manage who may act, on whose behalf, and with what authority as AI use expands.