- Home
- Platform
The ACSE platform
One loop from finding to fixed and proven.
Most tools stop at the finding. ACSE carries it the whole way: it detects the misconfiguration, shows the path an attacker would take, writes the fix as code, gets a person’s approval with MFA, verifies the result and keeps the record in your own cloud.
Risk that actually goes down
Findings close because each one arrives with a fix your team can review and merge, not another ticket to triage.
Change your auditors can follow
Every decision is bound to what the approver saw, signed, chained and kept where your auditor can verify it without us.
Control that stays with you
ACSE runs inside your cloud, reads with no keys, writes nothing to your cloud and needs a person to decide.
The loop
Eight capabilities, one system
Each part of ACSE feeds the next, and every step leaves evidence behind.
Detect
Misconfiguration checks across AWS, Google Cloud, Azure, Kubernetes and AI infrastructure.
Explore02Risk graph
The links between resources, and the paths from the internet to your data.
Explore03Fix
Validated pull requests into your own infrastructure code, never auto-merged.
Explore04Approvals
Six clear outcomes, step-up MFA and nobody approving their own change.
Explore05Evidence
A signed, append-only record in your account, verifiable offline.
Explore06Compliance posture
Seven frameworks, versioned and signed, with a governed and a raw score.
Explore07Governed AI
Optional explanations and drafts that pass through the same checks and a person.
Explore08Integrations
GitHub, Terraform, your identity provider, Teams and your SIEM.
ExploreTry it
Follow one path from entry to data
Hover or tab through the graph to see why each resource is on the path, then switch on the fix.
Risk graph · example
Entry point
Internet
Anyone can reach the load balancer. This is where the path starts.
Weak point · High
Load balancer
The listener accepts plain HTTP on port 80, so traffic is unencrypted.
Resource
Function
The load balancer forwards requests to this function. Link: LB_TARGETS_FUNCTION.
Identity
Role
The function runs as this role. Link: FUNCTION_ASSUMES_ROLE.
Data · Critical
Data bucket
The role can read this bucket, and the bucket allows public access. Link: ROLE_CAN_ACCESS.
Context
Network
The network the load balancer sits in. Not on this path.
Safeguard
Key
Encryption at rest is on for this bucket. A safeguard, but it does not stop public reads.
Resource
Log bucket
Another bucket the role can write to. Private, so it is not on the attack path.
After the fix
The path is cut
The draft pull request blocks public access to the bucket. The role still works, but the internet can no longer reach the data, so the path closes and the case moves to verification.
Illustrative graph. The link names are the ones ACSE records.
Where ACSE runs
The work happens in your cloud
ACSE is split in two. The runtime sits in your own account: it reads your cloud, evaluates policy, prepares fixes and keeps the evidence. The control plane holds the portal, approvals and reports.
The runtime opens every connection, outbound and signed. Nothing listens in your account, and what reaches the control plane is the shape of your risk, never the names of your resources.
- Read-only connections with no stored keys
- Evidence kept in append-only storage you own
- Identifiers never cross to the control plane
Our principle
Rules and tests do the work. People decide. The record proves it.
Detection and fixes are deterministic. AI is optional, off by default, and only ever drafts.
Whoever found it
Already have a scanner? Keep it.
ACSE detects on its own, and it can also take the findings your existing tools produce and carry them through the same governed fix, approval and evidence.
You keep the tools your team trusts. ACSE closes the part they leave open: the fix, the decision and the proof.
Questions
What people ask us
What does ACSE detect?
Cloud misconfigurations: public storage, weak network exposure, missing encryption, over-broad identities and the like, checked against the frameworks you choose. ACSE does not do runtime threat detection, workload vulnerability scanning or data classification.
Does ACSE need write access to my cloud?
No. Connections are read-only. Fixes go to your code as pull requests, and your own pipeline applies them after your team merges.
Where is my data kept?
In your account. The runtime and the evidence store run there. The control plane receives counts and shapes for dashboards and approvals, never resource names, identifiers or credentials.
Keep reading
Related
How 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.
ReadSolutionsFix existing findings
Whoever detected the misconfiguration, ACSE turns it into a reviewed fix in your own code, verifies the cloud afterwards and keeps a signed record.
ReadACSETrust center
How ACSE keeps your data in your account, connects read-only with no keys, keeps people in charge of every change and leaves proof you can check yourself.
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.