Published: 2026-10-30
Summary

A nightly security sweep with headless Claude Code: logs into S3 and Athena, read-only access, and a green/yellow/red Slack report

Chapters / key moments (click to jump — plays here on the page)

One of three security habits the speaker recommends is continuous insight into your logs. His team set up a scheduled, read-only Claude Code job that reads them and reports every morning, and the first week produced three useful lessons.

Source video

"I Gave Claude Code Our Server Logs (Here's What It Caught)" by Craig Hewitt — Watch on YouTube → Hewitt runs a podcasting SaaS on AWS; his stack will differ from yours, and he says the same idea works on Google Cloud or Heroku.

The three habits

Watch your packages, languages, frameworks and platforms for vulnerabilities (the speaker cites a recent PHP vulnerability that took his own site down for an update) with something that alerts you.
Scan the codebase regularly, with a tool such as detail.dev (which he says scans the whole codebase, unlike tools that scan only pull requests) or your own Claude or Codex subscription.
Watch your logs, which is what the rest of the video covers.

The architecture

Sources: Cloudflare (traffic routing), AWS GuardDuty, ClickHouse (listener analytics) and Sentry (error monitoring).
Storage: the AWS-side logs are pushed into an encrypted S3 bucket, and AWS Athena builds queryable databases from the raw data so questions can be asked in SQL.
Analysis: an EC2 instance, managed inside the same AWS environment, runs Claude Code headless. A skill and a script do the work; it can pull from raw logs or the curated log services.
Schedule and output: a timer runs it in the middle of the night, the report goes to Slack every day, reports are archived for 90 days then deleted, and each message is green (all good), yellow (something to look at) or red (drop everything).

Safeguards

Read-only access to the logs everywhere. The instance can search and read but cannot store secrets, encrypt keys or change the analytics infrastructure.
Negative tests were run to confirm it cannot be exploited to write, and they passed.
Everything stays inside the company's AWS environment.

Give the skill a picture of normal

The skill lists the data sources and, most importantly, what to expect: where the team lives and how people log into AWS, where infrastructure staff and developers are and how they log in. A new AWS user from a known place is not an alert. Because of this, the first run flagged real activity: a DevOps partner logging in from an unusual place while travelling, a developer deploying from a different IP address, and the speaker himself logging in as the AWS root user, which it told him not to do.

Three gotchas from the first week

Installed is not switched on. The first morning nothing arrived in Slack. The job had been run by hand but the scheduled job was installed and not enabled. Leave it in automatic mode and check the next day that it ran.
"It ran" is not "it got all the data". The first report said all looked good but admitted it could not verify two major sources (analytics and error reporting), a misconfiguration on his side. Give the job a rule to say plainly when sources were unreachable, and inspect the full report rather than only the Slack summary.
Team behaviour was the first finding. The earliest alerts were about the team's own unusual logins and root-user habit, which they fixed.

Caveats: replicating it

The speaker suggests giving the video to your coding agent and asking it to set up a similar system. This page does not give commands: none were shown, and Anthropic's docs on headless runs and scheduling should be checked before building it. This is also only the logs pillar, not a full security programme.