- Home
- Clouds
Clouds
Every estate you run, held to one standard.
Your teams run workloads across AWS, Google Cloud, Azure, Kubernetes clusters and GPU capacity. ACSE reads the configuration of each one, read-only, and puts every misconfiguration into the same queue, the same frameworks and the same evidence chain.
One queue across clouds
A public bucket on AWS and an open firewall rule on Google Cloud land side by side, ranked the same way and fixed through the same review.
Access you can explain
Every connection is read-only and keyless, created by your own administrators from a setup ACSE generates. There is nothing to rotate and nothing that can write.
Frameworks that span estates
The same framework controls map to checks on each cloud, so you see PCI DSS or NIST 800-53 across the whole estate, not one account at a time.
Where ACSE works
Pick the estate you care about first
Each cloud has its own provider pack: the checks, the read-only permissions they need and the fixes for common findings. The model above them is shared.
AWS
74 checks across storage, identity, network, compute, logging and encryption, with risk paths from the internet to your data.
Explore02Google Cloud
21 checks across Compute Engine, IAM, Cloud Storage and VPC networks, connected through workload identity federation.
Explore03Azure
13 checks across storage accounts, network security groups, virtual machines, Entra ID and role assignments.
Explore04Kubernetes
Workload security settings checked in your clusters and fixed in your manifests, Helm values or Kustomize overlays.
Explore05AI infrastructure
The configuration around GPU clusters, model storage, training data and the identities that reach them.
ExploreSelf-service connection
Connected by your own admins
A Tenant Admin picks a cloud and a scope in Setup. ACSE generates the setup for your cloud, already bound to your own ACSE runtime, and your administrators run it with their own credentials.
You paste back the non-secret outputs, such as a role ARN or a client id, and test the connection. ACSE reports connected, or exactly what is missing.
- Read-only roles built from each pack’s published permission list
- No access keys, service-account keys or client secrets
- Every connection change recorded on your evidence chain
- Choose the cloud and the scopeIn Setup › Connect cloud, a Tenant Admin picks the provider and what to cover. ACSE lists every permission it will need and who in your team can grant them, before anything is created.
- Run the generated setup in your cloudACSE generates a read-only setup bound to your tenant’s own runtime identity. Your team reviews and runs it. ACSE never runs it for you and never sees a key.
- Test the connection and confirm with MFATest connection checks every permission and reports exactly what is missing. The Tenant Admin confirms with MFA, and the connection settings are recorded on your evidence chain.
Scope
One account, or every account in an AWS Organization or organizational unit.
What the setup creates
- A read-only role, ACSEReadOnlyScanner, in each account in scope
- A trust policy that lets only your own ACSE runtime assume it
- A permissions boundary, so the role can never gain write access
Read-only by design. ACSE delivers fixes as pull requests to your code, so the connection never needs write access to your cloud.
Scope
One project, or every active project in a Google Cloud organization.
What the setup creates
- A workload identity pool and provider that trust your ACSE runtime
- A service account with read-only roles, which only that pool may impersonate
- No service-account keys, ever
Read-only by design. ACSE delivers fixes as pull requests to your code, so the connection never needs write access to your cloud.
Scope
One subscription, or a whole tenant.
What the setup creates
- An app registration with a federated credential for your ACSE runtime
- A custom role with exactly the read actions ACSE needs, at the scope you chose
- No client secrets or certificates
Read-only by design. ACSE delivers fixes as pull requests to your code, so the connection never needs write access to your cloud.
One model
Three clouds, one way of judging them
ACSE normalizes each cloud’s resources into the same shapes before any check runs, so the rest of the product does not fork by provider.
- ReadThe runtime in your environment reads configuration through each cloud’s own read-only APIs. It never reads object contents or secret values.
- NormalizeA bucket is a bucket and a firewall rule is a firewall rule, whichever cloud it came from.
- EvaluateDeterministic policy checks decide pass, fail or unknown. Anything ACSE cannot establish stays unknown and counts against your score.
- MapEach result feeds the framework controls it supports, on every cloud you connect.
Our rule
ACSE never needs write access to your cloud.
Fixes arrive as code in your repositories, or as a runbook for a person to follow. Your pipeline applies them after your team merges.
Questions
What people ask us
Do I need to install agents?
No. ACSE reads configuration through each cloud’s control-plane APIs, from a runtime that runs in your environment. Nothing is installed on your instances or nodes.
What happens if a permission is missing?
The scan still runs. A read that is refused makes that resource unknown, and a check that cannot list its resources reads not evaluated. Neither is ever counted as a pass, and Test connection names the missing permission.
What does ACSE’s hosted service see about my cloud?
Shapes and counts, not resource names, ARNs or ids. Detailed findings and evidence stay in your environment. See the data boundary for the full split.
Does ACSE detect threats or scan workloads for vulnerabilities?
No. ACSE checks cloud configuration for misconfigurations and governs the fix. It does not do runtime threat detection, vulnerability scanning or data discovery.
Keep reading
Related
Detect
ACSE checks every resource in your clouds against the frameworks you choose, from inside your own account, and explains each finding in plain words.
ReadTrustRead-only and keyless
ACSE connects to AWS, Google Cloud and Azure through short-lived, read-only access you create. No long-lived keys, no admin credentials, no cloud writes.
ReadACSEFrameworks
ACSE maps its cloud checks to CIS, PCI DSS, NIST 800-53, FedRAMP Moderate, CCCS Medium, ISO 27001 and SOC 2, with signed, versioned framework content.
ReadTalk to us
See ACSE on your cloud.
Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.