Attestation & Trust Model
Attestation is the mechanism that turns "trust us" into "check the math." This page explains what Polaris verifies, how the layers build on each other, and what happens when verification fails.
The trust anchor
Every confidential CPU and GPU that Polaris supports contains a private key fused into the silicon at manufacturing. The chip uses it to sign attestation reports: statements about what firmware booted, what launch measurement the environment has, and what security configuration is active. The corresponding public keys are published by AMD, Intel, and NVIDIA.
That means anyone, anywhere, can verify an attestation report with nothing but the chip vendor's published keys and open cryptography. There is no service to subscribe to and no authority to believe. If the signature verifies, the hardware made that statement. This is what we mean by math is the trust anchor.
On platforms that support direct attestation, the Polaris SDK performs exactly this check on the client side. Neither the cloud provider nor Fr0ntierX is in the trust path.
The five appraisal layers
One hardware signature proves the platform. It does not prove that the right application is running, or that the environment is still healthy an hour later. Polaris therefore appraises evidence in five layers, stacked from the silicon platform up to live runtime behavior. Each layer emits hardware-rooted evidence, each answers a different question, and Polaris turns that evidence into continuous proof: trust proven layer by layer, and halted or alerted on the moment a layer stops checking out.
| Layer | Name | Question it answers | Anchored in |
|---|---|---|---|
| L1 | Platform | Is this genuine confidential hardware with up-to-date firmware, running the expected environment? | CPU vendor silicon keys (AMD, Intel) or the cloud platform's attestation service |
| L1-GPU | Accelerator | Is the GPU in genuine confidential-computing mode, with verified firmware, driver, and secure boot? | NVIDIA silicon keys via NVIDIA's attestation service |
| L2 | Image integrity | Is the running container exactly the one that was deployed, byte for byte, with valid signatures? | Cryptographic digests and signature verification |
| L3 | Runtime behavior | Is the workload behaving the way the approved version behaves: processes, network connections, file access? | Continuous observation by the Sentinel agent |
| L3.1 | Kernel integrity | Has the operating system kernel itself been tampered with at runtime? | Kernel-level integrity checks by the Sentinel agent |
The layers are deliberately independent, and each covers a blind spot of the ones below it:
- L1 is the foundation. Everything above it inherits its guarantee: if the platform is not a genuine, correctly configured TEE, no amount of software checking matters. L1 catches a fake TEE, a downgraded firmware version, or a debug-enabled environment posing as a production one.
- L1-GPU extends the boundary to the accelerator. A healthy CPU report says nothing about the GPU sitting next to it. When a confidential GPU is part of the deployment, its firmware, driver, VBIOS, and secure-boot state are verified independently. CPU and GPU evidence are cryptographically bound together and to the same session, so an attacker cannot mix a healthy CPU report with a GPU from somewhere else.
- L2 pins the workload identity. A genuine TEE running the wrong container is still the wrong environment. L2 catches a swapped, modified, or unsigned image before it ever handles data.
- L3 watches what the workload actually does. Boot-time checks can never see an environment that started clean and was compromised while running. Behavioural monitoring compares live process, network, and file activity against a learned baseline and flags drift.
- L3.1 guards the layer L3 stands on. Runtime monitoring is only as trustworthy as the kernel it runs on. Kernel integrity checking detects rootkit-level tampering, the class of attack designed specifically to blind the monitoring above it.
Above the five layers sits governance and compliance: because every appraisal is grounded in hardware-rooted evidence, compliance reporting can assert against verifiable proof of what actually ran, not asserted controls. Polaris continuously evaluates attestation results against common frameworks (CMMC, NIST, HIPAA, PCI DSS, SOC 2) and emits signed compliance assertions, and revokes them explicitly the moment an appraisal fails.
Continuous appraisal
Polaris treats trust as something that expires every epoch. The Policy Manager evaluates fresh evidence from every workload on a short, regular cycle, and the workload's keys hold only as long as the proof does. Each round of evidence is bound to a fresh challenge so it cannot be replayed. Three properties keep the process honest:
- Independence. The appraiser runs outside the workload VM. A compromised workload cannot grade its own homework.
- Freshness. Stale evidence is treated as failure. A workload that stops reporting loses its keys, a behavior we refer to as the dead man's switch.
- Auditability. Appraisal results are signed and recorded in a public transparency log. Not even the Policy Manager can quietly rewrite history.
When verification fails
A failed appraisal has immediate, automatic consequences:
- Key revocation. The Policy Manager revokes the workload's access to its KMS keys. Data encrypted at rest becomes unreadable to the compromised environment within seconds.
- Traffic stops. The enforcement gate in the Secure Proxy stops serving workload traffic.
- Everyone finds out. The failure is published over signed event streams and APIs so SIEMs and operators can react, and the decision is recorded in the transparency log.
There is no manual step in this chain. The point of attestation with consequences is that a compromise is contained faster than a human can read the alert.
What attestation does not do
For completeness, two honest limitations:
- Attestation proves the environment is what it claims to be. It does not make a vulnerable application invulnerable. If your workload has an exploitable bug, Polaris will attest a faithfully running vulnerable workload, though runtime monitoring is designed to catch the effects of exploitation, such as unexpected processes or network connections.
- Confidential computing protects data in use from the infrastructure. Whoever legitimately operates the client side of a session can still see the data they send and receive. Polaris secures the pipe and the environment, not the intentions of authorized users.
Continue to Supported Platforms for where this model runs.