"Working" and "secure" are two entirely different claims about a system, and the gap between them is where most real-world incidents live — not in some novel zero-day, but in the mundane stuff: a security group rule that still says "allow from anywhere," a storage account with public access quietly left on, a database that's technically reachable from the internet because nobody explicitly told it not to be. None of these mistakes break your application. That's exactly what makes them dangerous — they're invisible until someone goes looking.

So I went looking. Here's what I built, what I found, and why I think the way I found it matters more than the finding itself.

The Setup: Four Checks, One Script, No Guessing

The goal was narrow and deliberate: a Bash script that audits an Azure environment for four specific, well-understood misconfiguration classes.

• Network Security Group rules that allow unrestricted inbound SSH or RDP — the digital equivalent of leaving your front door key under a mat that's visible from the street.

• Storage Account public blob access — can an anonymous, unauthenticated request read data out of your storage?

• Managed disk encryption-at-rest — if someone got physical or backend access to the underlying storage medium, is the data on it protected?

• Azure Database for MySQL public network access — can your database be reached from outside your private network at all?

Each check follows the same shape: call a read-only Azure CLI command, parse the JSON response with jq, and classify the result as PASS, WARN, or FAIL. No creativity, no interpretation — just a deterministic yes/no/unknown against a known-risky pattern. The script uses an array of function names so adding a fifth check later is a two-line change, not a rewrite. It exits with distinct codes — 0 for healthy, 1 for warnings, 2 for failures — so anything downstream, whether that's a human or an AI agent, can react proportionally without re-parsing a wall of text.

That last part matters more than it sounds. A script that just prints "something's wrong" is a script you have to read carefully every single time. A script that hands you a structured status is a script you can build automation on top of — which is exactly what came next.

Handing the Evidence to Claude Code — Without Handing Over the Keys

Here's where it gets interesting, and where I think a lot of "AI + infrastructure" conversations go wrong.

The obvious move is to let an AI agent run commands against your cloud environment and fix whatever it finds. The obvious move is also a bad idea. An agent that can both diagnose and treat a production environment is an agent one confident misunderstanding away from an outage , or worse, a security incident it caused while trying to prevent one.

So I built the opposite: a Claude Code Skill, invoked with /azure-audit, that is structurally incapable of touching my infrastructure. Not "instructed not to" — incapable. The Skill's permission set is Bash, Read, Grep. There is no Write in that list. It can run the audit script, read the resulting report, and grep through evidence. It cannot create a file, cannot edit a file, and by extension cannot silently rewrite the audit script or plant a remediation command somewhere I'd never notice.

On top of that, a project-level CLAUDE.md file spells out the rules in plain language: never create, modify, resize, start, stop, deallocate, or delete a resource; never run az group delete, az vm delete, or az resource delete; never execute a remediation command; and — the rule I think matters most — do not claim a finding unless the report contains supporting evidence.

That last rule is a quiet but important piece of engineering discipline. It's easy for an AI system to sound confident about a problem it's only inferred. Forcing every claim to trace back to an actual line in a Bash-generated report means the AI's analysis is grounded in something falsifiable, not vibes.

When I ran the audit, Claude Code did exactly what the Skill defines: it ran the script, read the report, and for every WARN or FAIL, it explained the finding in plain language, described the real-world security or operational impact, proposed one exact Azure CLI command to fix it, and gave me a verification command to confirm the fix later. Then it stopped. It didn't run the fix command. It asked me to.

This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — led by Pravin Mishra. My graded progress is public: Ginny Ibe — DMI Cohort 3. Start your DevOps journey: https://dmi.pravinmishra.com/?

This week, during Week 4 of my DevOps Micro-Internship, I learned that effective code reviews don't always start with a Pull Request. Sometimes the best review happens before the code ever leaves your laptop.

Creating a Problem on Purpose

To understand how developers prevent mistakes, I intentionally wrote a small script containing two common problems: a hardcoded AWS-style access key, and a leftover debug statement. Neither belonged in production code.

The goal wasn't to write perfect code. The goal was to build a safety system that could catch mistakes before another developer — or a production environment — ever saw them. That's the mindset behind DevSecOps: security should be built into the workflow, not added after something goes wrong.

Building My First Line of Defense With Git Hooks

The first safeguard I built was a Git pre-commit hook — a script that runs automatically before Git creates a commit. Think of it as a security checkpoint at the entrance of your repository. Before letting anything through, my hook scanned staged files for AWS-style access keys, private key signatures, and oversized files.

bash

# .git/hooks/pre-commit (excerpt)
#!/bin/bash

if git diff --cached | grep -E "AKIA[0-9A-Z]{16}"; then
  echo "❌ Commit blocked: AWS access key detected in staged changes."
  exit 1
fi

if git diff --cached | grep -E "BEGIN (RSA|EC|OPENSSH) PRIVATE KEY"; then
  echo "❌ Commit blocked: private key detected in staged changes."
  exit 1
fi

When I tried to commit my script, Git blocked the operation:

bash

$ git commit -m "add config script"
❌ Commit blocked: AWS access key detected in staged changes.

The commit never happened. The vulnerable code never entered repository history. That moment changed how I viewed automation — security isn't only about finding problems, it's about preventing them from becoming problems in the first place.

Adding AI as a Second Layer of Review

The Git hook was excellent at detecting known patterns — it could recognize "this looks like an AWS key." What it couldn't do was understand why something was a risk, like a debug statement that leaks information without matching any obvious pattern.

That's where AI-assisted review became useful. I built a Claude Code /pr-ready skill that analyzed my staged changes and generated a Pull Request readiness review — explaining why the debug statement was risky, why sample credentials could still trip security scanners downstream, and where the PR description needed more context:

$ /pr-ready

⚠️ Debug statement found in src/config.py:14
   → Exposes internal config values in logs. Remove before merging.

⚠️ Sample credential pattern detected in src/config.py:22
   → Even placeholder keys can trigger downstream secret scanners.
   → Recommend replacing with an obviously fake value (e.g. "REDACTED").

ℹ️ PR description is missing a "Testing" section.

Automation detects patterns. AI explains context. That's the real difference between the two layers.

Two Tools, Two Different Jobs

This assignment showed me that Git hooks and AI reviewers aren't competitors — they solve different problems.

Together, they create layered protection: one stops the obvious mistakes instantly, the other catches the subtler ones and explains why they matter.

Why Humans Still Matter

The biggest lesson wasn't about Git, and it wasn't about AI. It was about responsibility.

AI can help write code, review changes, and generate Pull Request summaries. But it shouldn't automatically commit code, push changes, merge Pull Requests, or modify repository history. Those decisions require human judgment — the developer remains responsible for understanding what actually enters the system.

Final Reflection

Before this assignment, I viewed Git mainly as a place to store and manage code. Now I see it differently: Git can be an intelligent checkpoint in the development lifecycle. A pre-commit hook protects the repository. AI provides additional insight. The developer provides judgment.

That combination creates a safer engineering workflow — not by removing humans from the process, but by giving developers better tools to make better decisions. The best security improvement is often the one that stops a mistake before anyone has to fix it.

This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — led by Pravin Mishra. My graded progress is public: Ginny Ibe — DMI Cohort 3. Start your DevOps journey: https://dmi.pravinmishra.com/?