Auditing Your Cloud and Identity Setup with AI

TL;DR - The previous post used AI to audit your code. But most cloud breaches are not a code bug, they are a misconfiguration: a public bucket, an over-broad role, an admin without phishing-resistant MFA. AI gives you an expert first pass over that surface too, if you run it right:

• Run a deterministic posture scanner for coverage. Prowler, ScoutSuite, or ScubaGear for cloud and identity; Checkov or Trivy for infrastructure-as-code. These are read-only and map to CIS, SOC 2, and the CISA baselines.
• Use AI to triage what the scanner floods you with. Which findings are actually reachable, which touch production and sensitive data, what the fix is. Attack-path context beats raw alert count.
• Guard the credentials. Auditing your cloud means giving something read access to your whole config. Keep it read-only, scope it tight, and feed the model the scanner’s output, not your live cloud keys.

Expert first pass at machine scale. You still sign off on every change.

The breach is usually a setting, not a bug

You can ship perfectly reviewed code and still get breached, because the hole is one level down: in how the cloud is configured. Gartner’s much-cited estimate has been that 99% of cloud security failures through 2026 are the customer’s fault, not the provider’s, and the mechanism is almost always misconfiguration. Even as that specific figure ages, the pattern behind it has not moved: misconfiguration is repeatedly named the number one cause of cloud incidents, an estimated 82% of misconfigurations trace to human error rather than a provider flaw, and organizations running public cloud average dozens of misconfigurations per account. The average misconfiguration breach now runs into the millions.

The canonical example is Capital One in 2019: 106 million records. There was no exotic zero-day. A misconfigured web application firewall allowed a server-side request forgery, that reached the cloud metadata service and lifted the credentials of an over-permissioned IAM role, and that role could list and read 700-plus S3 buckets it never needed. Individually, each setting looked survivable. Chained, they were a catastrophe. That is the nature of posture problems: boring settings that compound.

Code review does not catch any of this. It is a different surface, and it is exactly the kind of large, tedious, context-heavy review that AI is good at making a first pass over.

The three surfaces to audit

Cloud configuration. The classics, and they are still the classics because they still cause breaches: object storage open to the public, a security group with 0.0.0.0/0 on SSH or a database port, storage and volumes without encryption at rest, logging and audit trails switched off so you cannot even tell what happened. Four categories, S3 buckets, security groups, IAM policies, and databases, account for most of what gets exploited.

Identity. The highest-leverage surface, because a weak identity boundary turns a small foothold into a full compromise (ask Capital One). On AWS, the recurring sins are wildcard permissions ("Action": "s3:*" or worse "*": "*"), AdministratorAccess handed out when a handful of actions would do, and iam:PassRole with a wildcard that quietly enables privilege escalation. On Microsoft Entra ID, the equivalents are privileged roles like Global Administrator protected only by basic MFA rather than phishing-resistant methods, weak authenticators (SMS, voice) left enabled, permanent role assignments with no expiry instead of just-in-time activation, and refresh-token lifetimes long enough that a stolen token stays useful for weeks.

Infrastructure-as-code. The best place to catch all of the above, because it is where the misconfiguration is born. An aws_s3_bucket missing block-public-access, a security group with an open ingress rule, an RDS instance without storage_encrypted = true, are all easy to miss in a wall of HCL and trivial to catch before they ever provision. And it is where the fix has the most leverage: one over-broad IAM policy in a shared module propagates the identical flaw to every environment that uses it, so fixing it once in the module fixes it in all of them at once. Fix the running resource and you have patched one place; fix the module and you have patched the pattern.

IaC also has a class of secret leak worth calling out: a credential exported as a stack or module output, or a database password that lands in state in plaintext. Anyone who can read the outputs or the state file reads the secret. The IaC review is the place to catch “why is there an access key in this output,” before it is sitting in a state bucket forever.

AI plus a scanner, not either alone

This is the same lesson as auditing code, applied to config. The deterministic scanner is your coverage; the AI is your judgment.

The coverage layer is a posture scanner that reads your config through the provider APIs and checks it against known-bad patterns and compliance baselines:

• Prowler is the broad open-source choice: hundreds of checks (600-plus on AWS alone) across AWS, Azure, GCP, Kubernetes, Microsoft 365, and IaC, mapped to CIS, PCI-DSS, ISO 27001, SOC 2, HIPAA, and more. It is read-only, so it is low-risk to run against production. ScoutSuite covers similar multi-cloud ground (note it has not been actively updated since 2024, so pair it, do not rely on it alone).
• For Entra ID and Microsoft 365, CISA’s ScubaGear checks your tenant against the government SCuBA baselines and produces a pass/fail/warning report per policy across Entra, Exchange, Defender, SharePoint, and Teams. It is the closest thing to a free, opinionated identity audit.
• For infrastructure-as-code, Checkov (3,000-plus policies across Terraform, CloudFormation, ARM, Kubernetes, Dockerfile) or Trivy (which absorbed the old tfsec checks and also scans images) gate misconfig in CI before it ships.

