Organization Access Policies

Control access to all principals and resources across the entire organization

AI Object Storage organization access policies enforce permissions across your entire organization. They sit at the top of the policy hierarchy, taking effect before any bucket-level rules. Written in JSON with the same syntax as bucket access policies, they apply to both the S3-compatible API and the AI Object Storage API.

These policies automatically cover every resource, bucket, and user in your account. By centralizing access rules, you ensure that global security standards and compliance requirements are consistently applied. Because organization access policies override bucket access policies, they serve as the first line of defense for every request in your AI Object Storage environment.

How to set an organization access policy

To create an access policy, use the Cloud Console, or follow these steps:

Prepare a JSON file (for example, policy.json) similar to the examples below.

Send the JSON document to https://api.coreweave.com/v1/cwobject/access-policy with an HTTP client such as curl.

$
curl -X POST https://api.coreweave.com/v1/cwobject/access-policy \
  -H "Content-Type: application/json" \
  --data @policy.json

The endpoint returns a confirmation response.

For full request and response schemas, see the AI Object Storage API reference.

Key considerations

AI Object Storage organization access policies have some specific aspects and considerations that are important to understand:

Policy Aspect	Description
Admin Access	A special static internal policy grants Cloud Console admin users unrestricted access to all `cwobject:` API actions, but admin status does not grant S3 API access; S3 API access must be explicitly granted via org or bucket access policies.
Group Usage	Cloud Console groups are not allowed in organization access policies; use UIDs (from Cloud Console) or SAML users and groups instead.
s3:PutBucketPolicy	The `s3:PutBucketPolicy` action is a global operation that only evaluates organization policies (ignoring bucket-level policies) and requires org policies to explicitly allow `s3:PutBucketPolicy` or `s3:` with `"resources": [""]` or specific bucket names. This behavior is designed to prevent users from accidentally locking themselves out of a bucket with a misconfigured bucket access policy.
Global Operations	All `cwobject:` API actions and the `s3:ListAllMyBuckets` operation are global operations that must specify `"resources": ["*"]`.
Policy Evaluation Order	CoreWeave evaluates policies in two steps, with organization policies evaluated first (before any bucket-level policies).
Policy Management Recommendation	Prefer managing access via organization policies for broad, centralized control; use bucket policies only for bucket-specific features such as bucket lifecycle configuration.

Structure of organization access policies

Organization access policies use JSON objects with three top-level fields: version, name, and statements. The statements field is an array of objects. Each statement includes the following:

name: A unique identifier for the policy statement.
effect: Indicates whether the policy allows or denies access. Must be either Allow or Deny.
principals: The users, roles, or groups to which the policy applies.
actions: The specific actions that the policy allows or denies.
resources: The resources to which the policy applies, specified in short-form names (not full ARNs).

Version

The version specifies the policy language version and is mandatory. For organization access policies, set "version": "v1alpha1". This internal CoreWeave identifier is not the same as the date-based format (for example, "2012-10-17") used in standard S3 bucket access policies.

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "example-org-policy",
    "statements": [
      {
        "name": "allow-s3-get-object",
        "effect": "Allow",
        "principals": ["*"],
        "actions": ["s3:GetObject"],
        "resources": ["my-bucket/*"]
      }
    ]
  }
}

Name

At the top level, within the policy object, name is required. It provides a human-readable identifier for the overall organization access policy.

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "my-organization-wide-policy",
    "statements": [
      {
        "name": "allow-all-s3",
        "effect": "Allow",
        "principals": ["*"],
        "actions": ["s3:*"],
        "resources": ["*"]
      }
    ]
  }
}

Statements

The statements element is required, and acts as the main container for access rules. It can contain a single policy statement or an array of multiple statements, with each individual statement enclosed in curly braces.

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "multi-statement-policy",
    "statements": [
      {
        "name": "allow-s3-api-access",
        "effect": "Allow",
        "actions": ["s3:*"],
        "resources": ["*"],
        "principals": ["*"]
      },
      {
        "name": "allow-cwobject-api-actions",
        "effect": "Allow",
        "actions": ["cwobject:CreateAccessKey", "cwobject:ListAccessPolicy"],
        "resources": ["*"],
        "principals": ["coreweave/UserUID"]
      }
    ]
  }
}

Name (within Statement)

Within each individual statement, name is required. It serves as a short, human-readable identifier for that specific policy statement, similar to Sid in bucket access policies.

Each name must be unique within the JSON policy.

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "my-policy",
    "statements": [
      {
        "name": "MyUniqueStatementIdentifier",
        "effect": "Allow",
        "principals": ["*"],
        "actions": ["*"],
        "resources": ["*"]
      }
    ]
  }
}

Effect

The Effect field is mandatory and must be either Allow or Deny (case-sensitive). It determines whether the statement grants or denies the specified actions on the listed resources for the designated principals. By default, all access is denied.

