- Home
- Trust center
Trust center
Built so you don’t have to take our word for it.
ACSE is designed so the important guarantees are enforced by the architecture, not by promises. Your data stays in your account. Connections are read-only and use no stored keys. A person decides every change, and the record of it lives with you, where you can verify it without us.
Your data stays in your account
The runtime runs in your cloud. What reaches ACSE is shapes and counts, and the schema refuses resource names and ids.
Nothing to leak, nothing to break
ACSE reads your cloud through short-lived, read-only access you set up. It holds no long-lived keys and never writes to your cloud.
Proof that doesn’t depend on us
Evidence is signed, hash-chained and stored in your account. Your auditor can verify it offline, with no ACSE account.
Topics
Read the design, topic by topic
Each page explains one guarantee, how it is enforced, and where its limits are.
Your data stays yours
What stays in your cloud, what crosses to ACSE, and the registry that denies everything else.
Explore02Read-only and keyless
How ACSE connects to AWS, Google Cloud and Azure with federated, short-lived access and no stored secrets.
Explore03Responsible AI
Where the optional AI runs, what it may do, what it may never do, and who turns it on.
Explore04Evidence you hold
Signed, hash-chained records under write-once retention in your own account.
Explore05Architecture
The two planes, the outbound-only transport and how each request is signed.
Explore06Data residency
Choose the home region for your evidence and settings.
ExploreThe trust spine
Eight rules no shortcut may touch
These are the parts that make the evidence worth something. Every feature is built on them, and none can switch them off.
- Outbound only
- Your runtime opens every connection. Nothing listens in your account.
- Signed requests
- Each request is signed with your tenant’s Ed25519 key and carries a timestamp and a single-use nonce.
- No identifiers across planes
- Posture and risk data carry shapes and counts. The schema rejects names, ARNs and ids.
- Deny-by-default egress
- Nothing leaves your boundary unless a central registry classifies it. An unregistered message is refused.
- Unknown is never a pass
- A fact ACSE can’t establish counts as unknown, and unknown counts against your score.
- Approvals bound to the view
- A decision carries the hashes of the exact view the approver saw. If anything changed, it is refused.
- Separation of duties
- Every decision needs step-up MFA, and a machine can never be the approver.
- Fail closed
- A missing verifier or approval service means refusal, never silent approval.
People decide
Every change has a named approver
ACSE proposes; your people decide. A security approver reviews what the change does, what it was tested against, what is still uncertain and how to undo it, then confirms with fresh MFA.
By default the approver can’t be the person who wrote or requested the change. Smaller teams can allow it with a written justification, and the record names it every time.
- Step-up MFA on every decision
- Stale views refused, never submitted anyway
- Approvals happen only in the portal, never from a chat button
Independent verification
Check the record without us
A case export holds every signed record in order, the view each decision was bound to, and the seal. Your auditor checks it on their own machine, offline, with no ACSE account.
Two verifiers, one in Python and one in TypeScript, are built independently of the code that writes the evidence. They must reach the same verdict on the same file.
For your security review
Documents, on request
This trust center describes how the product is designed. For your vendor review, ask us for the documents you need.
Security documents
Architecture, data-flow and security documents are available on request. Ask through the contact page and tell us what your review needs.
Explore02A walk-through with your team
We can take your security architects through the planes, the transport, the evidence chain and the access you would grant.
ExploreQuestions
What people ask us
Where are your certifications and audit reports?
This trust center describes the product’s design and how each guarantee is enforced. Security documents are available on request: ask through the contact page.
Can ACSE change my cloud?
No. ACSE reads your cloud through read-only access. Fixes arrive as draft pull requests in your repositories, or as a patch or runbook for a person to apply, and your pipeline deploys them after your team merges.
Can InitValue alter the evidence?
The evidence is written to write-once storage in your account, and each record holds the hash of the one before. Changing, removing or reordering a record breaks the chain, and the offline verifier reports it.
What happens if part of ACSE is unavailable?
It fails closed. If the approval service, a verifier or the optional AI model is unavailable, the action is refused or the deterministic path is used. Nothing is approved by default.
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.