Policies and ABAC

Policies are how Lattix answers the question: given this requester, this data object, and this context, is access allowed? The answer is a cryptographically signed decision that downstream enforcement layers can rely on.

Lattix uses attribute-based access control (ABAC). A policy is a predicate over a set of attributes — about the requester, the data object, and the surrounding context — rather than a static assignment of roles to permissions.

Why not RBAC

Role-based access control expresses access by group membership: "members of the finance team can read financial records." That model captures policies of the form "who is this person." It cannot express policies that depend on what the person is doing right now — the device they're on, their location, whether they're authorized for the specific dataset, whether the action is happening inside an approved window.

ABAC evaluates each request in context. The same principal can be granted access under one set of conditions and denied under another, even seconds later, without any change to role assignments or group memberships.

What a policy evaluates

Lattix policies can reference any of the following attribute categories:

• Principal attributes: identity, organization, roles, clearance level, group memberships, authentication strength, session age.
• Data attributes: classification, tags, owner, origin, retention class, the specific data object's identifier.
• Context: time, geographic location, network zone, device posture signals provided by the identity layer.
• Assertion state: the signed assertions carried on the data envelope (see Trusted Data Format).

A policy is a small expression over these attributes. The evaluator returns a decision, a set of obligations (e.g., watermarking, view-only viewing, logging requirements), and the signed audit record that binds the decision to the request.

Where policies are evaluated

The Policy Decision Plane is the service responsible for policy evaluation. It is tenant-scoped and stateless from the request's perspective: every evaluation consults the current policy set and current attribute state.

Once the decision is made, it is signed and returned to the calling Policy Enforcement Point. Enforcement points verify the signature, check that the decision has not expired, and only then release the wrapped data encryption key.

Decision lifetime and revocation

A signed decision has a bounded lifetime — short enough that revoking a principal's access is effective within minutes, long enough that the enforcement layer does not need to call back for every operation in a short-lived session.

Revocation is handled in two ways:

• Cache invalidation. When a policy or principal attribute changes, cached decisions bound to the old state are invalidated.
• Fail-closed semantics. If the enforcement point cannot reach the decision plane to refresh a decision, access defaults to denial.

Deny policies

Lattix supports explicit deny as well as allow. A deny match overrides any allow, which makes it the correct tool for expressing carve-outs like "no one may access these particular records, regardless of other authorization" — common in legal hold, executive exclusion, or regulatory freeze scenarios.

Policy authoring

Administrators author policies in the Mesh Dashboard. A policy is written as a structured expression, tested against sample principals and data objects before being published, and then versioned. Older versions remain retrievable so that historical audit records can be interpreted against the policy set that was in force at the time.

Staging and review workflows let an organization require a second reviewer before a policy change goes live. This is configurable per tenant.

Relationship to other concepts

• Policy evaluation requires principal attributes from the identity provider — see Configuration → Identity.
• Decisions release keys held by the Key Access Service — see Hierarchical Key Model.
• Every decision produces an entry on the Immutable Ledger — see Immutable Ledger.