A vendor-neutral verification layer for attested compute.
Hardware attestation is fragmented. A phone, a CPU enclave, and a datacenter GPU each produce Evidence in a different format, signed against a different trust anchor, answering a different question. Seven KG appraises all three behind one interface and issues a single evidence artifact an auditor can act on.
Attestation roots are not interchangeable.
Every vendor ships its own Attester, its own quote format, its own certificate chain, and its own revocation story. There is no common Verifier, and no common shape for Attestation Results. An organization running mixed hardware ends up with one integration per root and no way to compare their outputs.
The failure that matters is subtler than integration cost. A VM-level claim is not a GPU-level claim. A confidential VM can show that its memory is encrypted and that its firmware measured a known launch state. On its own it cannot show which accelerator executed the workload, that the accelerator was in a confidential mode, or that the driver on the path was the one measured.
Those are different claims about different hardware. Presenting one as evidence for the other is the most common error we see, and it is the one a compliance reviewer is least equipped to catch — the paperwork looks complete either way.
One verifier, one policy language, one artifact.
We sit between the Attesters and the Relying Party, in the Verifier role described by RFC 9334.
- Verifier
- We accept Evidence from supported Attesters, validate each certificate chain to its vendor trust anchor, check freshness against the nonce, and emit Attestation Results in one normalized schema regardless of origin.
- Policy engine
- Appraisal Policy is configuration, versioned and diffable, not code buried in a service. A Relying Party states the properties it requires. The engine returns a decision and the specific claim that produced it.
- Evidence artifact
- Each appraisal produces a signed, timestamped record: the Evidence as received, the policy version applied, the outcome per claim, and the boundary of what was verified. It is written to be read by a compliance officer, not only parsed by a program.
- Brokerage
- Where a workload needs attested capacity it does not own, we match demand to supply and carry the verification through to the same artifact. Fiat invoicing. No token, no chain, no wallet.
We publish what each root cannot attest.
Every attestation technology has a boundary. Vendor documentation describes the inside of it thoroughly and the outside of it rarely. We document both sides, in the same artifact, with the same weight.
For each supported root, the artifact carries an explicit non-claims section: the properties that root does not cover, the assumptions that remain unverified, and the residual trust the Relying Party is still extending whether or not it intended to. A result that reads verified without naming its boundary tells an auditor nothing they can defend.
We can do this because we do not sell hardware. We have no reason to make any root look broader than it is, and stating the limits plainly costs us nothing we want to keep.
Contact.
We are talking to security and compliance teams evaluating attested compute, and to operators with capacity to attest. Direct email only.
Seven KG is not yet incorporated. Until it is, there is no legal entity to act as a data controller, so this site collects nothing: no forms, no cookies, no analytics, no third-party requests. Everything you loaded came from this origin.