Setting Effect to Allow grants permission; setting it to Deny explicitly rejects the request and overrides any Allow. During policy evaluation, an explicit Deny in an organization access policy immediately rejects the request.

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "deny-specific-deletion",
    "statements": [
      {
        "name": "prevent-object-deletion",
        "effect": "Deny",
        "principals": ["coreweave/UserUID"],
        "actions": ["s3:DeleteObject"],
        "resources": ["my-sensitive-bucket/*"]
      }
    ]
  }
}

Principals

The principals field is required. It defines which users, roles, or groups the policy applies to.

For organization access policies, only short-form identifiers are supported. If you use a full ARN, the policy will fail with an error.

Cloud Console Users: Use the user's UID, found in the user's Settings in the Cloud Console, prefixed with coreweave/. For example, coreweave/UserUID.
SAML Users or Groups: When using SAML with an Identity Provider (IdP), reference users or groups using the format role/GroupName. The GroupName must match the PrincipalName attribute in the SAML assertion.
Wildcard: Use "*" to apply the policy to all principals.

Info

Groups created in the Cloud Console (like admin) cannot be used in organization access policies. To assign policies to groups, use a SAML-enabled Identity Provider (IdP).

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "principal-access-examples",
    "statements": [
      {
        "name": "allow-specific-user",
        "effect": "Allow",
        "principals": ["coreweave/UserUID"],
        "actions": ["s3:*"],
        "resources": ["my-bucket", "my-bucket/*"]
      },
      {
        "name": "allow-saml-admin-group",
        "effect": "Allow",
        "principals": ["role/Admin"],
        "actions": ["s3:*", "cwobject:*"],
        "resources": ["*"]
      },
      {
        "name": "allow-all-users-read-access",
        "effect": "Allow",
        "principals": ["*"],
        "actions": ["s3:GetObject", "s3:ListBucket"],
        "resources": ["my-bucket", "my-bucket/*"]
      }
    ]
  }
}

Actions

The actions field is required. It defines which operations the policy allows or denies. You can use wildcards (like s3:* or cwobject:*) to cover multiple actions at once. Organization access policies can include actions from two APIs:

S3 API: Use s3:* to reference all S3 actions.
AI Object Storage API: Use cwobject:* for all CoreWeave-specific storage actions.

Recommendation: Keep S3 and cwobject: actions in separate policy statements. This makes the policy easier to read and understand.

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "action-set-example",
    "statements": [
      {
        "name": "allow-s3-read-actions",
        "effect": "Allow",
        "principals": ["*"],
        "actions": [
          "s3:List*",
          "s3:Get*",
          "s3:Head*"
        ],
        "resources": ["my-bucket", "my-bucket/*"]
      },
      {
        "name": "allow-cwobject-key-management",
        "effect": "Allow",
        "principals": ["coreweave/UserUID"],
        "actions": [
          "cwobject:CreateAccessKey",
          "cwobject:RevokeAccessKeyByAccessKey",
          "cwobject:ListAccessKeyInfo"
        ],
        "resources": ["*"]
      }
    ]
  }
}

Resources

The resources field is required. It defines which resources the policy applies to. Important guidelines for defining resources:

Use short names: Use simple resource names like my-bucket.
- Do not use full ARNs (such as arn:aws:s3:::my-bucket)—they will cause errors.
Specify both bucket and object levels: If a policy affects both bucket-level and object-level operations, list both:
- "my-bucket" for bucket-level actions
- "my-bucket/*" for object-level actions
Use "*" for global operations: Actions like cwobject:* and s3:ListAllMyBuckets are global—they're not tied to a single resource. They require "resources": ["*"] to be allowed.
Special case - s3:PutBucketPolicy: This action is treated as global. To allow it, include "s3:PutBucketPolicy" in the actions and set resources to either "*" or the specific bucket name (e.g., "my-bucket").

Example

{
  "policy": {
    "version": "v1alpha1",
    "name": "resource-scope-examples",
    "statements": [
      {
        "name": "allow-access-to-specific-bucket",
        "effect": "Allow",
        "principals": ["*"],
        "actions": ["s3:GetObject", "s3:PutObject"],
        "resources": [
          "my-specific-bucket",
          "my-specific-bucket/*"
        ]
      },
      {
        "name": "allow-global-s3-and-cwobject-actions",
        "effect": "Allow",
        "principals": ["*"],
        "actions": ["s3:ListAllMyBuckets", "cwobject:ListBucketInfo"],
        "resources": ["*"]
      }
    ]
  }
}

Allowed AI Object Storage API actions

The following AI Object Storage API (cwobject:) actions are allowed in organization access policies:

