# Weekly Amazon S3 bucket security audit posted to Slack

> Every Monday, check every S3 bucket for public exposure, missing encryption and weak backup settings, then get the risks ranked in Slack.

- Workflow type: agent
- Services: Amazon S3, Slack Bot, Google Sheets
- Categories: Engineering, Operations
- Published: 2026-08-10

## What it does

- Every Monday morning, reviews every bucket in your Amazon S3 account and checks whether it is exposed to the public internet, unencrypted, or missing backup protection.
- Posts one Slack message to your team listing only the buckets that need attention, worst first, with a plain sentence each explaining what is wrong and why it matters.
- Sends an all clear line when every bucket passes, so you always know the check actually ran and did not quietly fail.
- Adds a row each week to a Google Sheet recording the date, how many buckets were checked and how many problems were found, giving you a trend line and a record for compliance reviews.

## What you'll need

- An Amazon Web Services login with permission to view your S3 storage settings
- A Slack workspace and a channel where the weekly report should be posted
- A Google Sheet to hold the audit log, with a tab ready to receive one row per week

## Prompt

Every Monday at 8am, audit the security posture of every bucket in my Amazon S3 account and report the risks to my team in Slack. Use a cron trigger for the schedule.

Start with List Buckets to enumerate every bucket in the account. Then, for each bucket, read Get Public Access Block, Get Bucket Policy Status, Get Bucket Policy, Get Bucket Encryption, Get Bucket Versioning, Get Bucket Logging and Get Bucket Ownership Controls.

Judge each bucket against this safe baseline: public access fully blocked with all four Block Public Access settings enabled, default encryption on, versioning enabled, server access logging on, and a bucket policy containing no statement that grants access to a wildcard principal and no statement that permits plain HTTP instead of requiring secure transport. Object Ownership set to BucketOwnerEnforced is the safe setting, because it disables ACLs as a second route to public access.

Keep this workflow strictly read only. Never call any Put or Delete operation, even when a fix looks obvious. The report recommends and the human decides.

Treat a missing configuration as a finding rather than an error. S3 returns NoSuchBucketPolicy, ServerSideEncryptionConfigurationNotFoundError or NoSuchPublicAccessBlockConfiguration when a setting was simply never configured, which is exactly the risk worth flagging. Catch those specific errors, record them as findings, and carry on to the next check instead of failing the run.

Grade every finding so the report can be ordered worst first. Critical means the bucket is actually reachable by the public, either because the policy status reports it as public or because the policy grants a wildcard principal without a condition that meaningfully restricts it. High means missing default encryption, an incomplete Block Public Access configuration, or a policy that allows plain HTTP. Medium means versioning off, server access logging off, or ACLs still enabled. A bucket's overall severity is that of its worst finding.

List Buckets returns buckets from every region, but the credential carries a single region, so a bucket outside that region returns 301 PermanentRedirect. When that happens, read the correct region from the x-amz-bucket-region response header, which Head Bucket also returns, and retry that bucket against its real region. Never drop a bucket silently. A bucket that still cannot be read after the retry is an unaudited bucket, so report it under a could not check heading rather than counting it as passing.

Post one Slack message using the Slack Bot Send a Message operation, so the report comes from a bot identity rather than from me personally. List only the buckets that fail, ordered worst first, with one plain sentence per bucket saying what is wrong and why it matters, for example that a bucket is readable by anyone on the internet and could leak whatever is stored in it. Write for someone who is not an AWS expert: no operation names and no raw policy JSON. Put any could not check buckets in a short section at the end. If nothing fails, post a single all clear line naming how many buckets were scanned, so the team knows the audit ran.

Then append one row per run to my Google Sheets audit log with Append Values, recording the run date, how many buckets were scanned, how many failed, the count of findings at critical, high and medium, and how many buckets could not be checked. Use USER_ENTERED so the date lands as a real date. Always append and never overwrite earlier rows, so the trend is visible over time and the sheet doubles as evidence for compliance reviews.

## How to customize

- Change the day and time, for example daily during a security push and monthly once things are stable
- Choose which Slack channel gets the report, or send it as a direct message to whoever owns storage
- Adjust the standard buckets are measured against, such as accepting missing version history on temporary scratch buckets
- Exclude buckets that are public on purpose, like one serving a public website, so they stop showing up as problems

## FAQ

### Will this change anything in my AWS account?

No. This workflow only reads settings. It never turns anything on, edits a permission, or deletes anything, even when the fix looks obvious. It tells you what is wrong and leaves the decision with you, which is what makes it safe to run unattended every week.

### Does it cover buckets in more than one region?

Yes. It finds every bucket in the account no matter which region it lives in. If a bucket sits in a different region than your login defaults to, it works out the right region and tries again. Anything it still cannot read is listed separately as could not check, so an unaudited bucket is never quietly counted as safe.

### Do I need to be technical to read the report?

No. Each problem bucket gets one plain sentence saying what is wrong and why it matters, such as a bucket being readable by anyone on the internet. There is no raw configuration or code in the message, so a manager can act on it without asking an engineer to translate.

### What if a bucket was never configured with these settings at all?

That counts as a problem, not an error. A bucket with no encryption rule is an unencrypted bucket, and a bucket with no public access protection is one bad permission away from being exposed. Settings that were simply never set up are exactly the risk worth flagging.

### Does this replace a proper security review?

No, it fills the gap between reviews. Storage settings drift as people create buckets and adjust permissions during the week, so a weekly check catches that drift early instead of letting it sit until the next formal audit.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-amazon-s3-bucket-security-audit-posted-to-slack