Use `cbx audit aws`
Audit a live AWS account from your terminal: discover resources via the AWS SDK, ground findings in CloudBooster's curated rules with a local LLM CLI, and get a cited report.
Use cbx audit aws
cbx audit aws reads a live AWS account directly via the AWS SDK, grounds what it discovers in CloudBooster's curated AWS knowledge and rule pack, runs a local LLM CLI to produce cited findings, and writes a markdown report alongside terminal output. It's the live-account audit surface of the CLI.
It's designed for single-account, ad-hoc audits from a developer's laptop. Multi-account, continuous, or org-wide scanning is the hosted product's job — see Connect an AWS account.
Grounding is always on
cbx audit aws always grounds its findings in CloudBooster's curated knowledge. It fetches AWS knowledge and a curated rule pack from api.cloudbooster.io/v1/knowledge/aws/*, inlines them into the prompt alongside discovered resources, and runs a local LLM CLI (claude -p by default, or codex exec) with no MCP to cite them. That grounding is the value of the command, not an option — so the command does reach the CloudBooster knowledge API and requires the LLM CLI on your PATH.
Before you begin
cbx-cliv1 or later installed — see the install guide.- A CloudBooster account (
cbx login) — the audit fetches curated knowledge and the rule pack from the CloudBooster API. - A local LLM CLI on your
PATH—claude(Claude Code) by default, orcodex. The CLI owns its own auth. - An AWS profile in
~/.aws/credentials(orAWS_PROFILEset, or--credentials-file <path>pointing at a credentials file). - IAM permissions for the actions listed under Minimum IAM policy below.
Step 1 — Pick the profile
cbx audit aws resolves the profile with this precedence (highest wins):
--credentials-file <path>— explicit credentials file (overrides everything else).- Positional
[profile]argument —cbx audit aws prod. AWS_PROFILEenvironment variable.- The
defaultprofile.
Step 2 — Pick the region(s)
The --region flag is repeatable.
| You want… | Pass |
|---|---|
| The profile's configured region (default) | nothing |
| One region | --region us-east-1 |
| Multiple regions | --region us-east-1 --region eu-west-1 |
| Every enabled region in the account | --region all |
If the profile has no configured region and you're on an interactive terminal, you'll be prompted to pick. In non-interactive mode (--json/-o json, --quiet, or no TTY) you must pass --region explicitly — the command errors otherwise so a CI run can't silently scan the wrong place.
Global resources are discovered once
IAM, CloudFront, and Route53 are global. They're discovered once regardless of how many regions you pass and deduped by ARN.
Step 3 — Run the audit
Before any AWS call, a pre-discovery LLM preflight probes the chosen executor with a one-shot prompt. If the executor isn't on your PATH or isn't authenticated, the run aborts with E_LLM_PREFLIGHT before touching AWS.
Output goes in three places:
| Where | What |
|---|---|
| stderr | Preflight header (account ID, identity, regions, resource count, CloudTrail note), component summary, warning counts. |
| stdout | Plain-text findings list — pipe-safe. With --json, an envelope with findings, components, identity, and any permission errors. |
| Working directory | A markdown report (audit-report-*.md) with per-component sections and account-wide findings. |
A typical header looks like:
The CloudTrail line is intentional — security-conscious teams ask about read-event volume before letting tools loose on a production account. For a small account expect ~50–200 events per run.
Minimum IAM policy
The CLI ships a curated least-privilege policy at docs/cbx-audit-aws-iam.json in the cbx-cli repository. The high-level groupings are:
| Group | Actions | Why |
|---|---|---|
| Preflight | sts:GetCallerIdentity, ec2:DescribeRegions | Confirms credentials and resolves the region list. |
| Discovery | cloudformation:ListResources, cloudformation:GetResource | CloudControl API — primary discovery path. |
| Per-service describers | s3:Get*, iam:GetRole, iam:ListAttachedRolePolicies, ec2:Describe*, rds:Describe*, lambda:Get* / List*, elasticloadbalancing:Describe*, cloudfront:List*, route53:List*, dynamodb:Describe*, sqs:Get*, cloudwatch:Describe*, logs:Describe*, kms:Describe*, etc. | Fill in fields CloudControl doesn't return (encryption state, public-access block, last-used dates, etc.). |
The AWS-managed AWSReadOnlyAccess policy is a strict superset and is fine to use if you don't need least privilege.
AWS API calls are free
Every AWS API call cbx audit aws makes — Describe*, List*, Get* — is free. There's no per-call AWS charge to surface, so the report doesn't carry an AWS-cost line. The LLM analysis step does have a cost — see Choosing the executor below.
Choosing the executor
cbx audit aws always grounds its findings by running a local LLM CLI over discovered resources plus CloudBooster's curated knowledge. Pick which CLI drives it with --llm-executor:
| Executor | CLI invoked | Notes |
|---|---|---|
claude-code (default) | claude -p | Default. --llm-max-cost <usd> caps spend; on exceeding it a warning finding is emitted rather than aborting. |
codex | codex exec | Reports no cost, so --llm-max-cost is a no-op for codex. |
The default follows cbx llm default when that names one of these executors; otherwise it's claude-code. So either pass the flag or set a default once:
The chosen CLI (claude or codex) must be on your PATH and is responsible for its own authentication. Pin the model it uses with --llm-model:
The rule pack
The grounding rules come from a curated rule pack distributed over the CloudBooster API (/v1/knowledge/aws/rulepack) and cached locally at ~/.cache/cbx/rulepack/.
| You want… | Do this |
|---|---|
| Pin a specific rule-pack version | --rulepack-version <ver> (or env CBX_RULEPACK_VERSION) |
| Use a local rule-pack file instead of fetching | env CBX_AUDIT_RULES_FILE=<path> |
What if?
"region is required: pass --region"
You ran in a non-interactive context (-o json, --quiet, or a non-TTY shell) without --region, and the profile has no configured region. Pass --region <name> (repeatable, or all) explicitly. The interactive picker is suppressed in machine-readable / scripted contexts on purpose — CI shouldn't be guessing where to scan.
Run aborts with E_LLM_PREFLIGHT
The pre-discovery preflight couldn't drive the chosen LLM CLI. Confirm the executor is installed and on your PATH and that it's authenticated:
This runs before any AWS call, so nothing in your account was touched.
AccessDenied cascade
If discovery surfaces a flood of AccessDenied warnings (visible in the stderr header), re-run with --diagnose:
You get a per-call breakdown:
Attach the patch (or extend an existing inline policy) and re-run.
Throttling
AWS APIs throttle hard. The SDK's adaptive retry handles most cases, but on very large accounts you may want to lower concurrency:
The default is 4 concurrent calls per service.
A resource type isn't in the report
CloudControl covers ~700 of AWS's ~1,400 resource types. Anything outside the CloudFormation registry (some IAM Identity Center, some Bedrock, some IoT) is silently invisible — file a feature request if you hit a gap that matters.
Other useful flags
| Flag | What it does |
|---|---|
--dry-run | Run discovery and the LLM preflight, but skip the analysis pass. Good for checking IAM coverage and connectivity without spending on the LLM. |
--no-tui | Disable the interactive TUI (implied in non-TTY / scripted contexts). |
--strict | Treat warnings as failures so they affect the exit code. |
--diagnose | Emit a per-call breakdown of discovery permission errors (see the AccessDenied callout above). |
Where else can I audit?
| Surface | What it sees | When to use |
|---|---|---|
cbx audit aws (CLI) | Live state of an AWS account | "What's actually running right now?" |
pkg/audit (Go library) | Terraform/Pulumi state or IaC source, via downstream tools that embed cbx-cli | Not a CLI command — see Use cbx audit. |
| Import existing infrastructure (hosted) | Uploaded Terraform/Pulumi state, in the portal | Connect an AWS account. |
| Hosted product | Continuous, multi-account, org-wide | Platform / security teams. |
Next steps
- Connect an AWS account for continuous, multi-account scanning in the hosted product.
- Run
cbx auditin GitHub Actions. - Use
cbx audit— how the CLI surface relates to the library state-file path. cbx auditfailures — troubleshooting common errors.