Skip to main content
You can exchange a CoreWeave API access token directly for temporary AI Object Storage credentials, without creating a separate static Access Key. If you already authenticate with a CoreWeave API access token, CoreWeave recommends this method over creating a static Access Key in Cloud Console, because it removes the extra key-creation step and carries the principal’s SCIM group memberships in the iam:[ORG-ID]:groups condition key for group-based and attribute-based access control. The exchange uses the AWS container credentials feature. Your client requests credentials from the AI Object Storage API access token endpoint, passing your API access token as a bearer token.
Exchanging an API access token for temporary credentials requires the Object Storage Admin role or an organization access policy that grants cwobject:CreateAccessKey.

​
Configure your environment

  1. Ensure you’re using a supported S3 client. The minimum supported versions are awscli >= 2.33.2 and boto3 >= 1.42.5.
  2. Set the following environment variables. Replace [API-ACCESS-TOKEN] with your API access token and [AVAILABILITY-ZONE] with the CoreWeave Availability Zone you’re using:
    Set the environment variables
    export AWS_CONTAINER_CREDENTIALS_FULL_URI=https://api.coreweave.com/v1/cwobject/temporary-credentials/api-token
export AWS_CONTAINER_AUTHORIZATION_TOKEN="Bearer [API-ACCESS-TOKEN]"

aws configure set s3.addressing_style virtual

export AWS_REGION="[AVAILABILITY-ZONE]"
export AWS_ENDPOINT_URL_S3="https://cwobject.com"
  3. Test your configuration by listing your buckets:
    List your buckets
    aws s3 ls
On success, CoreWeave validates the API access token and returns temporary credentials with the identity format coreweave/[UID]. The returned credentials inherit permissions from your organization access policies and any applicable bucket access policies.

​
Group-based access control

Because the temporary credentials carry the principal’s SCIM group memberships in the iam:[ORG-ID]:groups condition key, you can write access policies that grant or deny access based on group membership instead of naming individual principals. To use this:
Last modified on June 29, 2026