AttestorianWe sell evidence. So we start with ours.
How Attestorian is designed, what it can and cannot prove, where the product stands today, and how to report a security issue.
Six commitments built into the product.
Customer-controlled keys
Evidence can be signed with keys held in your own KMS or HSM. The party accountable to regulators holds the seal.
Standard cryptography only
The production core uses widely adopted, publicly reviewed algorithms through established libraries. Research components are isolated and disabled in production builds.
Fail-closed verification
Any inconsistency, missing step, or extra step fails verification. There is no partial pass.
Bounded parsing
Verifiers enforce size and decompression limits to resist malformed or malicious packages.
Cross-implementation agreement
Independent verifiers written in different programming languages must agree on a shared conformance corpus.
No vendor dependency
Verification works offline, without Attestorian services, for as long as you keep your evidence.
What sealed evidence proves, and what it does not.
A valid seal proves
- The record has not changed since it was sealed
- Which key, and therefore which party, sealed it
- The order and completeness of the recorded steps
A seal alone does not prove
- That a compromised system recorded truthfully
- That capture was complete outside instrumented paths
- That local clock time was authoritative
- That an AI answer or decision was correct
How we address these limits
Capture-completeness declarations state exactly which paths are instrumented. Trusted time-stamping and independent witnessing options anchor time and prevent silent rollback. Human approval controls keep people accountable for high-impact decisions. We document each boundary openly rather than hiding it.
Where Attestorian stands today.
We believe partners should know exactly where a technology stands before they rely on it.
| Area | Status | Detail |
|---|---|---|
| Core recorder, sealing, redaction, verification | Working | Covered by automated tests, including cross-language conformance across a shared corpus of 31 test packages |
| Offline verifiers (command line, TypeScript, browser) | Working | Available for pilots and demonstrations |
| Inline tool gateway and policy controls | Working | Local benchmark: median under 0.3 ms added per tool call. Pilot acceptance target: 5 ms or less. |
| Banking demonstration scenario | Working | End to end in the demonstration environment, including adversarial tests |
| Multi-tenant control plane | Reference | Reference implementation with row-level security |
| External KMS, HSM, and time-stamping integrations | Per deployment | Designed; configured and validated for each deployment |
| Independent third-party security review | Planned | We welcome a review commissioned or nominated by a partner |
| Production deployments | Design-partner stage | Our 30-day pilot is designed to establish production evidence together |
No trackers. No cookies. No third parties.
This site loads no analytics, advertising, or third-party scripts, sets no cookies, and serves its fonts and assets from its own domain. The interactive demonstrations run entirely in your browser and send nothing anywhere.
Read the privacy noticeReport a security issue.
If you believe you have found a vulnerability in Attestorian software or this website, compose a security report with a description and steps to reproduce. If JavaScript or a local email app is unavailable, use the contact address in our linked security.txt file. Please give us reasonable time to investigate before public disclosure, and do not access data that is not yours or degrade service for others.
Machine-readable contact: /.well-known/security.txt
Technical standards and verification references.
These documents explain the standards and data formats referenced in our technical material. A reference is not an independent security review or certification of Attestorian.
- RFC 8785: JSON Canonicalization Scheme describes deterministic JSON representation for repeatable hashing and signing.
- RFC 8032: EdDSA signatures defines Ed25519 and Ed448 signature algorithms.
- RFC 6962: Certificate Transparency documents the Merkle-tree construction referenced by our evidence format. RFC 9162 is the successor Certificate Transparency specification.
- RFC 9116: security.txt defines the machine-readable vulnerability contact file published by this website.
For the current implementation boundary, key-trust requirements, and deployment-specific integration status, use the maturity table above and request the evidence pack.
Inspect our security model and evidence.
Request the technical evidence pack or review our threat model with your security team. The USD 10,000 pilot fee is credited in full toward your annual license.
Last updated: