Infra Audit5 min readUpdated November 4, 2026

Give the Auditor a Read-Only Identity, Never Your Admin

If the auditor cannot write, it cannot break. Here is the exact policy shape, what the audit can see with it, and what stays out of reach.

Create a dedicated IAM user with a policy of list, get and describe actions across the services in scope. The full audit runs on it. Secrets are never printed; findings reference shapes, not values.

One policy, all Allow, actions limited to list, get, describe and their service-specific equivalents, resources *. The wildcard on resources is acceptable because the actions themselves cannot mutate anything. Explicitly omitted: get-secret-value, get-parameter with decryption, anything starting with Put, Create, Delete, Modify, Update. The result: the auditor can map the whole account and change nothing.

See How We Work

In This Guide

The policy shape

One policy, all Allow, actions limited to list, get, describe and their service-specific equivalents, resources *. The wildcard on resources is acceptable because the actions themselves cannot mutate anything. Explicitly omitted: get-secret-value, get-parameter with decryption, anything starting with Put, Create, Delete, Modify, Update. The result: the auditor can map the whole account and change nothing.
One policy, all Allow, actions limited to list, get, describe and their service-specific equivalents, resources *. The wildcard on resources is acceptable because the actions themselves cannot mutate anything. Explicitly omitted: get-secret-value, get-parameter with decryption, anything starting with Put, Create, Delete, Modify, Update. The result: the auditor can map the whole account and change nothing.

What the audit does with it

The full check set runs: exposure, IAM, detection, expiry. On our canary account, a PowerUser-scoped identity ran the complete audit with zero write operations, detected 9 out of 9 planted misconfigurations, and the report contained no secret values.
The full check set runs: exposure, IAM, detection, expiry. On our canary account, a PowerUser-scoped identity ran the complete audit with zero write operations, detected 9 out of 9 planted misconfigurations, and the report contained no secret values. The identity's own permissions were themselves audited as a finding, which is the standard the skill holds itself to.

The offboarding

One key deletion ends the access. That is the whole point of a dedicated identity: the audit relationship has a clean end, no shared admin password to rotate, no wondering which systems used it. The audit skill's own recommendation: treat auditor keys like every other key, 90-day rotation included.
One key deletion ends the access. That is the whole point of a dedicated identity: the audit relationship has a clean end, no shared admin password to rotate, no wondering which systems used it. The audit skill's own recommendation: treat auditor keys like every other key, 90-day rotation included.

Get the skill

The checks in this guide come from the roqy audit skill, open source at https://github.com/roncoo-2/roqy-audit. It runs read-only against your own account, produces findings with verdicts (confirmed, needs_validation, rejected), and was validated on a live canary AWS account where 9 planted misconfigurations were detected 9 out of 9 times.
The checks in this guide come from the roqy audit skill, open source at https://github.com/roncoo-2/roqy-audit. It runs read-only against your own account, produces findings with verdicts (confirmed, needs_validation, rejected), and was validated on a live canary AWS account where 9 planted misconfigurations were detected 9 out of 9 times. The full canary report is in the repository under docs/runs. Copy the skill into any coding agent, point it at your stack, and get the same report for your account.

4 Tips to Get Started

1

One identity per auditor, named for the purpose. Offboarding is then one key deletion.

2

Deny by omission: grant only list, get, describe. No Put*, no Delete*, no Create*.

3

Set a key rotation reminder: auditor keys follow the same 90-day rule as every other key.

4

The audit report must never contain secret values. Shapes and prefixes only.

Ready to Stop Worrying About Infra?

Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.

Related Guides

Is My S3 Bucket Public? How to Check in One Command

One command tells you if your S3 bucket is public, and one curl proves it. The policy check shows intent, the anonymous request shows reality.

The Most Common AWS Misconfiguration (It Is One Line of Config)

Public buckets and Principal * policies cause most disclosed AWS incidents. Each is one line of config with account-wide blast radius. Here is the pattern.

Terraform State File Leak: Every Secret in Plaintext

terraform.tfstate stores database passwords, IAM keys and TLS private keys in plaintext. sensitive=true hides nothing. Here is how leaks happen and the check.

Docker Socket Mounted in a Container: Root on the Host, No Exploit Needed

A container with /var/run/docker.sock mounted controls the host daemon and can mount your entire filesystem. No kernel exploit required. Here is the mechanism and the check.

R

Ron Cohen — DevOps engineer & founder, roqy.io

Content reviewed by the roqy.io team. Our guides are based on publicly available data.

Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.

Frequently Asked Questions

How do I give an auditor read-only AWS access?

Create a dedicated IAM user, attach a policy granting only list, get and describe actions on the services in scope, and hand over its access key. The full audit runs on that identity: every command is read-only, nothing can be changed or restarted, and offboarding is deleting one key.

What can a read-only audit see?

Everything configuration: bucket policies, security groups, IAM users and keys, trust policies, snapshots, CloudTrail and GuardDuty state, runtime and certificate dates. It cannot see secret values inside Secrets Manager or SSM Parameter Store with a read-only policy scoped to metadata, and it never needs to: findings reference shapes, not values.

Is read-only really safe?

Yes, with one caveat: some read actions return sensitive data, like get-secret-value. The audit policy omits those specific actions. The skill's hard safety rules also cap network probes at single status-code requests, and the client can veto any probe.

Get the DevOps Ecosystem Behind You

One accountable engineer. Full platform behind him. Month-to-month, no lock-in.

See How It Works