Skip to content

Threat Model

What Nanorix attests to, what it doesn't, and what attacks the capsule boundary defends against.

Deployment posture. The substrate described below is the Nanorix-hosted Evaluation Sandbox. Production regulated-data processing runs in customer infrastructure (BYOC), where the same capsule isolation applies on infrastructure the customer controls.

What Nanorix attests to

Nanorix's AuditProof attests to the capsule boundary:

  1. Sealed isolation. The capsule executed inside Linux kernel isolation primitives (6 namespace layers + cgroup v2 + seccomp). The kernel enforced the boundary; we composed it into a proof.
  2. Volatile-only memory. The capsule had no persistent disk. All state lived in tmpfs (RAM-backed) and was destroyed when the capsule was destroyed.
  3. Cryptographic destruction. The 8-step SHA-512 hash chain plus Ed25519 signature attests that the destruction sequence ran end-to-end: namespace teardown, tmpfs unmount, multi-pass DoD-5220 memory wipe, key incineration, forensic verification.
  4. Activity trail integrity. Every recorded activity event (file uploads, executions, HTTPS calls, batch operations) is bound into the canonical hash. Tampering with any event invalidates the signature.
  5. Egress provenance. Every outbound HTTPS call from the capsule is sealed-daemon-routed: the destination, request body hash, response body hash, TLS pin verification outcome, and duration are bound into the AuditProof.

What Nanorix does NOT attest to

These are explicitly out of scope — they are the customer's responsibility:

  1. Customer code correctness. Nanorix doesn't audit your Python/Node code. If your workload has a bug that leaks data through a side channel (timing, error messages, log output), the AuditProof shows your code ran but doesn't certify it was bug-free.
  2. LLM / API provider trust. When your capsule calls Anthropic / OpenAI / a customer's payer API, Nanorix attests to the call (request hash, response hash, TLS pin) but does not attest to what the provider does with the data. That's between you and the provider.
  3. Compliance status. The regulatory_context reference module produces related-to mappings — never compliant-with assertions. Compliance is a determination your auditor or compliance officer makes; Nanorix produces the evidence input.
  4. Customer-declared fields. data_classification ("PHI" / "PII" / "financial" / etc.) and jurisdiction ("US" / "EU" / etc.) are customer-attested. Nanorix doesn't verify them. If you declare data_classification: "general" while uploading PHI, the AuditProof reflects what you declared, not what's true.
  5. Side-channel inference attacks. If the capsule's CPU usage, memory pressure, or timing leaks information through host-OS metrics that an attacker on the same Cloud Run instance can observe, Nanorix's isolation stack doesn't fully defend against that. (Cloud Run gen2's per-revision instance isolation provides one layer; consider per-pilot dedicated tenancy if your threat model includes co-tenant adversaries.)
  6. Pre-capsule data flow. The data was in a state somewhere before it entered the capsule. Nanorix attests from capsule-create onward; the upstream pipeline is yours.

Attack scenarios + defenses

Scenario 1: A capsule operator wants to exfiltrate customer data

Attack: A Nanorix engineer with cluster-admin access tries to read capsule memory.

