Trust Center
ALEETH exists to put autonomous AI under institutional control. It would be a contradiction to run our own platform any other way. The controls below are in force today. The work that is not yet finished is named plainly underneath, because a governance company that overstates its own posture has already failed its own test. Nothing on this page is aspirational unless it is labeled so.
AT REST
AES-256
envelope encryption
PROVENANCE
Ed25519
append-only, anchored
ISOLATION
Per-tenant
API-authorized, verified
AUDIT
Immutable
every state transition
Controls In Force Today
These are operating in production now. Each is enforced at the layer that makes it hard to bypass, the database and the cryptography, rather than left to application logic or policy alone.
01.
Every certification state and control event writes to an append-only, Ed25519-signed ledger, then anchors on a recurring cadence into an independent public ledger via OpenTimestamps. Records cannot be edited or deleted after the fact. The math is the authority, not our word.
02.
Data is encrypted in transit with TLS, and at rest. Customer-held secrets such as provider API keys are sealed with AES-256-GCM envelope encryption. Plaintext secrets are never stored in the database and never written to logs.
03.
Every request is authorized against the tenant it targets in the API layer, and cross-tenant access is denied by default. This is independently verified: a token scoped to one tenant receives a 403 when it reaches for another tenant’s data. Row-level security policies at the database provide defense in depth for direct client access, and mutations route through audited, server-side functions.
04.
Operator and customer authority are cryptographically separated; customer tokens are scoped to a single tenant by signed claim and are independently revocable. Operator access is role-based, granted per permission, and requires multi-factor authentication, which is enforced. Enterprise single sign-on via SAML 2.0 and OIDC is available, with per-customer identity-provider configuration and signed-assertion validation.
05.
Every state transition records the actor, the before and after state, source address, and timestamp to an append-only audit log enforced by a database trigger. The record of who did what, when, cannot be rewritten by the application.
06.
An internal sentinel probes platform health and integrity on a fixed cadence and writes any incident to an append-only log, with alerting. We hold our own platform to the same continuous-evidence standard we require of the systems we certify.
Underway · Not Yet Complete
Trust is built by what you admit, not only by what you claim. The following are committed and in progress. None of them is represented as done. If a prospect needs one of these in place before they can proceed, tell us and we will share the current state and the timeline.
A formal readiness program is in progress. We are not yet certified, and we will not claim it until the report is in hand. This page will carry the attestation the day it is issued.
A third-party penetration test against the platform is scheduled. The summary letter and our remediation record will be made available to enterprise prospects under NDA once complete.
Automated SCIM 2.0 user provisioning and deprovisioning is in development. Single sign-on (SAML 2.0 and OIDC), multi-operator accounts, role-based permissions, and enforced MFA are already in force; automated directory-sync provisioning is the remaining enterprise-identity piece.
Data · Residency · Subprocessors
Primary data residency is the United States. We use a small, named set of subprocessors. We do not sell or share customer data, and customer evidence is never used to train third-party models.
Responsible Disclosure
We welcome good-faith security research. If you report a vulnerability in good faith and within the scope below, we will not pursue legal action, we will acknowledge your report, and we will keep you updated through remediation.
DO report promptly, give us reasonable time to remediate before public disclosure, and act in good faith.
DO NOT access, modify, or exfiltrate another customer's data, degrade or interrupt service, or run automated scanning that disrupts availability.
SCOPE aleeth.com and its public verification surfaces (the public certificate verifier and trust pages). Operator and customer consoles, and social engineering of staff or customers, are out of scope.
Next · Provenance
Every statement on this page about signed, append-only, anchored records is verifiable. The live receipt chain and the public-ledger anchor are open to any browser, with no account and no permission required.
See the live proof →