Architecture
Built so the wrong things can’t happen.
ACSE is split between a control plane we run and a runtime that runs in your cloud. The runtime does the sensitive work where your data already lives, and talks to the control plane only outward, only signed, and only in shapes and counts.
Nothing to open up
The runtime opens every connection. No inbound ports, no listeners, no vendor access into your account.
Nothing to leak
No long-lived keys. Read-only federated access, minted and used inside your account.
Nothing to take on trust
Every message is signed and every record is chained, so each claim can be checked.
The data boundary
What stays, and what ACSE sees
Select a row to see why the line falls where it does.
Projections carry shapes and counts. The schema rejects resource names, ARNs and ids, so they cannot be sent by mistake.
The risk graph is built in your account. ACSE sees the shape of the path, not who or what is on it.
There are no long-lived keys. Connections use workload identity federation and read-only roles you create.
Evidence is written to append-only storage in your account. ACSE can show and verify it, but cannot change it.
Decisions are delivered back to your account and appended to the chain before they count.
Connecting a cloud
Three steps, self-service
A tenant admin connects a cloud from the portal. Your team runs the generated read-only setup, so ACSE never holds a key.
- 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 case, end to end
From scan to sealed record
- ScanThe runtime reads your cloud and evaluates policy in your account.
- ProposeIt resolves the source, writes the fix, validates it and checks the guardrails.
- DecideA person approves in the portal with MFA, bound to the exact view.
- Deliver the decision homeThe signed decision returns to your account and is chained before it counts.
- Verify and sealAfter the merge, the runtime re-reads the resource, watches the observation window and seals the case.
Engineering principles
Rules the system enforces on itself
Deny-by-default egress
Nothing leaves your boundary unless a central registry classifies it.
No identifiers across planes
The schema rejects resource names, ARNs and ids in anything sent to the control plane.
Unknown is never pass
A fact that cannot be established counts against the score.
Fail closed
A missing verifier or approval service means refusal, never permission.
Questions
What people ask us
What do we install?
The ACSE runtime, in an account you choose. It enrolls itself with a single-use token and generates its own signing key.
Can the whole thing run in our cloud?
The planes are cleanly separated, so ACSE is designed to run fully in a customer’s own environment for buyers who need it. Talk to us about your requirements.
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.
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.
ReadPlatformEvidence
ACSE records every step of every fix in a signed, hash-chained, append-only record in your own account, which an auditor can verify offline.
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.