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.Documentation Index
Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
Use this file to discover all available pages before exploring further.
Prerequisites
You must have theObject Storage Admin IAM role (assigned through CoreWeave IAM Access Policies), or equivalent permissions to create and manage organization access policies:
cwobject:EnsureAccessPolicyto create or edit an organization access policy.cwobject:ListAccessPolicyto view existing organization access policies.cwobject:DeleteAccessPolicyto delete an organization access policy.
Object Storage Admin IAM role assigned to them, so they can create and manage organization access policies, as well as grant the same permissions to other users and groups (through either IAM Access Policies or AI Object Storage organization access policies).
How to set an organization access policy
You can set an organization access policy using the Cloud Console, the AI Object Storage API, or the CoreWeave Terraform provider.- Cloud Console
- AI Object Storage API
- Terraform
To create an organization access policy in the Cloud Console:
Edit returns you to the policy editor.Delete requires confirmation:
- Navigate to the Organization Access Policies page.
- Click the Create Policy button at the top right corner of the page.
- In the Create Policy page, enter the Policy Name.
- Within the policy, add one or more statements. In the Statement section, enter a descriptive Name for the statement. For example, “grant-read-access-to-test-bucket”.
- For Access, select either Allow access or Deny access.
-
For Principals, enter one or more principals to which the statement applies. The search field shows available principals (users and groups) in your organization. Select the principals you want to add, or enter
*to allow access to all principals: After selecting the principals, they will appear in the Principals section:

-
For Actions, enter one or more actions to which the statement applies. The search field shows you available actions. Select the actions you want to add, or enter
*to allow access to all actions. This example grants read access by allowing the actionss3:GetObjectands3:ListBucket: After selecting the actions, they will appear in the Actions section:

-
For Resources, enter one or more resources to which the statement applies. The search field shows you available resources. Select the resources you want to add, or enter
*to allow access to all resources. This example scopes the policy statement to the buckettest-bucketand all objects within it: After selecting the resources, they will appear in the Resources section:

- Add another statement by clicking Add Statement, or click Submit to create the policy.
- Use the Search function to find policies by name.
- To view an existing policy, click the policy name.
- To edit or delete a policy, click the More icon to the right of the policy, then select Edit or Delete.


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:
| Field | Description |
|---|---|
| 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
Theversion 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.
Replace [BUCKET-NAME] in the policy with the name of the bucket you want to grant access to.
Example policy
Name
At the top level, within thepolicy object, name is required. It provides a human-readable identifier for the overall organization access policy.
Statements
Thestatements 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.
Replace [USER-UID] in the policy with the UID of the user you want to grant access to.
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.
Effect
TheEffect 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.
Replace [USER-UID] in the policy with the UID of the user you want to deny access to.
Principals
Theprincipals 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 withcoreweave/. 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. TheGroupNamemust match thePrincipalNameattribute in the SAML assertion. - OIDC Users: When using OIDC with an Identity Provider (IdP), reference users using the format
role/[JWT-ISSUER-URL]:[JWT-SUBJECT-USER-ID]where[JWT-ISSUER-URL]is the issuer of the JWT token and[JWT-SUBJECT-USER-ID]is the subject of the JWT token.
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).
Actions
Theactions 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.
cwobject: actions in separate policy statements. This makes the policy easier to read and understand.
Resources
Theresources 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). Full ARNs cause errors.
- Do not use full ARNs (such as
- 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 likecwobject:*ands3:ListAllMyBucketsare global and 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 theactionsand setresourcesto either"*"or the specific bucket name (e.g.,"my-bucket").
Allowed AI Object Storage API actions
The following AI Object Storage API (cwobject:) actions are allowed in organization access policies:
cwobject:CreateAccessKeycwobject:CreateAccessKeySAMLcwobject:ListAccessKeyInfocwobject:GetAccessKeyInfocwobject:UpdateAccessKeyStatuscwobject:RevokeAccessKeyByAccessKeycwobject:RevokeAccessKeysByPrincipalcwobject:EnsureAccessPolicycwobject:ListAccessPolicycwobject:DeleteAccessPolicycwobject:ListBucketInfocwobject:GetBucketInfocwobject:EnableBucketAuditLoggingcwobject:DisableBucketAuditLoggingcwobject:EnableBucketAuditLoggingDefaultcwobject:DisableBucketAuditLoggingDefaultcwobject:EnableControlPlaneAuditLoggingcwobject:DisableControlPlaneAuditLogging
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.