Proof rooted in hardware.
Our products rest on one idea: instead of asking you to trust us, we run audits and builds inside hardware that can prove what it did. This page explains the building blocks, and how we bind them together.
Trusted Execution Environments
A Trusted Execution Environment (TEE) is an isolated environment created by the CPU itself. Modern TEEs, such as AMD SEV-SNP, Intel TDX, and AWS Nitro, are designed to protect a running program so that even the cloud provider or a system administrator cannot access or tamper with it. This is often called Confidential Computing: it protects data while it is being processed, not just at rest or in transit.
Remote attestation
The feature we care most about is remote attestation. The CPU measures the code that is loaded into the TEE at launch and signs a report with a key that chains back to the hardware vendor.
This is what "hardware-backed trust" means in practice: the trust anchor is a tamper-resistant CPU feature, not a software configuration, a policy, or a contract. You do not have to trust the infrastructure operator, and you do not have to trust us. What remains is trust in the CPU vendor and in the small, measured software stack, and that is a far smaller thing to trust. You verify the report yourself.
We are primarily after integrity
TEEs are usually marketed for confidentiality: keeping data secret while in use. We mostly use them for something else: integrity. An attestation proves that a specific, known program ran on specific inputs and produced a specific output, untampered. That is what makes the execution of an audit or a build verifiable rather than taken on faith.
Confidentiality still matters where the data itself is sensitive. Our Confidential SBOMs product uses the same hardware to answer questions about an SBOM without ever revealing it.
The input-code-output graph
A single attestation certifies a single execution and nothing more. Our work is binding those attestations together into evidence you can actually use.
Each attested execution produces one signed record binding three things together: the inputs (a source tree, a dependency diff), the code that ran (an audit program, a build recipe), and the output (a verdict, a binary). Because each part is hashed into the attestation, none of them can be swapped out after the fact.
Attested evidence graph
⇄ queried by AI agents
Customers & auditors ✓
verify, at scale
These records chain into a graph. An Attestable Builds record proves a binary came from its source; a Dependency Canary record proves a verdict came from auditing a specific diff. The same structure covers both, so you can follow the chain from the artifact you deploy back to the audits of the code inside it, and query it via API.
Check a real attestation yourself at app.lightsquares.dev/verify.
Want to see this applied to your supply chain?
Book a call with our founders or explore the products built on this technology.