Every container with its public access level, in five minutes

What does the container audit check?

Public access level per container, first.

In Azure that setting is per container rather than per blob, so one misconfiguration exposes everything inside it. Then lifecycle policies, or the absence of them, which is where storage cost goes. Then last-modified dates, which show which containers nothing has touched since a project ended.

That is three reads and a table, and the table is the conversation with whoever owns the subscription. Nobody schedules this. It happens after an incident, or after somebody in security asks a question that starts with "just checking". Writing it up as a shared table is ordinary data extraction.

Why is blob deletion the action to switch off?

Because unless soft delete is enabled on the storage account, a deleted blob is gone.

Soft delete is not on by default on older accounts and versioning is a separate setting, so "we can restore it" is a claim worth verifying before you rely on it.

The Available tools list on the Azure Storage entry under `strawberry://settings/integrations` names every tool the connection exposes and marks the read-only ones. Switch delete actions off in the Permissions block. Consequential steps stop at an approval card anyway, and on a permanent delete both stops are worth having.

• Container listing with public access level: the single most valuable read.
• Lifecycle policy presence, which is where storage cost hides.
• Delete actions: permanent without soft delete, so switch them off.
• Verify whether soft delete and versioning are actually enabled before trusting either.

Pick the narrowest credential the tools accept

A SAS token scoped to one container with read and list permissions and a real expiry is far better than an account key, because an account key is the whole storage account forever. Check which the connection requires before you decide how it fits your policy.

Reading a public-access setting is a security question, and the browser half turns it into an action: opening the ticket, naming the owner from the resource tags, checking whether the container is referenced in a repository. That is operations work, and ai for it admins covers the recurring version.

Frequently asked questions