🪣 Securing Cloud Storage Buckets With AI: Access, Encryption, and Audits

Every cloud-breach headline you’ve read about an exposed storage bucket is the same mistake repeated: someone made a bucket public to unblock a quick task, and it stayed public with real data in it. On GCP the trap has an extra wrinkle — Cloud Storage has two access models layered on top of each other, legacy ACLs and IAM, and a bucket can be locked down in one while wide open in the other. I once audited a bucket whose IAM policy was spotless and whose object ACLs still granted allUsers read from a migration two years prior. Reading that combined state correctly is hard, which is exactly why I use AI to audit it — to decode the effective access while I stay the one who decides what’s allowed.

Kill ACLs first: enforce uniform bucket-level access

The single best thing you can do for GCS security is turn off object ACLs entirely with uniform bucket-level access, so IAM is the only access model and there’s only one place to read. I have AI find every bucket that hasn’t done this yet:

gcloud storage buckets list \
  --format="json(name, uniform_bucket_level_access)" > buckets.json

Prompt: “Here is a list of GCS buckets with their uniform_bucket_level_access status (JSON). List every bucket where it’s disabled — those still use legacy ACLs and have a second, hidden access surface. For each, give me the gcloud storage buckets update command to enable UBLA, and note that enabling it is reversible within 90 days so I can roll back if something breaks.”

gcloud storage buckets update gs://my-bucket --uniform-bucket-level-access

The model flagging that UBLA is reversible for 90 days is the detail that lets me enable it confidently — I know I have an undo window if a legacy ACL-dependent integration breaks. I verify nothing reads via ACLs first; AI helps me check, I make the call.

Audit effective access, including public exposure

The question that actually matters is “who can read this bucket?” — and the answer lives in the IAM policy plus any public access prevention setting. I pull both and let AI render the verdict:

gcloud storage buckets get-iam-policy gs://my-bucket --format=json
gcloud storage buckets describe gs://my-bucket \
  --format="value(public_access_prevention)"

Prompt: “Here is a GCS bucket’s IAM policy (JSON) and its public_access_prevention setting. Tell me plainly: can anyone on the internet read or list this bucket? Look specifically for allUsers and allAuthenticatedDomains/allAuthenticatedUsers members and what roles they hold. Then list every external principal (anything not in my org) with any access. End with a one-word verdict: PUBLIC or PRIVATE.”

The one-word verdict forces an unambiguous answer. allAuthenticatedUsers is the sneaky one — it sounds restrictive but means “anyone with any Google account,” i.e. effectively public. AI calls that out reliably when I name it, and the verdict line is what I act on.

Enforce public access prevention so it can’t happen again

Auditing finds today’s exposure; the prevention setting stops tomorrow’s. I enforce it per-bucket, and org-wide via policy:

gcloud storage buckets update gs://my-bucket --public-access-prevention=enforced

Prompt: “Write the GCP Organization Policy that enforces storage.publicAccessPrevention across the whole org, plus a note on how to grant a documented exception for the one bucket that genuinely must serve public static assets. I want a deny-by-default posture with a deliberate, auditable carve-out.”

The deliberate carve-out matters — there’s usually one legitimately-public bucket (a static site, public downloads), and the right design is org-wide enforcement with a single documented exception, not leaving the whole org open because of one bucket. AI drafts both halves; I approve the exception.

Encryption: customer-managed keys where it counts

GCS encrypts at rest by default, but for sensitive buckets I want customer-managed keys (CMEK) so key access is logged and revocable. I have AI set it up and, more importantly, explain the failure mode:

gcloud storage buckets update gs://sensitive-data \
  --default-encryption-key=projects/my-proj/locations/us/keyRings/gcs-ring/cryptoKeys/gcs-key

Prompt: “I’m enabling CMEK on a GCS bucket. Explain what breaks if the key is disabled or the service account loses access to it, how to grant the GCS service agent the right role on the key, and how to verify objects are actually encrypted with my key and not Google’s default. Give the gcloud commands.”

CMEK’s foot-gun is that losing key access makes the data unreadable — that’s the point, but it means the key-to-service-agent grant has to be right. AI explaining the failure mode up front is what stops me from locking myself out of my own data.

Lifecycle and the bulk audit

Old data is risk and cost. I have AI draft lifecycle rules and then run a full-fleet audit:

Prompt: “Here is gcloud storage buckets list output for my whole project with IAM and UBLA status (JSON). Produce one table: bucket, public yes/no, UBLA on/off, CMEK on/off, versioning on/off. Sort so the riskiest buckets — public or ACL-enabled — are at the top. Flag any bucket with no clear owner label so I can chase ownership.”

That single table is the artifact I take to a security review. It turns a project full of buckets into a ranked risk picture in one pass, surfacing the public, ACL-enabled, unowned buckets first.

Who decides

Securing GCS with AI works because the access model — IAM plus ACLs plus the prevention flag — is structured config that a model reads correctly and renders into a plain verdict far faster than I cross-reference three settings by hand. But the model can’t know which bucket is meant to be public, can’t run the changes, and doesn’t carry the consequences of locking out a key. So the division holds: AI audits, renders verdicts, drafts commands, and explains failure modes; I supply the intent, verify the live state, and own every enablement and exception. A bucket the model calls PRIVATE is still my responsibility to confirm.

The reusable prompts are in my prompts collection, and the GCP with AI series covers the IAM and Org Policy controls that back this up. The next breach headline is a public bucket. Make sure it isn’t yours — and let AI help you read the access model you’d otherwise skim.