Policies

Control access to endpoints and resources

Policies define who can access what within CoreWeave's AI Object Storage and S3-compatible APIs. They serve as the foundation for controlling access to resources and actions, ensuring that users and systems only perform operations they're explicitly authorized to do. This guide explains how policies are evaluated, the differences between organization and resource policies, and key exceptions to consider when designing secure, predictable access controls.

Both the AI Object Storage API and the S3-compatible API use two types of policies: Organization Policies and Resource Policies.

• Organization Policies apply to all principals and resources across the entire organization.
• Resource Policies apply only to a specific resource, such as a Bucket Policy applied through the S3 API's s3:PutBucketPolicy call.

Policy evaluation order

The AI Object Storage API evaluates policies by following these steps in sequence:

1. Evaluate all organization policies:
   • If a Deny policy exists, then reject the request.
   • If an Allow policy exists, then continue to evaluate all valid resource policies.
   • If no Allow or Deny policy exists, then the request is rejected implicitly.
2. Evaluate all valid resource policies:
   • If no resource policies exist, then the request is allowed implicitly.
   • If a Deny policy exists, then reject the request.
   • If an Allow policy exists, then accept the request.
   • If a resource policy exists, but it does not explicitly Allow or Deny, then reject the request implicitly.

The following diagram illustrates this workflow:

Exceptions and special cases

Most requests follow the evaluation process shown above. However, there are a few notable exceptions and behaviors to be aware of.

Admin users in the Cloud Console and cwobject API

Users in the admin group (as defined in the Cloud Console) have unrestricted access to all cwobject: API actions. A special static policy grants those users full access to those actions.

Warning

Restrict admin group membership to trusted users.

Admin users and S3 API access

Policy configuration is still required for admin users to access S3 API endpoints. Admin status does not grant automatic access to the S3 API.

s3:PutBucketPolicy is evaluated as a global operation

The s3:PutBucketPolicy action is treated as a global operation and only evaluates organization policies — it does not consider any resource-level policies. To successfully use this action, the organization policy must:

• explicitly allow s3:PutBucketPolicy, and
• reference "resources": ["*"] or "resources": ["my-bucket"] to ensure the bucket is selected by the policy.

This behavior ensures that you cannot accidentally lock yourself out of a bucket using a misconfigured bucket policy. Admin users can always recover access through the cwobject APIs.

Global operations require wildcard * in resources

Some operations act across many resources or are not tied to a specific resource. These include:

• All cwobject: actions
• S3 operations such as s3:ListAllMyBuckets

To allow these actions, the policy must specify the wildcard * in the resources field. For example:

Example

"resources": ["*"]

Omitting the wildcard will result in these actions being denied, even if the action is explicitly listed.

Policy example

The following policy demonstrates two common use cases.

The first statement allows any user to:

• Create access keys
• Create SAML access keys
• View access policies

The second statement grants full access to all S3 API actions.

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "cwobject-access",
    "statements": [
      {
        "name": "allow-token-creation",
        "effect": "Allow",
        "actions": [
          "cwobject:CreateAccessKey",
          "cwobject:CreateAccessKeySAML",
          "cwobject:ListAccessPolicy"
        ],
        "resources": ["*"],
        "principals": ["*"]
      },
      {
        "name": "s3-api-access",
        "effect": "Allow",
        "actions": [
          "s3:*"
        ],
        "resources": ["*"],
        "principals": ["*"]
      }
    ]
  }
}

Because admins already have unrestricted cwobject: access, this policy effectively limits non-admin users to only the actions specified — a useful pattern for granting minimal initial access and managing permissions centrally.