cwobject:CreateAccessKey
cwobject:CreateAccessKeySAML
cwobject:RevokeAccessKeyByAccessKey
cwobject:RevokeAccessKeysByPrincipal
cwobject:EnsureAccessPolicy
cwobject:DeleteAccessPolicy
cwobject:ListAccessPolicy
cwobject:EnableBucketAuditLogging
cwobject:DisableBucketAuditLogging
cwobject:EnableControlPlaneAuditLogging
cwobject:DisableControlPlaneAuditLogging
cwobject:EnableBucketAuditLoggingDefault
cwobject:DisableBucketAuditLoggingDefault

Please note: cwobject actions must use "*" as the resource value.

These actions are specific to the AI Object Storage API and are used to manage access keys, policies, and audit logging for your organization.

Example use cases

Below are examples organization access policies for various use cases. You can use these examples as templates to create your own organization access policies tailored to your specific needs.

Full control of all resources for admins

This policy contains one statement that grants full S3 API access (s3:*) to all SAML admins for all resources in the organization. The resources field is set to "*" to allow access to all S3 buckets and objects, and the principals field is set to ["role/Admin"] to allow access to all users in the SAML Admin group.

Full control of all buckets for admins

{
  "policy": {
    "version": "v1alpha1",
    "name": "full-s3-api-access",
    "statements": [
      {
        "name": "allow-full-s3-api-access-to-all",
        "effect": "Allow",
        "actions": [
          "s3:*"
        ],
        "resources": ["*"],
        "principals": ["role/Admin"]
      }
    ]
  }
}

Full control of one specific bucket for all users

This policy contains two statements that, when combined, grant access to a specific bucket, "my-specific-bucket".

The first grants access for the creation of access keys and listing of access policies to all users.
The second grants full S3 API access (s3:*) to all users.

The resources field includes both the bucket itself and all objects within that bucket, allowing for both bucket-level operations (like listing the bucket) and object-level operations (like getting or putting objects within that bucket).

Full control of one specific bucket for all users

{
  "policy": {
    "version": "v1alpha1",
    "name": "full-access-my-specific-bucket",
    "statements": [
            {
        "name": "allow-token-creation",
        "effect": "Allow",
        "actions": [
          "cwobject:CreateAccessKey",
          "cwobject:CreateAccessKeySAML",
          "cwobject:ListAccessPolicy"
        ],
        "resources": [
                   "mybucket",
                   "mybucket/*"
               ],
        "principals": ["*"]
      },
      {
        "name": "full-s3-access-for-all-users",
        "effect": "Allow",
        "actions": ["s3:*"],
        "resources": [
          "my-specific-bucket",
          "my-specific-bucket/*"
        ],
        "principals": ["*"]
      }
    ]
  }
}

Full S3 API access to all users

This policy contains one statement that grants full S3 API access (s3:*) to all principals and resources in the organization. The resources field is set to "*" to allow access to all S3 buckets and objects, and the principals field is also set to "*" to allow access to all users.

This is useful when you want to grant full access by default, then restrict specific buckets with bucket access policies.

Full S3 API access to all users

{
  "policy": {
    "version": "v1alpha1",
    "name": "full-s3-api-access",
    "statements": [
      {
        "name": "allow-full-s3-api-access-to-all",
        "effect": "Allow",
        "actions": [
          "s3:*"
        ],
        "resources": ["*"],
        "principals": ["*"]
      }
    ]
  }
}

Full control of all buckets for a specific user

This policy grants full S3 access (s3:*) to a specific Cloud Console user, identified by their UID (coreweave/UserUID).

The UID can be found in the user's settings within the Cloud Console. The resources field uses the wildcard "*" to grant access across all buckets, but it could also be narrowed to a specific bucket using the short-form resource names, as shown in the previous example.

Full control of all buckets for a specific user

{
  "policy": {
    "version": "v1alpha1",
    "name": "s3-full-control-specific-user",
    "statements": [
      {
        "name": "full-s3-access-for-user",
        "effect": "Allow",
        "actions": ["s3:*"],
        "resources": ["*"],
        "principals": ["coreweave/UserUID"]
      }
    ]
  }
}

Read-only access to all buckets

This policy provides read-only access to all S3 buckets for all principals. The actions s3:List*, s3:Get*, and s3:Head* are commonly used to define read-only permissions.

Read-only access to all buckets

{
  "policy": {
    "version": "v1alpha1",
    "name": "s3-read-only-all-buckets",
    "statements": [
      {
        "name": "read-only-access",
        "effect": "Allow",
        "actions": [
          "s3:List*",
          "s3:Get*",
          "s3:Head*"
        ],
        "resources": ["*"],
        "principals": ["*"]
      }
    ]
  }
}

Read-only access to a specific bucket

This policy restricts everyone in the organization to read-only access for "my-specific-bucket". Note the short-form bucket name used in the resources array, which is required in organization access policies.

Two resources are listed:

