Oracle details work on AI-agent identities and action-specific approvals

An AI agent with permission to delete a database should not necessarily be allowed to delete every database it encounters. Oracle’s October 30 disclosure describes work on cloud identity controls that would distinguish those decisions, alongside temporary agent identities and task-limited permissions. These are capabilities in development, not a newly available product.

The work would extend Oracle Cloud Infrastructure Identity and Access Management, or OCI IAM—the system that manages identities and access permissions. Oracle already provides authentication, workload identities, centrally managed policies and audit capabilities. Its proposed additions address agents that delegate work and need different permissions as a task progresses.

Oracle grounds the proposal in its internal deployments. When connecting Enterprise ChatGPT to internal systems, it focused on preserving employees’ existing information-access permissions. As Codex and operator agents began using tools in environments with production access, Oracle says it introduced access granted only when needed, reviews to minimize permissions and human approval for sensitive operations.

One account versus a traceable chain of agents

A shared login can obscure who did what. Oracle describes an operator investigating an incident through an agent that delegates to specialized agents. If all of them use the operator’s credentials or one application identity, the audit record may identify the account without identifying the particular agent responsible for an operation.

Oracle is developing distinct, short-lived identities for individual agents and subagent executions. Each would be linked to the user, software workload or parent agent responsible for creating it. Audit records would remain after an agent’s execution ends. The intended record would show which agent acted, whose authority it used and how that authority passed through delegated tasks.

Temporary authority, with a ceiling

The permission problem is different from the identity problem. An agent might begin by reading logs and metrics, then discover that fixing the issue requires a configuration change. Oracle contrasts two unsatisfactory starting points: broad permissions expose more than the task initially needs, while read-only access can prevent the agent from finishing.

IAM Roles are being developed to let authorized users and agents assume defined permissions for limited periods. As the work changes, an agent could request additional authority, but only within the maximum established by IAM policy. A subagent would receive the same or narrower permissions than its parent—not a broader grant simply because the work was delegated.

Permission would not settle every action

Oracle’s database example illustrates the extra check. An agent cleaning up unused resources might legitimately have delete permission. Deleting a database supporting a production service, however, could disrupt customers. The proposed contextual authorization would use available trusted signals to decide whether an otherwise permitted operation should proceed, be blocked or require a person’s approval.

Human approval could be required by policy for designated sensitive operations or triggered by the contextual decision. Oracle says OCI IAM could verify the approver through a YubiKey touch or biometric verification using OCI Identity Assurance, then bind that approval to the specific action. That would connect the approval to both a verified person and a particular operation.

The verification component has an existing foundation. In its October 27 security announcement, Oracle said OCI Identity Assurance can use biometrics to confirm the identity and presence of someone approving sensitive actions, such as releasing payments or changing access permissions. That capability explains the proposed human check; it does not make the newly described agent-authorization workflows available.