Settings, not shells
Most of the cloud incidents that land in a report start as a setting: a guest who can invite guests, a pipeline that can push to production from a forked pull request, a tenant that still allows legacy auth. You do not need an exploit chain to know those are wrong. You need someone who has seen them used.
A configuration review is that pass. We read the tenant, the pipeline, and the identity provider. We do not attack them. The output is a prioritized list of what to change, with enough context that an engineer can change it without a second workshop.
What we review
Microsoft 365 and Entra ID. Conditional access, legacy authentication, consent, guest access, privileged roles, and the mailbox and SharePoint settings that turn one compromised user into a much larger problem.
CI/CD. GitHub Actions, GitLab CI, Azure DevOps, and similar systems — secrets in logs, overly trusted workflows, deploy keys, and the path from a pull request to production.
Cloud tenants and IaC. The control-plane settings that a cloud penetration test would later try to use, plus the Terraform, Bicep, or equivalent that keeps recreating them.
Identity elsewhere. Okta, Kubernetes RBAC, and other control planes when they sit on the same path. We do not invent a review for a platform we cannot read well; we scope to what you run.
What this is not
It is not vulnerability scanning. Scanners check software versions. This checks whether the system was stood up in a way an attacker would like.
It is not a penetration test. If you need proof of impact against AWS, Azure, or GCP, that is the cloud engagement. If you need someone to try to get in, say so — we will tell you which test that actually is.
What you receive
A ranked list of configuration issues, each with the control to change, why it matters in your setup, and what “fixed” looks like. No exploit payloads, no theatre. The point is that someone can start closing items the same day.