Architecture

Polaris separates duties across a small number of components with one design rule: the party that runs the workload never appraises itself. Evidence is produced inside the confidential environment, but judged outside it, and the judgment controls access to keys.

The big picture

Polaris Proxy

The proxy is the only component that touches your traffic. It runs inside the confidential VM, in front of your unmodified application, and is responsible for:

• TLS termination inside the boundary. The certificate's private key is generated inside the TEE; on platforms with a hardware-isolated security module the key is held where even the guest OS cannot extract it. TLS 1.3 with post-quantum hybrid key exchange is supported.
• Attestation service. The proxy collects hardware evidence, binds it to the TLS key, and serves it to clients and to the Policy Manager. On supported platforms it serves the raw hardware report so clients can verify against the silicon vendor directly.
• Transparent encryption. Optional end-to-end payload encryption with keys negotiated against the attested environment, plus encryption of data before it reaches storage.
• Enforcement gate. The proxy blocks workload traffic until the environment has a passing appraisal, and stops serving if the appraisal turns unhealthy.

Polaris Policy Manager

The Policy Manager is the independent appraiser. It runs outside the workload VM and continuously evaluates evidence in layers:

• Platform layer. Is this genuine, up-to-date confidential hardware, running the expected firmware and launch measurement? Verification is done against the silicon vendors' key hierarchies (AMD, Intel, NVIDIA), directly where the platform allows it.
• Image layer. Is the running workload exactly the container that was deployed? Image digests and signatures are checked against a baseline captured at deployment, with support for signature transparency tooling.
• Runtime layer. Is the workload behaving the way it did when the baseline was learned? Evidence comes from the Sentinel agent: process, network, and file-access behavior plus kernel integrity signals.

The appraisal result drives the KMS gate: platform-native key access control (Google Cloud KMS, AWS KMS, Azure Key Vault, OCI Vault) is granted while appraisal passes and revoked when it fails. Results are also published over signed APIs and event streams so your monitoring can react, and recorded in a transparency log for audit.

Freshness challenges flow between the Policy Manager and the proxy so that every round of evidence is provably new, not replayed.

Polaris Sentinel

Sentinel is a lightweight agent inside the environment that observes what the workload actually does at runtime, from process launches to network connections to file access, and checks kernel-level integrity. It exposes this evidence to the proxy, which forwards it as part of the continuous appraisal. Sentinel is how Polaris notices the attacks that boot-time attestation cannot: a workload that booted clean and was compromised afterwards.

Polaris SDK

The SDK is the client's half of the trust story, for servers and applications that talk to Polaris-protected workloads:

• Full attestation verification, including direct hardware-report verification with no cloud service in the trust path on supported platforms.
• The TLS binding check that defeats relay attacks, and certificate pinning helpers.
• Client-side payload encryption compatible with the proxy's transparent decryption.
• GPU attestation verification for confidential GPU deployments.

Trust boundaries, summarized

Polaris is built so that you never have to trust Fr0ntierX. Everything runs on infrastructure you control, your own cloud account or your own data center. We operate no service in the connection path, we hold none of your keys, and we never see your data or your traffic. There is no Fr0ntierX cloud to route through and nothing to phone home to.

We are also not a party you have to take on faith. The Polaris components inside the environment are measured and attested exactly like the rest of your workload, and clients verify that evidence themselves against the silicon vendor's published keys. On direct-attestation platforms the verification chain runs from the chip to your own client with no intermediary at all. If the math checks out, the guarantee holds regardless of what you assume about Fr0ntierX; if it does not, no assurance from us would make it safe. That is the point: trust is placed in hardware and cryptography you can check, not in us.

Party	Do you have to trust them?
CPU/GPU silicon vendor (AMD, Intel, NVIDIA)	Yes. This is the hardware root of trust, and their published keys are the verification anchor. It is the one trust assumption confidential computing cannot remove.
Cloud provider	Not for confidentiality. The provider hosts the hardware but cannot read memory encrypted against the host, and on direct-attestation platforms it is not in the verification path either. You rely on it only for availability.
Fr0ntierX	No. Polaris runs entirely on customer-controlled infrastructure. Fr0ntierX is not in the data path, control path, or verification path, and nothing is sent back to Fr0ntierX.

For the details of what verification covers, continue to Attestation & Trust Model.