ENCLAVE

A secure Android ecosystem — v 2026.05

— build manifest

A phone built for
people who cannot
afford to be wrong.

ENCLAVE is a hardened Android distribution running on attested hardware. Verified boot, no Google services, sandboxed execution, and a first-party application stack — assembled for principals whose threat model is not theoretical.

Request access →
01 / Hardware-rooted trust 02 / On-device intelligence 03 / No telemetry page 01 / 09

§ 02 — the case

posture / default state

The modern smartphone is the most compromised device its owner will ever carry.

It speaks continuously to servers its owner does not control. It runs code its owner cannot audit. It ships with vendor services that assume trust the owner has not granted. For a small set of principals — heads of state, founders under threat, counsel handling sealed matter, journalists with sources to protect — it is not. ENCLAVE is the device that refuses that bargain by construction, not by configuration.

Google services
removed
Telemetry endpoints
blocked
Bootloader
locked / verified / attested
User data
on-device only
Network
outbound deny by default
App execution
sandboxed, signed

§ 03 — ecosystem at a glance

read top-down. each layer inherits the trust of the one above.

Four layers.
Each one accountable to the one above.

Hover or focus a layer. Each step in the stack is signed, measured, and constrained. Nothing is implicit.

  • L4NetworkOutbound default-deny. Per-app egress rules.egress denied by default

    All app traffic is mediated by a per-process firewall. DNS is performed over authenticated channels. No silent endpoint outside the user's declared allowlist may be reached.

Each layer attests the layer above. Failure isolates downward — figure 03 — architecture

§ 04 — the os

five guarantees

What the operating system does,
and what it refuses to do.

  1. 01 / Verified boot

    The device refuses to start if anything between firmware and userspace has been altered.

    Boot stages cryptographically attest the next. The chain terminates in a hardware key fused at manufacture. A failed measurement halts boot — there is no "continue anyway" path.

  2. 02 / Hardware attestation

    A remote party can verify the device is genuine and unmodified — before exchanging anything sensitive.

    Attestation statements are signed by a key the user cannot extract. The state of the bootloader, OS image, and patch level are exposed to your counterparty on demand — without exposing identity.

  3. 03 / Sandboxed execution

    Every application runs in its own confined process — including ours.

    Capability-based mediation. Filesystem, network, sensors, and IPC are gated per app and revocable. A compromise of one application cannot escalate into a compromise of the device.

  4. 04 / No Google services

    No Play Services. No Firebase. No silent connections to a vendor cloud.

    Push, location, identity, and crash reporting are replaced with first-party equivalents that route through user-controlled infrastructure. The device does not phone home to a party you did not choose.

  5. 05 / First-party stack

    Messaging, browser, vault, contacts, calendar — built and audited together.

    A small, coherent application set ships with the device. Each component is reviewable, replaceable, and accountable to the same threat model. End-to-end encryption is the default, not a setting.

§ 05 — honest disclosure

— limits of the product

Read this section before purchase.

Disclosure — scope

What we do not claim.

ENCLAVE does not protect against an adversary who can physically coerce you to unlock the device. It does not protect against a compromised counterparty — if the person on the other end of the conversation is hostile, encryption does not save you.

ENCLAVE cannot save a user who chooses to install untrusted code, disable verification, or hand the device to someone who should not have it. We assume an attentive operator. We do not promise omniscience; we promise a defensible posture and the documentation to defend it.

If your threat model includes signals intelligence at scale, this device is one component of a posture — not the posture itself.

§ 06 — proof shelf

where the evidence lives

Where the evidence lives. Or honestly, where it is still being assembled.

audit

Trail of Bits

Scope: boot chain & attestation key handling. Engagement scheduled Q3 2026. Public report to follow under coordinated disclosure.

status · scheduled

team

Eight engineers, six disciplines

Former AOSP, kernel hardening, secure element firmware, and applied cryptography. Names available under NDA to qualified buyers.

status · composed

threat model

Published, versioned

What we defend against, what we do not, and how the boundary moves over time. Maintained alongside the codebase, never marketing.

status · v 2026.05

open source

OS, apps, attestation tools

Source published on GitHub. Reproducible builds. The firmware blob that remains under vendor NDA is documented with its hash and capability surface.

status · partial / public

All proof artifacts referenced above are linkable on request. Empty slots are honest. — updated 2026.05.22

§ 07 — access posture

intake process

Available by request.

Onboarding includes a security briefing, threat-model intake, and on-site or escorted device provisioning. We do not sell at retail. We sell to principals who can articulate why they need this device — and to the institutions that protect them.

Begin a conversation →
  1. 01 introduction & references
  2. 02 threat-model briefing
  3. 03 provisioning & training
  4. 04 ongoing attestation channel

Pricing communicated post-intake. We answer in 72 hours.