// project phoenix · security-domain launch

Technology

Project Phoenix: the security-domain launch of the Ziru Labs trust-layer primitive.

Project Phoenix is the security-domain launch of the Ziru Labs trust-layer primitive. Phoenix is a hardware-rooted AI security substrate that addresses the physical-extraction, bus-level-interception, firmware-compromise, and hardware-enforced-governance threat classes at the hardware layer. Phoenix is additive to silicon-vendor confidential computing and trusted execution environments; it extends the hardware-attested trust boundary below the TEE to cover threats that sit outside the TEE threat model.

// the four architectural layers

Four hardware-rooted layers, composed.

Each layer addresses a distinct class of threat that sits beneath the software trust boundary. Click a layer to open its category-level description.

// Layer I

Foundational Hardware Trust.

Addresses physical-access attack classes against deployed hardware, including cold-boot extraction of AI infrastructure memory, chip-level probing, chassis-level tampering, and supply chain compromise of deployed boards. Phoenix Layer I roots the hardware trust chain in physically-unclonable characteristics of the deployed silicon.

// Layer II

Active Inference Security.

Addresses runtime attack classes against AI inference integrity, including memory-side extraction of model weights and inference data during active computation, and bus-level interception of inference results. Phoenix Layer II binds AI inference execution to hardware-attested cryptographic state such that inference results carry cryptographic evidence of authentic execution.

// Layer III

Structural Network Elimination.

Addresses lateral-traversal attack classes across AI infrastructure, multi-tenant memory-sharing vulnerabilities, and network-level compromise of high-bandwidth AI clusters. Phoenix Layer III eliminates the networked attack surface between AI infrastructure nodes at the architectural level.

// Layer IV

Cognitive Governance.

Addresses AI-behavior attacks that survive software-layer governance, including jailbreaks that bypass safety instructions, compromise of alignment mechanisms through software vulnerabilities, and governance constraints that persist only as software configuration. Phoenix Layer IV establishes hardware-enforced AI governance that persists across software-layer compromise.

// the two tiers

Two tiers, six threat layers.

Tier 2 is anchored to Tier 1. Tier 1 closes the physical, bus, firmware, and kernel threat layers (I–IV); Tier 2 closes the model-and-inference and governance threat layers (V–VI).

// tier 2

Per-Output Reasoning Provenance.

Closes threat layers V (Model and Inference) and VI (Governance).

Mission-Scope FSM Compilation
Enforcement Provenance Tags + Temporal Ordering Attestation
Capability Attestation Bonds
Hardware-Rooted Operator Authority Chain
Manufacturing-Time Authority Template
PUF-Chain Federated Operator Continuity Token
Mechanism Interlock Attestation

// tier 1

Hardware-Rooted Infrastructure Trust.

Closes threat layers I (Physical) through IV (Kernel).

PUF identity, e-fuse-locked digital birth certificate
Hardware-rooted secure boot
Vocabulary-logits FSM (silicon-signed)
Continuous PCIe Zero-Copy verification telemetry
Chunked-prefill TOCTOU closure
Non-routable CXL substrate
Physical interlock, secure override, IOMMU-RDMA isolation

// integration thesis

Additive to existing silicon-vendor security.

Phoenix is designed to compose with, rather than replace, existing silicon-vendor security features. NVIDIA Confidential Computing, AMD SEV-SNP, Intel TDX, and ARM Confidential Compute Architecture provide trusted execution environments within the CPU or GPU. Phoenix extends the hardware-attested trust boundary below these TEEs to cover physical-layer, bus-level, firmware-level, and governance-level threats that sit outside the TEE threat model. The integration thesis is additive: Phoenix makes silicon deployable in customer environments that currently cannot accept the residual risk.

NVIDIA Confidential Computing
AMD SEV-SNP
Intel TDX
ARM CCA

// explicit scoping

What Phoenix does not address.

// out-of-scope.list — Phoenix does not address:

[01] Silicon supply chain compromise at the foundry level.

— Phoenix assumes the silicon vendor's foundational root of trust is intact.

[02] The trusted execution boundary function itself.

— Provided by silicon-vendor TEEs.

[03] Model poisoning or adversarial machine learning inputs.

— Addressed by adversarial-robustness research at the model layer.

[04] Software alignment and AI safety research.

— Establishes the constraints Phoenix enforces at the hardware layer.

[05] Training-data provenance and model watermarking.

— Adjacent domains Phoenix composes with but does not itself provide.

// end-of-list

// ip position

IP position.

Ziru Labs holds 30 inventions covering the trust-layer primitive: 23 dual-use inventions and 7 inventions reserved for defense under distinct disclosure protocols. Provisionals have been filed in waves and remaining drafts are in active prosecution. Utility patent prosecution is active for the core mechanism-level inventions. Briefings on the defense-reserved inventions are available to appropriately cleared counterparties through appropriate channels.

Dual-use: 23 inventions across the four architectural layers
Defense: 7 inventions reserved under distinct disclosure protocols
Coverage: Mechanism-level claims at the category level
Window: 20-year protection extending into the 2040s upon grant

// detailed technical materials

Substantive technical engagement proceeds under mutual non-disclosure agreement.

Counterparties under active NDA with Ziru Labs receive access to the Technology Architecture reference document, the MWP Test Plan, the Threat Model Reference, the Phoenix Block Diagram, and ongoing technical materials relevant to their specific engagement track.

Request NDA pathway