Mesh Node
The endpoint runtime for the Lattix Zero Trust Fabric.
The Mesh Node is the local runtime that participates in the Zero Trust Fabric. It runs wherever protected data is produced, consumed, or enforced — on workstations, servers, sidecars alongside existing applications, or as a service in a data pipeline.
What it does
A Mesh Node performs four functions:
- Wrap. When a local application produces a data object that should be protected, the Mesh Node wraps it in a ZTDF envelope, signs the manifest, and writes the object to local storage or emits it to the application's normal downstream destination.
- Unwrap. When a local application requests a wrapped object, the Mesh Node obtains a signed decision from the configured Policy Decision Plane, requests the wrapped key from the Key Access Service, unwraps the DEK, and returns the cleartext to the application.
- Enforce. Where the node sits in the request path of an application (as a sidecar, for instance), it can refuse to forward a request that does not carry a valid decision.
- Audit. Every wrap, unwrap, and enforcement action emits a ledger event through the fabric.
The Mesh Node is the participant type that most often interacts with application code. A well-deployed fabric has Mesh Nodes wherever wrapped data is created or consumed.
Where it runs
The runtime is deliberately lightweight and cross-platform. It can be deployed as:
- A desktop agent on user workstations (Windows, macOS, Linux).
- A server daemon on application hosts.
- A sidecar container alongside services in orchestrated environments.
- A service process embedded in a data pipeline (batch jobs, streaming ingestion).
All variants speak the same fabric protocol and present the same local API to the applications they support.
Local-first protection
A core design goal is that protection does not require a round-trip to a distant service for every operation. The Mesh Node maintains bounded local caches for recent policy decisions and recent key releases, scoped to the tenant and to the local principal. When cached state is present and fresh, operations are local; when cached state is stale or missing, the node coordinates with the fabric.
Critical invariants are preserved even in the local-first mode:
- Every cache entry has an expiration bounded by the originating decision.
- Revocation events invalidate caches on the next heartbeat.
- An offline node refuses operations that require fresh decisions it does not hold.
Identity on the endpoint
The Mesh Node needs to know which principal to evaluate requests against. It obtains this from the local identity source — the user's logged-in identity on a workstation, a service-account credential on a server, or a workload identity token in an orchestrated environment. These identities are tenant-scoped and federated; the Mesh Node does not store long-lived credentials locally.
When the principal's identity state changes (a role is revoked, a session is ended), the fabric's revocation flow invalidates the node's caches and stops authorizing operations under the old identity.
What the Mesh Node does not do
- It is not a data store. Wrapped objects are held wherever the tenant's storage strategy dictates (local, object storage, a specific cloud bucket). The Mesh Node processes envelopes in transit.
- It does not hold KEKs. Wrapping and unwrapping DEKs requires coordination with the Key Access Service.
- It does not make policy decisions. Those are made by the Policy Decision Plane.
The Mesh Node is the glue: the thing that makes wrapping and unwrapping feel like a local operation to the applications that use it, while keeping the actual security decisions in the hands of the tenant's policy and key infrastructure.
Relationship to concepts
- The Mesh Node is a participant in the Zero Trust Fabric.
- It handles the ZTDF envelope on behalf of local applications.
- Unwrap operations go through the hierarchical key model.
- Operations produce ledger events.