Skip to main content

Verifying a Deployment

Deploying gets Polaris running. Verification proves it is doing its job: that your workload sits inside a genuine confidential environment, running the stack you expect, and staying that way. There are two things to know. A client runs a connect-time check before it sends anything sensitive. And the Policy Manager keeps verifying the environment continuously for as long as the workload runs. Both are anchored in hardware, and both have consequences when a check fails.

What Polaris verifies​

Verification is layered. Each layer emits hardware-rooted evidence, answers a different question, and covers a blind spot of the ones below it. The Attestation & Trust Model page describes each in depth; in short:

  • L1, platform. Is this genuine confidential hardware, with up-to-date firmware, running the expected environment? Verified against the CPU vendor's silicon keys.
  • L1-GPU, accelerator. On confidential-GPU deployments, is the GPU in genuine confidential-computing mode, with verified firmware, driver, and secure boot? Verified against NVIDIA, and cryptographically bound to the CPU evidence so the two cannot be mixed and matched.
  • L2, image integrity. Is the running container exactly the one that was deployed, byte for byte, with valid signatures?
  • L3, runtime behavior. Is the workload behaving the way the approved version behaves: its processes, network connections, and file access?
  • L3.1, kernel integrity. Has the operating system kernel been tampered with at runtime?

A deployment is healthy only when every layer that applies to it checks out.

The connect-time check​

Before a client sends data, it verifies the environment end to end, using the Polaris SDK. Three things have to hold:

  • Genuine hardware. The environment presents a hardware-signed attestation report, and the client checks that signature against the silicon vendor's published keys. A fake or misconfigured environment cannot pass.
  • Your stack. The report carries the launch measurement and platform properties, and the client checks them against what you expect, so the environment is not just a TEE but your TEE running your workload.
  • This connection. The report is bound to the TLS session, and the client checks that the key securing the current connection is the one the hardware vouched for. This defeats a relay that forwards someone else's genuine report.

Only when all three hold does the client pin the connection and start sending data. On platforms that support direct attestation, the SDK checks the raw hardware report against the silicon vendor with no cloud service and no Fr0ntierX service in the path. Run this check yourself once right after deploying; every client then repeats it on every connection.

Continuous verification​

A passing connect-time check is a snapshot. Environments drift, get patched, or get attacked, so the Policy Manager re-checks all five layers on a short, regular cycle for the life of the workload. Three properties keep that honest:

  • Independence. The appraiser runs outside the workload VM, so a compromised workload cannot grade its own homework.
  • Freshness. Each round of evidence is bound to a new challenge and cannot be replayed, and a workload that goes silent loses its keys. We call that the dead man's switch.
  • Auditability. Every appraisal result is signed and recorded in a transparency log, so the history of an environment's health cannot be quietly rewritten.

While the layers pass, the workload keeps access to its KMS keys. The moment a layer fails, that access is revoked automatically and the proxy stops serving traffic. A compromised environment keeps running but can no longer read the data it exists to protect.

Results reach your SIEM​

You do not have to poll for any of this. Attestation results stream out over signed event streams and APIs, so your SIEM and monitoring ingest them and alert on a failure the same way they handle any other security signal. Because the events are signed, they are tamper-evident: your SIEM can trust that a result came from the Policy Manager and was not forged or altered in transit.

Compliance​

Because every appraisal is grounded in hardware-rooted evidence, Polaris turns it into signed compliance assertions against common frameworks, including CMMC, NIST, HIPAA, PCI DSS, and SOC 2. These assert against verifiable proof of what actually ran, not asserted controls, and they are revoked the moment an appraisal fails. The compliance report flows to your SIEM alongside the attestation results, so evidence of compliance, and of its loss, lands in the same place your team already watches.

Reading a failure​

A failed verification is a stop sign, not a warning to click through. Common causes:

  • The environment is not confidential. If the VM was launched without its confidential-computing mode enabled, it cannot produce a valid report and verification fails at the first check. This is the safety net for the launch setting described on the AWS page: a non-confidential instance fails cleanly here instead of quietly serving traffic.
  • The measurement does not match. The environment is a genuine TEE, but not running what you expected. Confirm you are checking against the right workload and image.
  • The connection is not bound. The report is valid but not tied to this connection, the signature of a relay. Do not send data.

After it passes​

Once the connect-time check passes, the deployment is ready for traffic and continuous verification carries it from there: every layer re-checked each cycle, key access held only while the proof holds, and every result and compliance assertion delivered to your SIEM. You prove it once by hand; Polaris proves it continuously after that.