Row-level ACL on the graph
Permissions inside the database. Not on top of it.
Most "secure by design" platforms enforce ACLs in the application layer — leaving every direct query path, every reporting tool and every misconfigured admin client as a bypass. Indentia enforces row-level ACL inside IndentiaDB itself. There is no path that doesn't check.
Capabilities
What database-native ACL gives you.
Enforced inside the database
Permissions are not an app-layer afterthought. Every read, every traversal, every join checks ACLs inside IndentiaDB itself. There is no path that bypasses the rules.
Per-row, per-attribute
Grant or deny at the level of an individual record — or an individual attribute of a record. "User can see this customer but not their credit score" is one permission, not a custom field-mask in every query.
ABAC over the ontology
Attribute-Based Access Control evaluated against entity properties (clearance, releasability, jurisdiction, sensitivity) and dynamic context — not just classical RBAC group membership.
Live change subscriptions
Subscribe to permission changes over WebSocket. When access is revoked, every active session sees it within seconds — no "wait for the next page load" gap.
Time-travel aware
Replay a query at any past moment with the permissions that applied then. Forensic and audit teams see exactly what a user could have seen on day X.
Auditable by construction
Every access decision logs the rule that fired, the inputs it evaluated, and the identity that triggered it. The decision log is part of the same knowledge graph.
Zero-trust at the storage layer
The strongest perimeter is no perimeter.
With row-level ACL inside the database, every consumer — a dashboard, an agent, a JDBC client, an admin's curl — is equally untrusted and equally checked. The path of least resistance becomes the path of correct enforcement, which is how a security control survives contact with reality.