The short version. You provide read-only credentials. The engine enumerates identity, storage, network and workload configuration across AWS, Azure, GCP and Kubernetes, compares it against CIS Benchmark expectations, and reports what is exposed. It changes nothing.
What this engine does
Cloud breaches rarely start with a broken cipher. They start with a role that can do more than anyone intended, a bucket that answers to the internet, or a cluster API reachable from outside the VPC. This engine looks for those.
- Identity and access — over-permissive roles and policies, wildcard permissions, unused credentials, privilege escalation paths through role assumption.
- Public exposure — object storage open to the internet, publicly reachable databases and management endpoints.
- Network posture — security-group and firewall rules that permit more than the workload needs.
- Kubernetes — API server exposure, RBAC gaps, privileged workloads and namespace boundaries.
- CIS Benchmark alignment — checks mapped to the published benchmark for the provider, so the result is comparable to what an auditor expects.
What it deliberately does not do
You are handing over credentials to your cloud account. What we do with them is bounded, and the bounds are technical rather than promised:
- Read-only. No resource is created, modified, deleted or restarted. Nothing in your account changes.
- No data access. The engine reports that a bucket is public; it does not read its contents.
- No exploitation of what it finds. A privilege-escalation path is described, not walked.
- No credential retention. Credentials are written to the scan workspace, used, then zeroed and deleted when the run ends. They are never stored in our database.
- No lateral movement. The audit stays inside the account you authorised.
How we prove you are allowed to run it
Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. Cloud accounts cannot be DCV-verified, so this engine runs on your explicit attestation that the account is yours or that you are authorised to assess it — plus the practical proof of holding credentials for it.
Where your data goes, and when it is deleted
Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.
- The report — kept two years, so you can hand it to an auditor next year.
- Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
- The anonymous homepage preview — content erased after 24 hours.
- The authorisation record — kept, because it is the evidence that the scan was permitted.
The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.
How a run actually works
Give the engine the narrowest read-only role your provider supports. It enumerates configuration through the provider APIs, then analyses the result: which identity can reach which resource, which exposure is real rather than theoretical, and which findings the CIS Benchmark treats as a control failure.
Credentials are handled as a special class throughout — never written to the database, never included in logs, and removed from disk in the workspace teardown at the end of the scan.
What you get at the end
A posture report organised by exposure, with the specific resource identifier for each finding, the benchmark control it maps to where one applies, and remediation expressed in your provider's own terms. Suitable for handing to an auditor asking how you assess cloud configuration.
What this engine cannot find
A configuration audit sees configuration. It does not see:
- Application-level vulnerabilities in the workloads running on that infrastructure.
- Anything the read-only role cannot enumerate — deliberately restricted services stay invisible.
- Runtime behaviour: what actually happens when the workload processes a request.
- Data-layer problems inside a storage service, since contents are never read.
- Cross-account trust relationships involving accounts you did not authorise.
We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.
Frequently Asked Questions
Can this change anything in our cloud account?
No. The engine performs read-only enumeration and never creates, modifies, deletes or restarts a resource. Provide a read-only role and the boundary is enforced by your own provider as well.
What happens to the credentials we provide?
They travel on the dispatch channel, are written into the scan workspace, used for enumeration, then zeroed and deleted at teardown. They are never written to our database or logs.
Do you read the contents of our storage buckets?
No. The engine reports that a bucket is publicly reachable; it does not read, list at scale, or download what is in it.
Which providers are covered?
AWS, Azure, GCP and Kubernetes, with checks mapped to the published CIS Benchmark for each where one exists.
Is this a penetration test?
It is a read-only posture audit. Privilege-escalation paths are described rather than walked, which is the appropriate boundary for a production cloud account you rely on.