Platform Overview

A short orientation to Lattix — a distributed management plane, a decentralized data plane, and protected objects that carry their own encryption and policy.

Lattix protects data by combining a distributed management plane, a decentralized data plane, and protected objects that carry their own encryption and policy bindings.

The platform works in three parts:

  • Management services define identity, policy, key access, and evidence.
  • Mesh nodes distribute policy and enforce it locally.
  • Protected objects remain sealed until an authorized unwrap.

Each of the diagrams below tells one part of that story. The five capability layers at the end name the cross-cutting terms the rest of the documentation refers back to.

Platform at a glance

Platform at a glance: a management plane containing identity, policy administration, KAS, and evidence services; a data plane of mesh nodes enforcing policy locally; and a protected object containing ciphertext, a wrapped key, and a policy binding travelling between a producer and a consumer./ PLATFORM AT A GLANCEMANAGEMENT PLANEdistributed microservices · replicated state · no single controllerIDENTITYOIDC · SAML · mTLSPOLICY ADMINPAP · PDP runtimeKASfederated key accessEVIDENCEimmutable ledgerpolicies publishedevidence recordedPRODUCERwrapsPROTECTED OBJECT◆ CIPHERTEXT◆ WRAPPED KEY◆ POLICY BINDINGsealed without authorized unwrap · travels with the dataCONSUMERunwrapsaccess enforced locallypolicies replicatedDATA PLANElibp2p mesh · embedded PDP on every node · local enforcementMESH NODEPEP · PDP · libp2pMESH NODEPEP · PDP · libp2pMESH NODEPEP · PDP · libp2pMESH NODEPEP · PDP · libp2p

Two planes coordinate; protected objects travel between them. The management plane is where identity providers are wired in, policies are authored, keys are mediated, and evidence is recorded. The data plane is where those policies are replicated and enforced at the node where the request actually happens. The next three diagrams expand the parts that need more detail.

Protected object model

Protected object model: a producer wraps a data object in a TDF envelope containing ciphertext, wrapped DEK, policy binding, integrity metadata, and audit linkage; the consumer unwraps only on authorized access./ PROTECTED OBJECT MODELPRODUCERWRAPSclassifies · signsTDF ENVELOPEpersistent asset · travels with the data◆ CIPHERTEXTAEAD-encrypted payload◆ WRAPPED DEKDEK encrypted under KEK◆ POLICY BINDINGsigned policy reference + attributes◆ INTEGRITYauthenticated manifest · signed assertions◆ AUDIT LINKAGEcontent ID + ledger referenceCONSUMERUNWRAPSon authorizedaccess onlyENCRYPTION IS A PROPERTY OF THE OBJECT · NOT A STAGE IN A PIPELINEProtection travels with the data across clouds, endpoints, partners, and backups — revocation after the fact remains effective.

Traditional security architectures protect the container around the data: the server, the network segment, the application. When the data leaves that container, its protection ends. Lattix inverts the model — the envelope travels with the data and every unwrap requires a fresh, policy-authorized key release. Protection applies the same way in your cloud, in a partner's cloud, on a laptop, on a USB drive, or in an email — and revocation remains effective against copies you no longer control.

Authorized unwrap flow

Authorized unwrap flow: consumer presents identity, local PEP receives the request, embedded PDP evaluates against the local policy replica, KAS mediates authorized KEK use, DEK is released for local decrypt, and a signed evidence event is written to the immutable ledger. Any broken step causes fail-closed denial; the object remains sealed and a denied-access event is still recorded./ AUTHORIZED UNWRAP FLOWhow a consumer opens a protected object — fail-closed at every step/01IDENTITYconsumer presentstoken · attributes/02PEPlocal gatein request path/03PDPembeddedevaluates locally/04KASmediates KEKreleases DEK/05DECRYPTlocal toconsumer/06EVIDENCEsigned eventimmutable ledgerany deny at any stepDENIED · FAIL-CLOSEDobject remains sealed · denied-accessevent still written to the ledgerFAIL TRIGGERS · MISSING POLICY · EXPIRED DECISION · REVOKED KEY · STALE REPLICA · UNREACHABLE KAS

Evidence is generated throughout, not just at the end: policy publication, replica updates, access requests, key releases, and revocations all land on the immutable ledger. Denials produce records too, so the absence of a record really does prove an access did not occur.

How policy reaches every node

Distributed policy distribution: policies are authored in the PAP in the management plane, signed and versioned, replicated across management services, and then propagated via libp2p to every mesh node where the embedded PDP evaluates them locally./ DISTRIBUTED POLICY DISTRIBUTIONauthored once · propagated over the mesh · evaluated locally everywherePAPpolicy administrationdraft · review · version · publishSIGN · PUBLISHversioned bundlesMGMT SERVICE Areplicated policy statePDP · KAS · evidencelibp2p peerMGMT SERVICE Breplicated policy statePDP · KAS · evidencelibp2p peerMGMT SERVICE Creplicated policy statePDP · KAS · evidencelibp2p peerSYNCSYNCLIBP2P PROPAGATIONsigned deltas · mesh-wideMESH NODEpolicy replica · cacheembedded PDPevaluates locallyMESH NODEpolicy replica · cacheembedded PDPevaluates locallyMESH NODEpolicy replica · cacheembedded PDPevaluates locallyMESH NODEpolicy replica · cacheembedded PDPevaluates locallyPEER-TO-PEER PROPAGATION CONTINUES LATERALLY · CONVERGES WITHOUT CENTRAL DEPENDENCY

Policy is authored once in the management plane and ends up evaluated on every node that needs it, without any node depending on a central evaluator at request time. Revocations and trust updates propagate the same way, so a change at the PAP reaches the enforcing edge within minutes rather than requiring a push-to-every-endpoint step.

The five capability layers

The five capabilities below are not sequential stages — they are cross-cutting layers that appear throughout the diagrams above. They are listed here so the rest of the documentation has stable terms to refer back to.

  • /01 Identity and Trust — OIDC, SAML, SPIFFE, mTLS, node identity, attestation. Principals become attribute sets; participants prove themselves with tenant-scoped certificates.
  • /02 Policy Authoring and Distribution — PAP for authoring; a common PDP runtime evaluates in both planes; signed policy bundles propagate over the libp2p mesh.
  • /03 Protected Object — the TDF envelope itself: ciphertext, wrapped DEK, policy binding, integrity metadata, audit linkage. Persistent, not transient.
  • /04 Local Enforcement and Key Access — PEP at the workload, embedded PDP at the node, KAS-mediated unwrap that keeps the KEK inside the trusted key service boundary.
  • /05 Evidence and Convergence — immutable ledger, tamper-evident events, revocation sync, policy-version convergence across both planes.

The rest of this documentation

The remaining sections take each capability in turn:

  • Core Concepts — the primitives: Trusted Data Format, ABAC, the hierarchical key model, the mesh fabric, the immutable ledger, content addressing, and post-quantum encryption.
  • Products — the products that expose these primitives to users: Lattix Passport, Data Rooms, the Zero Trust Fabric, the Mesh Node, the Immutable Ledger, connectors, and the Policy Engine.
  • Configuration — the administrative controls a tenant administrator configures.
  • Best Practices — recommendations for rolling this out successfully.

Welcome

The Lattix documentation — architecture, concepts, products, and configuration for the data-centric security platform.

Core Concepts

The primitives that appear throughout the Lattix platform — ZTDF, ABAC, the hierarchical key model, the mesh fabric, and the immutable ledger.

On this page

Platform at a glanceProtected object modelAuthorized unwrap flowHow policy reaches every nodeThe five capability layersThe rest of this documentation