Public access prevention is a Cloud Storage setting that stops anyone from making a bucket's data public through IAM or ACLs. Turn it on per bucket as enforced, or inherit it from the storage.publicAccessPrevention organization policy, and requests that rely on allUsers or allAuthenticatedUsers will fail.
What it blocks
Google describes public access prevention as protection against accidental exposure. When it applies, no one can make data in the bucket public through IAM policies or ACLs. Requests that depend on the allUsers or allAuthenticatedUsers principals are rejected.
Existing public grants are not deleted. They stay in place but are overridden while prevention is active. That means turning it off again would bring them back, so clean up grants you no longer want.
Signed URLs are not affected, and neither are private buckets served through a load balancer or Cloud CDN, according to Google.
Enforced and inherited
A bucket's setting is one of two values.
- Enforced. Prevention applies to that bucket directly.
- Inherited. The bucket follows the organization policy constraint storage.publicAccessPrevention. Google checks the bucket's project first, then its folder, then the organization. If none of them sets the constraint, prevention does not apply.
Inherited is the better default for a company, since one policy at the organization level covers new buckets without anyone remembering a flag. Enforced is useful for a bucket you want protected no matter what an organization policy says.
Projects that are not attached to an organization cannot use organization policies. For those, use the bucket-level setting.
How this relates to uniform bucket-level access
They solve different problems. Google's page says only that with uniform bucket-level access enabled, ACLs cannot be used to control access to individual objects, so you can skip checking object ACLs when hunting for public exposure. Uniform access simplifies where permissions live. Public access prevention is the control that says nothing here may be public, whichever route is used. You can use both.
A rollout plan
- Inventory which buckets are intentionally public, such as a static asset bucket.
- Move intentional public content to its own project or folder.
- Set the organization policy at the organization root, and give the public-content folder an exception.
- Enforce prevention directly on your most sensitive buckets.
- Re-check access in your audit logs after the change, in case an integration relied on public access.
Common mistakes
Assuming prevention deletes the exposure. It overrides public grants, so the data is hidden from anonymous callers, but the grants are still on record. A later change to the setting, or a bucket moved to a project without the policy, could bring them back.
Setting it only on new buckets. Existing buckets keep their own setting. If they are on inherited, they follow the organization policy. If you set the policy late, check that old buckets are not left on a state that exempts them.
Forgetting projects outside the organization. Organization policies cannot apply to projects that are not attached to an organization, so those need the bucket-level setting on every bucket.
Breaking a public website without warning. A bucket that serves public files will stop doing so once prevention applies. Tell the owner and move the content first, or give that folder or project an explicit exception.
Quick check
Does it break signed URLs?
No. Google states signed URLs keep working. Only grants to allUsers or allAuthenticatedUsers are blocked.
Does turning it on remove public grants?
No. The grants remain but are overridden. Remove them yourself so they do not return if the setting is later turned off.
Sources
Last reviewed: 19 October 2026.
