The 15-Minute Security Audit for Your AI Automation

You just shipped an AI automation. It's extracting data, calling APIs, writing to your database. It's working. Then you remember: is it secure? Here's a 15-minute checklist. Run it now. It catches 90% of the problems that cause breaches or expensive mistakes.

1. API Keys and Secrets (5 minutes)

Check:

• API keys are in AWS Secrets Manager or Parameter Store, NOT in code or config files.
• Lambda has an IAM role that grants access to those secrets, with least privilege.
• Secrets rotate automatically (if the API provider supports it). Set a reminder to rotate manually if they don't.
• No API keys in CloudWatch logs, error messages, or DynamoDB records.

Quick test: Search your codebase for ANTHROPIC_API_KEY= or similar. If it returns results, you have a problem.

Fix: Move to Secrets Manager. Lambda reads it at runtime. Delete the old keys immediately.

2. Least-Privilege IAM (3 minutes)

Check:

• Lambda role has only the permissions it needs. (S3 read on specific bucket, DynamoDB write to specific table, Secrets Manager read to specific secrets.)
• No "Action": "*" or "Resource": "*" in the Lambda role policy.
• If Lambda writes to S3, it can only write to a specific bucket or folder, not your entire account's S3.

Quick test: Open IAM console. Find your Lambda role. Read the attached policy. If you see "*", narrow it down.

Example tight policy:

3. Encryption at Rest and in Transit (2 minutes)

Check:

• S3 bucket has default encryption enabled (KMS or AES-256). One toggle in S3 console.
• DynamoDB table has encryption at rest enabled. One toggle.
• Lambda code doesn't make unencrypted HTTP calls; uses HTTPS only.
• Data in transit between Lambda and database uses VPC endpoints if possible (for DynamoDB).

Quick test: S3 console → bucket properties → encryption. Enabled? DynamoDB console → table settings → encryption. Enabled?

4. Input Sanitization (2 minutes)

Check:

• User input is validated before it's used in SQL queries, API calls, or file operations.
• File uploads are scanned for malicious content (via ClamAV or third-party service).
• Large inputs have size limits. (If someone uploads a 5GB file, does it crash your Lambda?)

5. Dependency Scanning (2 minutes)

Check:

• You know what third-party libraries your Lambda depends on. (Check requirements.txt or pyproject.toml.)
• You use a tool to scan for known vulnerabilities. GitHub does this free with Dependabot. Enable it.
• You're not using ancient versions of libraries with known CVEs.

Quick test: GitHub repo → Settings → Security → Dependabot alerts. Any red flags?

6. Secret Detection in Code (1 minute)

Check:

• You use a tool to scan for accidentally committed secrets. (Git-secrets, Gitleaks, or GitHub's built-in secret scanning.)
• It runs in CI/CD (GitHub Actions) to catch commits before they're pushed.

Quick test: git log | grep "ANTHROPIC_API_KEY". If results, you have a problem.

Fix: Enable GitHub secret scanning (Settings → Security → Secret scanning). It's free.

7. Logging and Monitoring (1 minute)

Check:

• CloudWatch Logs are enabled for your Lambda. Every error is logged.
• You're NOT logging sensitive data (API keys, tokens, customer PII).
• You have a CloudWatch alarm for Lambda errors. Alert your team when failures spike.

Quick test: CloudWatch console → Logs → Lambda function. Do you see logs? Are they readable?

The Template: Copy and Run

Save this to a checklist. Run it every time you deploy a new automation. It takes 15 minutes. It saves you from disasters.

One hour of security work saves months of incident recovery. Run this checklist today. Share it with your team. Make it part of your deployment process.