Zero Trust Fabric

The Zero Trust Fabric is how Lattix's components talk to each other. It is a coordinated mesh of nodes that together decide, enforce, and record every access to protected data. It is deliberately decentralized: there is no single gateway every request has to pass through, no shared database that must be reachable for the system to function, and no assumption that participants trust each other's networks.

Fabric participants

A fabric deployment is made up of four participant types:

• Mesh Nodes run on endpoints where protected data is produced, consumed, or enforced. They are the local runtime for Lattix — wrapping outgoing objects, verifying incoming ones, and applying enforcement in place.
• Policy Decision Points (PDPs) evaluate policies. A tenant can run one or several; requests are routed to whichever is reachable and authorized for the tenant.
• Policy Enforcement Points (PEPs) sit in the request path of a data-consuming application. They require a signed decision before data flows downstream. The PEP is usually deployed as a sidecar to existing services.
• Key Access Services (KASes) hold wrapped keys and release them on positive decisions. Different tenants can run different KASes, and a single tenant can run multiple KASes in different regions for latency or residency reasons.

These participants discover and authenticate to each other over a zero-trust mesh network.

How participants find each other

Participants bootstrap into the mesh using short-lived enrollment tokens issued by the tenant's administrative plane. Once enrolled, they advertise themselves in a tenant-scoped service registry with a TTL — if a participant goes offline, its registration expires and requests stop being routed to it.

All participant-to-participant traffic uses mutual TLS. A participant proves its identity with a tenant-scoped certificate; the other end verifies that the certificate is valid for the requested role and has not been revoked. A compromised participant can be revoked at the tenant level and is effectively removed from the mesh on the next handshake.

No shared infrastructure requirement

A coalition or multi-organization fabric can span entirely different cloud providers, identity systems, and networks. What participants share is:

• The Trusted Data Format envelope (which carries policy by reference, not by value).
• The decision format (the signed structure that PEPs and KASes verify).
• The ledger schema (the envelope of audit records each participant writes).

They do not need to share a database, a message bus, or a specific cloud provider. The fabric is intentionally composable.

Fail-closed semantics

Every participant defaults to denial when something is wrong:

• If a PEP cannot reach a PDP to refresh a decision, access is denied.
• If a KAS cannot verify a decision signature, the wrapped DEK is not released.
• If a Mesh Node cannot reach its KAS at unwrap time, the object remains ciphertext.

This is the opposite of most enterprise systems, which fail open ("allow by default if the gate is unreachable"). Lattix's security posture requires that access be actively authorized at the moment of use.

Local caches

A strict fail-closed system with no caching would be operationally painful. The fabric uses bounded local caches for:

• Recent positive decisions (bounded to the decision's own lifetime).
• Recent wrapped-key releases (bounded to the session's validity).
• Policy snapshots (bounded to a short TTL or until revocation invalidates them).

Caches are local to the enforcing node, never shared across tenants, and are invalidated on revocation events. The effect is that steady-state operations are fast, while revocations propagate within minutes.

Relationship to other concepts

• The Trusted Data Format is the envelope carried over the fabric.
• Policies and ABAC are evaluated by the PDP participants.
• The Hierarchical Key Model is the mechanism KAS participants use to gate cryptographic unwrapping.
• Every fabric decision is recorded on the Immutable Ledger.