Audit logging for AI Object Storage

Audit logging for CoreWeave AI Object Storage provides granular records of actions performed on your object storage resources. This page explains the types of events captured, how logs are formatted and delivered, and how to enable audit logging for your organization or for specific buckets. Logs are written to a reserved bucket named cw-[ORG-ID]-audit-logs in your organization. Audit logging supports the following use cases:

• Security and compliance teams: trace data access and administrative actions.
• Platform and storage admins: understand access patterns and debug incidents.
• Application engineers: correlate storage audit logs with application logs to investigate behavior during incidents.

​

Log types

Audit logging captures two types of events: control plane events and data plane events.

​

Control plane logs

Control plane logs capture administrative and configuration-level events, including:

• Key creation
• Key revocation
• Audit logging enabled for a bucket or for the organization
• Audit logging disabled

Each control plane log entry includes the following fields (not exhaustive): Control plane logs are stored under a cw-control-plane/ prefix in your organization’s audit logging bucket, partitioned by date and time.

​

Data plane logs

Data plane logs capture authenticated access to data, including:

• Object operations such as puts, gets, and deletes
• Bucket operations such as bucket creation and listings

Each data plane log entry includes the following fields (not exhaustive): Data plane logs are stored under a cw-data-plane/ prefix in your organization’s audit logging bucket, partitioned by date and time.

​

Log format and delivery

CoreWeave batches and compresses audit log events before writing them to the audit logging bucket. Events are written to a durable message queue and bundled at least every 15 minutes before persistence. The on-disk format is line-delimited JSON, where each line is a JSON object, stored in compressed files (.json or .json.gz). Object keys follow this format: Keep the following in mind when processing audit logs:

• The order of events inside a bundle doesn’t necessarily match the order in which CoreWeave generated them.
• The order of bundles written to the audit logging bucket doesn’t reflect the precise generation order.
• A single request (for example, a multi-object delete) can generate multiple log entries.

​

Audit logging bucket

Each organization has one audit logging bucket, named cw-[ORG-ID]-audit-logs, where [ORG-ID] is your organization ID. The bucket is isolated per organization and governed by your organization access policies and bucket access policies. You are responsible for managing the data in the bucket and pay storage fees for that data. For billing details, see Usage-based billing and pricing.

​

Configuration

Audit logging can be configured at the organization level or at the individual bucket level, so you can choose the right scope for your use case. Control plane logging can only be enabled at the organization level. It cannot be scoped to individual buckets. When you enable data plane logging at the organization level, it applies only to new buckets created after the setting is enabled. Buckets that already exist keep their prior data plane logging state until you enable data plane logging for each bucket. Because high-traffic buckets can produce large volumes of log data, per-bucket logging is more targeted and can help avoid unexpected storage fees.

​

Enable audit logging

Enabling audit logging requires steps from both CoreWeave and your team. CoreWeave provisions your destination bucket and enables the feature on the backend. You configure the bucket access policy and logging settings.

​

Prerequisites

Enabling audit logging requires two separate permissions:

• To set the bucket access policy: An AI Object Storage Access Key and an organization access policy that allows s3:PutBucketPolicy on the cw-[ORG-ID]-audit-logs bucket (or s3:* on all buckets).
• To call the Object Storage API: The Object Storage Admin IAM role and a CoreWeave API access token.

​

Steps

1. Contact CoreWeave support to request enablement, and include your organization name and Org ID. Your Org ID is a short hexadecimal string (for example, ab1cd2). Find it on the Settings page of your Cloud Console account. CoreWeave creates your cw-[ORG-ID]-audit-logs destination bucket as part of the enablement process.
2. After CoreWeave creates the destination bucket, apply a bucket access policy granting the CoreWeave audit logging service account permission to write logs. The policy must grant at minimum s3:ListBucket and s3:PutObject. Replace [ORG-ID] with your organization ID.
   audit-logging-bucket-access-policy.json

   {
     "Statement": [
       {
         "Sid": "AllowAuditLoggingServiceAccount",
         "Action": [
           "s3:ListBucket",
           "s3:PutObject"
         ],
         "Effect": "Allow",
         "Principal": {
           "CW": [
             "arn:aws:iam::coreweave:static/audit-logs"
           ]
         },
         "Resource": [
           "arn:aws:s3:::cw-[ORG-ID]-audit-logs",
           "arn:aws:s3:::cw-[ORG-ID]-audit-logs/*"
         ]
       }
     ],
     "Version": "2012-10-17"
   }
   
   For instructions on applying this policy using S3 clients or Terraform, see Manage bucket access policies.
3. Notify CoreWeave that you’ve applied the bucket access policy, either by replying to your CoreWeave support ticket or by notifying CoreWeave through your support Slack channel. The CoreWeave admin then finishes enabling audit logging for your organization. After CoreWeave confirms that audit logging is enabled for your organization, you can choose which event types to capture.
4. Call the Object Storage API to enable the types of logs you want:
   • Use organization-level settings to enable control plane logging, data plane logging for all buckets created after the setting is enabled, or both.
   • Use bucket-level settings to enable data plane logging for a specific bucket only.
   • Organization-level
   • Bucket-level

   Organization-level settings let you enable control plane logging, data plane logging for all buckets created after the setting is enabled, or both.Set the flags to true or false based on which event types you want to log:

   • controlPlaneAuditLoggingEnabled: Control plane logging
   • bucketAuditLoggingEnabled: Data plane logging for buckets created after the setting is enabled

   Save the following as organization-settings.json:

   organization-settings.json

   {
     "settings": {
       "controlPlaneAuditLoggingEnabled": true,
       "bucketAuditLoggingEnabled": true
     }
   }
   

   Submit the request:

   Example request

   curl -X PUT https://api.coreweave.com/v1/cwobject/organization/settings \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer [API-ACCESS-TOKEN]" \
     -d @organization-settings.json
   

   A successful response returns the updated organization settings:

   Response status code 200

   {
     "settings": {
       "controlPlaneAuditLoggingEnabled": true,
       "bucketAuditLoggingEnabled": true
     }
   }
   

   Bucket-level settings enable data plane logging for a specific bucket. Control plane logging is not available at the bucket level.Save the following as bucket-settings.json, replacing [BUCKET-NAME] with the name of the bucket to monitor. Set the auditLoggingEnabled flag to true to enable data plane logging for the bucket.

   bucket-settings.json

   {
     "bucketName": "[BUCKET-NAME]",
     "settings": {
       "auditLoggingEnabled": true
     }
   }
   

   Submit the request:

   Example request

   curl -X PUT https://api.coreweave.com/v1/cwobject/bucket/settings \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer [API-ACCESS-TOKEN]" \
     -d @bucket-settings.json
   

   A successful response returns the updated bucket settings:

   Response status code 200

   {
     "settings": {
       "auditLoggingEnabled": true
     }
   }
   

   You can also modify bucket settings in Terraform using the coreweave_object_storage_bucket_settings resource.