Your security-critical operations. Defense built into every layer.
A hosted platform designed to protect sensitive applications, keys and decisions: hardware isolation for where the work runs, approvals signed on hardware keys for who may act, and signed records for what happened. We run the infrastructure. You set the rules.
Illustrative capabilities, described from the engineering record. The product has not launched with a client; readiness is a conversation, not a line on this page.
Hardware and software. Working together to protect you.
Isolation, software hardening and authorization each protect a different boundary. Together they put controls around where sensitive work runs, who can approve it, and how you verify the result.
Protected by hardware
Keys remain inside secure hardware. Hardware-enforced boundaries separate network-facing processing from protected components, and NETBREAK, the protocol break in front of every protected instance, limits communication to authorized destinations.
Measured on the bench
Reduce the ways an attack can succeed
Safe Rust provides memory-safety guarantees within its safety model; unsafe code and external interfaces require separate review. SPARK proofs check specified properties of selected critical parsers and data stores under stated assumptions. The compute host uses a read-only system image and a non-executable data partition; the key-holding core has no network stack.
Proof scope published
Critical actions need signed approval
Designated people sign approvals with hardware security keys. An approval is bound to the exact request: the key signs the request's hash, and the service verifies it against the held operation before anything executes. A credential alone moves nothing.
Built on our development installation
Every sensitive action takes the same path.
A request that fails a required check does not proceed to execution. The four components behind the path are Vault (keys), Approvals (policy and named approvers), Ledger (signed records) and Protected compute (hardware-isolated, hardened software).
Built, and where.
What the engineering record shows running on our own development installation, as distinct from what is designed.
| Identity | Sign-in with hardware security keys and passkeys; sessions graded by the key that signed in; an email-first sign-in. Built. |
|---|---|
| Approvals | Held changes approved by named members on the request hash, with executor and class locks; a policy per class of change. Built. |
| Records | An audit log and organization stream, webhooks, exportable records; the record-verification check shown on the home page. Built. |
| Protected compute | Hosts that report a hardware quote at every check-in, with each image's measurement compared before it is trusted; VMs started by signed, approved orders; measured images with their build records and vulnerability reports. Built on one development host. |
| Builds | Every image's build record, software bill of materials and vulnerability report published by the pipeline and read by the platform; approvals copy them into the record. Built. |
| Design, not built | Service tiers and a shared tier's isolation; generated client libraries and an SDK release; a public developer path; the signing device's path from the device to the platform (see the Signing Display preview). |
What we can show you.
Formal verification
Selected properties of selected components are formally verified under stated assumptions. Not a claim about the whole system; the briefing covers what is and is not in scope.
Compliance
Certification and audit status changes over time. Ask us for the current position rather than relying on a list on this page.
Technical evidence
Architecture, threat model and verification material are walked through in a 90-minute engineering briefing under NDA.
AlphaPoint Cloud is described as designed and as it runs on our own development installation. No customer deployment, certification or outcome is represented on this page.