The judgment layer is where AI earns its place. A posture scanner on a real account returns hundreds of findings, most of them, in the words of every SOC that has drowned in them, technically accurate and operationally useless. A finding only matters when you can answer “is this reachable, and does it touch anything important.” That is context work: a public VM matters far more when it is in production, reachable through a risky identity path, and connected to sensitive data. Feed the scanner’s output to an AI reviewer and ask it to rank by exploitable attack path, dedupe the noise, explain each real risk in plain terms, and draft the fix. That is the difference between a 400-line report nobody reads and the five things to fix this week.

But ranking is not enough, because AI triage has its own failure mode: it produces confident false positives, and ranked noise is still noise. In one audit I ran, roughly a third of the raw findings were false positives. A common shape: the tool flags “S3 bucket not encrypted at rest” or “database storage not encrypted,” both of which have been encrypted by default at the provider for years. The finding is technically emitted, factually wrong, and lands with the same confident tone as a real one. Sorting them more neatly does not make them true. What makes AI triage trustworthy is a refutation pass: run several independent checks that each try to disprove a finding, and keep only the ones that survive a majority vote. Skepticism, not just sorting, is what clears the noise. It is the same adversarial-verification move that separates a useful code review from a plausible-sounding one.

The workflow that holds up

Mirror the code-review loop, pointed at config:

1. Scan. Run Prowler / ScubaGear / Checkov. You get structured, deterministic findings mapped to a framework.
2. Triage with AI, then refute. Feed the findings plus context (which accounts are prod, which data is sensitive) and have the model rank by real attack path, group duplicates, and separate “fix now” from “policy debt.” Then run a refutation pass: independent checks that each try to disprove a finding, keeping only what survives. That pass, not the ranking, is what clears the false positives.
3. Draft the fix. Let it propose the concrete remediation: the tightened IAM policy, the Terraform diff, the conditional-access change. Read it.
4. Verify and apply. A human approves anything that touches identity, network exposure, or production. The model proposes, you decide.
5. Gate IaC in CI. Put Checkov or Trivy in the pipeline so the next misconfiguration is caught in the pull request, not in a breach report.

The gap both scans miss: drift

There is a blind spot neither scan closes on its own. A posture scanner reads your live state. An IaC scanner reads your code. Neither catches the case where the two disagree, where the Terraform declares one thing and the running config has quietly drifted to another, changed by hand in a console during an incident and never reconciled. Drift between declared and actual is its own surface, and it is exactly where nasty surprises hide (a trust policy or a wildcard that exists in production but in no repo). Catch it by diffing what your IaC intends against what the provider actually reports, and treat any gap as a finding in its own right.

Guard the credentials you hand it

This surface has a risk the code audit did not, and it is the one to get right: to audit your cloud, something needs read access to your entire cloud configuration. That is a powerful credential, and the tooling is software with its own attack surface, the same point the code post made about security skills.

• Read-only and scoped, never write, never long-lived. Giving an agent a read-only, tightly scoped role for live recon is not only acceptable, it catches things a static export misses: an access key’s last-used age, a cross-reference against live logs. The rules that never bend are the other three: never write access, never long-lived keys, and never credentials in the prompt.
• Never paste secrets into a prompt. Config exports routinely contain access keys, connection strings, and tokens. Strip them, or you have just leaked them to wherever the prompt goes.
• Trusted tools and skills only, same rule as before. A skill or agent that can read your whole cloud and also process untrusted input and act on it is the makings of a bad day.

Where it still needs you

• Business context. Is that public bucket a leak, or is it your CDN origin serving public assets on purpose? The scanner flags it either way; only you know which. AI can guess, and sometimes guesses wrong.
• Data classification. “This database is exposed” matters enormously or barely at all depending on what is in it. That is your knowledge, not the model’s.
• Runtime versus config. Posture tools see how things are set up, not what is actually happening in the account right now. Config audit is one layer, not the whole program.
• The final apply. Changing an IAM policy or a conditional-access rule can lock out the wrong people or open the wrong door. A human applies it, in a change window, with a rollback.

Used this way, AI is an experienced cloud auditor who reads every line of your config, every account, without getting bored, and hands you a prioritized list instead of a data dump. It is occasionally, confidently wrong, which is why the scanner grounds it and a human signs off.

Summary

Most breaches are a misconfiguration, not a code bug, and the misconfiguration surface, cloud config, identity, and the IaC that provisions both, is precisely the large, tedious, context-heavy review AI is good at accelerating. Run a deterministic posture scanner (Prowler, ScubaGear, Checkov) for coverage, use AI to triage the flood into the few things that are actually reachable and matter, keep the credentials read-only and the secrets out of the prompt, and put a human on every change. It is an expert first pass at machine scale, over the surface where the real breaches happen.

This closes the loop from AI writes your code and auditing that code with AI: first the code, now the cloud it runs in.

---

Want an expert audit of your cloud and identity setup, the AI-accelerated first pass and the human read on what actually matters? That is the core of Security & Compliance. Book a free 30-minute call and we will run it against your environment and go through the findings together.