Oracle adds controls for AI assistants to access tools across business applications

Oracle is introducing identity controls that let approved AI assistants retrieve information and act across business applications without giving them unrestricted access. In its October 9 announcement, the company described new Oracle Cloud Infrastructure Identity and Access Management capabilities that separate client approval, tool permissions and authorization in the next application.

The starting problem: access without a master key

Oracle outlined the catalyst in an October 5 account of its internal AI deployments. Enterprise ChatGPT needed access to company documents and conversations to answer employees’ questions. Oracle said it built connections using Model Context Protocol, or MCP—a shared way for AI applications to discover and call software tools.

A privileged account spanning connected workspaces would have let an employee retrieve information they were not entitled to see. Oracle instead preserved the employee’s permissions at the backend. Employees approve requested access, and the MCP server separately checks whether the client may invoke a tool. Consent to read does not authorize sending messages or changing records.

The new announcement explains how that access model extends to approved clients and workflows spanning applications. Oracle illustrates it with a sales analyst asking an assistant to identify accounts with declining orders, then create follow-up tasks. Reading the report and creating a task require separate permissions.

Approve the client, then constrain the request

Client onboarding starts with Client ID Metadata Documents, or CIMD. An application publishes its OAuth configuration—the settings used to request authorized access—in a document hosted at an HTTPS address. That address becomes its client identifier. OCI IAM retrieves and validates the document, reducing repeated manual registration across identity domains.

Two approvals with different jobs

• The identity-domain allowlist specifies which metadata locations IAM trusts.
• The resource-application allowlist specifies which CIMD clients can access a particular application. Approval for sales reporting need not open other applications.

The client discovers the authorization service through the MCP server’s published metadata rather than relying on hard-coded endpoints. It identifies the target resource and requests permissions. For interactive public clients, Oracle uses Proof Key for Code Exchange, or PKCE, which requires a client-generated verifier to protect against interception of an authorization code.

IAM returns an access token identifying the server that should accept it and the permissions it carries. The MCP server validates those details before running a tool. Oracle’s Database Tools example exposes named SQL reports with preset parameters and group-based access; the database connection’s permissions still govern the underlying data.

Crossing applications without another approval screen

Creating a follow-up task takes the workflow into another application, with its own users and permissions. OCI IAM’s cross-app access handles that transition through two backend exchanges. The intermediate credential is called an Identity Assertion JWT Authorization Grant, or ID-JAG. It carries signed identity information to the receiving domain, rather than serving as the final API access token.

The receiving domain checks the grant and client relationship, maps the person to an active local user, and applies its authorization rules. Oracle says compatible grants from trusted external identity providers, including Okta, are also accepted when inbound trust, client bindings and user mapping are configured.

Once administrators configure those relationships, the workflow can continue without another interactive user-approval step at the target authorization server. That removes a prompt, not the receiving application’s control over permitted actions. Oracle instructs developers to keep exchange credentials and tokens in the backend, separate from the public client’s configuration.

For teams putting this into operation, Oracle recommends linking IAM records with MCP and application logs to connect permission decisions to executed actions. Identity controls remain one layer: database permissions, safe tool design and runtime security still have to enforce the boundaries around the assistant’s work.