The bucket itself ("my-specific-bucket")
All objects within that bucket ("my-specific-bucket/*")

This allows for both bucket-level operations (like listing the bucket) and object-level operations (like getting or listing objects within that bucket). The principals field is set to "*" to allow access to all users.

Read-only access to a specific bucket

{
  "policy": {
    "version": "v1alpha1",
    "name": "specific-bucket-access",
    "statements": [
      {
        "name": "read-only-my-specific-bucket",
        "effect": "Allow",
        "actions": [
          "s3:List*",
          "s3:Get*",
          "s3:Head*"
        ],
        "resources": [
          "my-specific-bucket",
          "my-specific-bucket/*"
        ],
        "principals": ["*"]
      }
    ]
  }
}

Allow non-admins limited AI Object Storage API access

This policy contains one statement for AI Object Storage API actions (cwobject:). It grants all non-admins the ability to create access keys and list access policies, but does not grant any other cwobject: access. Remember that cwobject: actions are global and require "resources": ["*"].

Admins (as defined in Cloud Console) already have unrestricted cwobject: access, so this policy effectively limits non-admin users to only these specified actions.

Allow non-admins limited AI Object Storage API access

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

AI Object Storage API and S3 API access for a SAML group

This policy contains two statements that, when combined, grant all S3 API and AI Object Storage API actions to a specific SAML group, role/Admin.

The first statement (cwobject-access-for-saml-group) grants all AI Object Storage API actions (cwobject:*).
The second statement (s3-access-for-saml-group) grants all S3-compatible actions (s3:*).

This grants broad administrative access at the organization level, while controlling membership with your Identity Provider (IdP) group.

AI Object Storage API and S3 API access for a SAML group

{
  "policy": {
    "version": "v1alpha1",
    "name": "full-access-saml-admin-group",
    "statements": [
      {
        "name": "cwobject-access-for-saml-group",
        "effect": "Allow",
        "actions": [
          "cwobject:*"
        ],
        "resources": ["*"],
        "principals": ["role/Admin"]
      },
      {
        "name": "s3-access-for-saml-group",
        "effect": "Allow",
        "actions": [
          "s3:*",
        ],
        "resources": ["*"],
        "principals": ["role/Admin"]
      }
    ]
  }
}

Advanced example

This example policy combines three statements that are similar to the previous examples, but combined into a single policy.

The first statement, s3-access, grants full S3 API access to all principals and buckets.
The second statement, cwobject-access, grants limited AI Object Storage API access to all non-admins.
- Admin users do not need to be listed here, because they have a special internal policy granting unrestricted access.
The third statement, read-only, makes a specific bucket read-only for a specific SAML group.

This is similar to a real-world scenario that allows all users to manage S3 buckets, but restricts AI Object Storage API access to non-admins, while restricting a specific SAML group to read-only access to a specific bucket.

Advanced example

{
  "policy": {
    "version": "v1alpha1",
    "name": "complex-access-policy",
    "statements": [
      {
        "name": "s3-access",
        "effect": "Allow",
        "actions": ["s3:*"],
        "resources": ["*"],
        "principals": ["*"]
      },
      {
        "name": "cwobject-access",
        "effect": "Allow",
        "actions": [
          "cwobject:CreateAccessKey",
          "cwobject:CreateAccessKeySAML",
          "cwobject:ListAccessPolicy",
          "cwobject:ListAccessKeyInfo"
        ],
        "resources": ["*"],
        "principals": ["*"]
      },
      {
        "name": "read-only",
        "effect": "Allow",
        "actions": [
          "s3:List*",
          "s3:Get*",
          "s3:Head*"
        ],
        "resources": [
          "my-specific-bucket",
          "my-specific-bucket/*"
        ],
        "principals": ["role/SAMLGroup"]
      }
    ]
  }
}

How to set an organization access policy​

Key considerations​

Structure of organization access policies​

Version​

Name​

Statements​

Name (within Statement)​

Effect​

Principals​

Actions​

Resources​

Allowed AI Object Storage API actions​

Example use cases​

Full control of all resources for admins​

Full control of one specific bucket for all users​

Full S3 API access to all users​

Full control of all buckets for a specific user​

Read-only access to all buckets​

Read-only access to a specific bucket​

Allow non-admins limited AI Object Storage API access​

AI Object Storage API and S3 API access for a SAML group​

Advanced example​

How to set an organization access policy

Key considerations

Structure of organization access policies

Version

Name

Statements

Name (within Statement)

Effect

Principals

Actions

Resources

Allowed AI Object Storage API actions

Example use cases

Full control of all resources for admins

Full control of one specific bucket for all users

Full S3 API access to all users

Full control of all buckets for a specific user

Read-only access to all buckets

Read-only access to a specific bucket

Allow non-admins limited AI Object Storage API access

AI Object Storage API and S3 API access for a SAML group

Advanced example