Defense: Capsule memory lives in tmpfs (RAM). At capsule destroy, the multi-pass DoD-5220 wipe overwrites every page before unmount. The destruction sequence overwrites and unmaps capsule memory before teardown; the AuditProof attests the sequence executed. Pre-destroy reads would require the attacker to win a race against capsule lifetime (typically seconds to minutes); the AuditProof would not record their read (it's host-side state), so this attack can succeed against an active capsule but cannot affect destroyed ones. Recommendation: pair with Cloud Audit Logging on the underlying GCP project so any privileged container access is recorded out-of-band.

Scenario 2: An attacker wants to forge an AuditProof

Attack: A bad actor wants to claim a capsule destroyed sensitive data when it didn't.

Defense: Forging requires the Ed25519 private key. Keys are generated per-capsule and destroyed with the capsule (the key-destruction step of the chain (dire_keys)). The public key is published in the AuditProof; the private key never leaves capsule volatile memory. To forge, attacker must either (a) extract the private key during capsule lifetime (see Scenario 1), or (b) compromise the Ed25519 algorithm (no known practical attack against Ed25519). The AuditProof is verifiable offline against the published public key — anyone can detect a forged proof.

Scenario 3: The customer's code phones home with PHI

Attack: A malicious customer-side workload tries to exfiltrate PHI to an attacker-controlled host.

Defense: The egress allowlist (declared at Capsulefile build time + checked at runtime by the sealed daemon) blocks any destination not on the list. With no allowlist declared, the capsule has no network at all. With an allowlist that omits the attacker host, calls to that host fail with egress_denied and the activity_trail records the denial. Customer cannot configure the allowlist post-capsule-create — it's bound at create time and immutable for the capsule lifetime.

For higher assurance, customers declare TLS pin maps (tls_pinned_certs) — even if an attacker compromises DNS to point an allowed hostname at their own host, the TLS handshake fails because the SHA-256 fingerprint won't match.

Scenario 4: A regulator demands evidence the capsule destroyed PHI

Attack: No active attack — a compliance audit.

Defense: Customer hands the regulator the AuditProof. Regulator runs nanorix verify auditproof.json — the offline CLI reproduces the 8-step hash chain, verifies the Ed25519 signature against the published public key, walks the activity_trail to confirm the recorded events match the customer's logs, and surfaces any discrepancies. The reference module produces the regulator-relevant framework binding (HIPAA §164.312, GDPR Article 32, etc.). The chain of custody is cryptographic, not based on Nanorix's word.

Scenario 5: A subpoena requires production of capsule contents

Attack: No active attack — a legal discovery scenario.

Defense: Nanorix has nothing to produce — capsule contents lived in volatile memory and were destroyed when the capsule was destroyed. The AuditProof exists; the data does not. Customer hands over the AuditProof + their own copies of input/output files (they wrote them to their own systems). The regulator/court sees: "Nanorix attests this data was processed in this isolated environment for this duration and destroyed. Here are the operational hashes; the data itself is not recoverable."

This is the zero-retention posture and it is designed for pipelines such as legal eDiscovery, behavioral health, and EU data processing under GDPR.

Scenario 6: A nation-state adversary compromises the cloud provider

Attack: State actor with hypervisor-level access to the underlying GCP infrastructure.

Defense: This is genuinely hard. Linux kernel isolation runs above the hypervisor; if the hypervisor is compromised, Linux primitives can be bypassed by reading guest memory directly. Two mitigations:

  1. Customer-managed KMS for memory artifacts. When using the multi-session memory artifact pattern, the artifact is encrypted with the customer's KMS key. Even if the hypervisor reads the encrypted blob, the plaintext requires customer-side authorization to decrypt. Nanorix never holds the plaintext.
  2. Confidential computing. Future Nanorix infrastructure may run on Confidential VMs (AMD SEV / Intel TDX) — adds hardware-level encryption of guest memory that even the hypervisor cannot read. Tracked as a future roadmap item.

For pilots whose threat models include nation-state adversaries, contact us for the dedicated-tenancy + Confidential Computing roadmap.

Trust boundaries

Drawing the trust boundaries explicitly:

  ┌──────────────────────────────────────────────────────────┐
  │ Customer's compliance + ops trust domain                 │
  │                                                          │
  │  ┌──────────────────────────────────────────────────┐    │
  │  │ Customer's verifier — replays AuditProof offline │    │
  │  └──────────────────────────────────────────────────┘    │
  │                       ↑ AuditProof JSON                  │
  ├───────────────────────│──────────────────────────────────┤
  │ Nanorix's attestation domain                             │
  │  ┌──────────────────────────────────────────────────┐    │
  │  │ Per-capsule isolated environment                 │    │
  │  │ ┌──────────────────────────────────────────────┐ │    │
  │  │ │ Customer's workload code + customer's data   │ │    │
  │  │ │ (Nanorix CANNOT inspect; only attest)        │ │    │
  │  │ └──────────────────────────────────────────────┘ │    │
  │  │ ┌──────────────────────────────────────────────┐ │    │
  │  │ │ Sealed daemon (records every egress request) │ │    │
  │  │ └──────────────────────────────────────────────┘ │    │
  │  └──────────────────────────────────────────────────┘    │
  └──────────────────────────────────────────────────────────┘
                          ↑ HTTPS API
                          ↑ TLS-pinned, sealed-daemon-routed
                          ↓
  ┌──────────────────────────────────────────────────────────┐
  │ Third-party API providers (Anthropic / OpenAI / payer)   │
  │ — Customer's trust relationship; outside Nanorix's scope │
  └──────────────────────────────────────────────────────────┘

The customer's trust model spans the whole stack. Nanorix's attestation covers the middle layer. The third-party API providers are the customer's responsibility — Nanorix attests to what was sent to them and what came back, not to what they did with it.

What to do if you find a vulnerability

Email security@nanorix.io with details. We aim to acknowledge within 24 hours and triage within 72 hours, and we credit the reporter in the public CVE if applicable. Our target coordinated-disclosure window is 90 days for critical issues / 30 days for high / immediate for low.

For the customer's own application-level vulnerabilities (a bug in your Python workload that leaks PHI to logs, for example), Nanorix has no insight or remediation path — but we can help you trace which capsule's AuditProof recorded the leaking event. Contact support@nanorix.io.