Home / OCI

OCIHow-toBeginner

Introduction to OCI Audit: find who created, changed or deleted a resource

How OCI Audit records every API call, how to search it in the console and with the OCI CLI, which fields matter, and how to keep audit events longer and alert on risky actions.

Deepak Bhardwaj4 min read

Applies toOCI Audit service, OCI Logging search, Service Connector Hub, OCI CLI 3.x

What OCI Audit records

Every call to an OCI public API (console clicks, CLI, SDK, Terraform) is recorded by the Audit service automatically. You don't have to enable anything. Each event tells you:

  • Who: user or principal (including instance principals and resource principals).
  • What: the operation, such as TerminateInstance, UpdateSecurityList, DeleteBucket.
  • Where: compartment, resource OCID, region.
  • When and from where: timestamp, source IP, user agent (console, CLI, Terraform).
  • Result: response status code.

Audit events are kept for 365 days by default (you can check or change the tenancy retention setting in the Audit console). They're per region, so search the region where the change happened.

Step 1: Search in the console

  1. Navigation menu > Observability & Management > Logging > Audit.
  2. Pick the compartment and time range.
  3. Use the search box, for example TerminateInstance or a resource OCID.

The Logging Search page lets you query audit events with the logging query language, which is more flexible:

search "ocid1.tenancy.oc1..aaaa.../_Audit"
| where data.eventName = 'TerminateInstance'
| sort by datetime desc

Include sub-compartments with _Audit_Include_Subcompartment in the search path.

Step 2: Search with the OCI CLI

The CLI needs a start and end time (UTC, RFC 3339):

COMPARTMENT=ocid1.compartment.oc1..aaaa...

oci audit event list \
  --compartment-id $COMPARTMENT \
  --start-time 2026-11-01T00:00:00Z \
  --end-time   2026-11-02T00:00:00Z \
  --all \
  --query "data[?!starts_with(data.\"event-name\",'Get') && !starts_with(data.\"event-name\",'List')].{time:\"event-time\", event:data.\"event-name\", who:data.identity.\"principal-name\", ip:data.identity.\"ip-address\", res:data.\"resource-name\"}" \
  --output table

Field names in CLI output use hyphens (event-time, principal-name); the JMESPath query must quote them as above.

Find who deleted a specific resource

oci audit event list --compartment-id $COMPARTMENT \
  --start-time 2026-10-26T00:00:00Z --end-time 2026-11-02T00:00:00Z --all \
  --query "data[?contains(data.\"event-name\",'Delete') || contains(data.\"event-name\",'Terminate')].{time:\"event-time\", event:data.\"event-name\", who:data.identity.\"principal-name\", res:data.\"resource-id\"}" \
  --output table

Tip

Large time ranges in busy compartments return a lot of read events (Get*, List*). Narrow the window to the hours around the incident first, then widen it.

Step 3: Read an event

The fields you'll use most:

Field Example Meaning
data.eventName UpdateSecurityList The API operation
data.identity.principalName deepak@example.com User or principal
data.identity.principalId ocid1.user... / ocid1.instance... OCID of the caller; an instance OCID means instance principal
data.identity.ipAddress 203.0.113.10 Source IP
data.identity.userAgent Oracle-JavaSDK..., Terraform/... Tool used
data.resourceId ocid1.securitylist... The resource touched
data.request.parameters / data.stateChange — What changed (before/after for some services)
data.response.status 200, 409, 404 Did it succeed

A principalId that is an instance or function OCID tells you an automated job made the change, not a person.

Step 4: Keep events longer and send them elsewhere

Use Service Connector Hub to copy audit events to Object Storage (cheap long-term storage) or to Logging Analytics / a SIEM:

  1. Observability & Management > Connectors > Create connector.
  2. Source: Logging, log group _Audit, compartments to include.
  3. Target: Object Storage bucket (with retention rules if you need immutability), or Streaming for a SIEM.

The connector needs IAM policies to write to the target; the console offers to create them.

Step 5: Alert on risky actions

Use the Events service with a Notifications topic. Example rule matching security list and NSG changes, policy changes and bucket visibility changes:

{
  "eventType": [
    "com.oraclecloud.virtualnetwork.updatesecuritylist",
    "com.oraclecloud.virtualnetwork.updatenetworksecuritygroupsecurityrules",
    "com.oraclecloud.identitycontrolplane.updatepolicy",
    "com.oraclecloud.objectstorage.updatebucket"
  ]
}

Event type names vary by service; copy the exact names from the Events rule builder in the console rather than typing them from memory.

Common questions

Question Answer
Can I see who read an object in a bucket? Object-level reads are not in Audit; enable Object Storage service logs (read/write logs) on the bucket
I can't find an event Wrong region, wrong compartment (try include sub-compartments), or time range in local time instead of UTC
Can audit events be deleted? No; you can only change the retention period
Does Audit show data inside a database? No; use Data Safe / database auditing for SQL-level activity

Prevent problems later

  • Ship audit events to a separate, locked-down compartment or bucket owned by security.
  • Create Events alerts for network, IAM policy and bucket-visibility changes in production compartments.
  • Use separate users or tagged automation principals so "who" is always clear; avoid shared accounts.
  • Tag resources with an owner so the audit trail and the person to call line up.

Related fixes