Cloud access
Read-only, and no keys to leak.
ACSE reads your cloud through a role or identity you create, trusted only by your own ACSE runtime. Access is short-lived and read-only. There is no access key, service-account key or client secret for anyone to store, rotate or lose.
Nothing to rotate
Connections use workload identity federation and assumed roles, so there is no long-lived secret to manage.
Access you can read in full
The setup is generated from the exact list of read permissions the checks need, and nothing more.
No path to write
ACSE never needs write access to your cloud. Fixes go to your code as pull requests.
Connect a cloud
Three steps to connect a cloud
Pick a cloud to see what the generated setup creates in your account.
- 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.
You run the setup
ACSE never holds your admin rights
A Tenant Admin chooses the cloud and the scope in the portal. ACSE generates the setup, pre-filled with your values and bound to your own runtime’s identity. Your administrator runs it in your cloud, with your own credentials.
You paste back only non-secret values, such as a role ARN or a service-account email. ACSE never asks for, receives or stores an administrator credential, access key, service-account key or client secret.
- Generated as a template or script and a Terraform module
- Every permission is a read, checked by tests
- Adding or changing a connection needs recent MFA
Per cloud
What the access looks like
- AWS
- A cross-account read-only role whose trust policy names only your runtime’s role, with an external id. For an Organization, deployed across the accounts you choose.
- Google Cloud
- A custom read-only role and a service account with no key, reached through a workload identity pool that admits only your runtime.
- Azure
- An app registration with a federated credential and no secret or certificate, holding only read actions.
- Token lifetime
- Short-lived tokens, minted and used inside your account. Nothing long-lived is stored.
- Scope
- Exactly the accounts, projects or subscriptions you set up. ACSE can’t reach a scope you didn’t grant.
Test connection
If something is missing, it says exactly what
Test connection asks your runtime to assume the identity and make a few read-only calls. The answer is a closed code, never a guess.
Trust not established
The role or federation doesn’t admit your runtime yet.
Permission missing
Names the read permissions the checks need and the setup doesn’t grant.
Scope not found or partial
The account, project or subscription isn’t visible, or only some of it is, with counts.
Why read-only is enough
Fixes go to your code, not your cloud
ACSE delivers each fix as a draft pull request in your repository, through an app you install on the repositories you choose. It never merges. Your pipeline applies the change after your team does.
So even a compromised control plane can’t grant itself access to a scope you didn’t set up, and can’t write to your cloud. Removing a connection is recorded, and the coverage it provided drops visibly.
Questions
What people ask us
Do I need to give ACSE an access key?
No. There is no field for one. Connections use roles and workload identity federation that trust only your runtime.
Who can add a connection?
A Tenant Admin with a recent MFA sign-in. Every change to a connection is an event in your tenant’s record and on the evidence chain.
Can I see the exact permissions before I run the setup?
Yes. The wizard shows the permissions and who in your organization can grant them before you run anything. Each generated role is built from the checks’ own permission list.
How does ACSE read the account it runs in?
The runtime in your account scans that account with its own task role, which only reads the resources it checks. Other accounts, projects and subscriptions are reached through the connections you create.
Keep reading
Related
Data boundary
ACSE runs in your account and sends only shapes and counts. Names, ids and credentials stay with you, and a deny-by-default registry governs what leaves.
ReadACSEClouds
ACSE checks AWS, Google Cloud, Azure, Kubernetes and AI infrastructure for misconfigurations through read-only, keyless connections you set up yourself.
ReadPlatformHow it works
ACSE’s runtime runs in your cloud and connects outbound only, signed. It reads with no keys and keeps evidence in your account. See the architecture.
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.