Limpopo Guardian Engine

Access is determined by context, not by the screen

Limpopo Guardian Engine is a universal context-aware security layer. It turns complex relationships between users, data and objects into a single, manageable access model. Each decision depends on who is accessing the object, what action they perform and in what context, and the rules are enforced at the data level, independently of the application interface.

Access check · context
subject: designer_ivanov
action: READ
object: document · ABVG.303111.001 SB
context: organization DB-1 · project R-160 · group "Designers"
→ allowed: role "designer" in project R-160
11:20:12 contractor_petrov READ → denied: object not published to the contractor
11:20:44 designer_ivanov UPDATE → allowed: object owner
How it works

One access model for every application

01
Context-based access

The system answers one question: may this user perform this action on this object in this context? It considers not only who does what, but also under which conditions.

02
What makes up the context

Organization, project or scope, group, role and the scope of that role, object publication, ownership, delegated access, object type and the specific action.

03
Relationships instead of attributes

Access is determined not by a single property of the user or the object, but by their relationships and the current context of the interaction.

04
Rules separate from the interface

The decision is made for the requested object and context, not for the open screen. Rules are not hard-coded into application business logic.

05
Domain-independent

Guardian is not tied to any one domain. The same mechanism controls access to documents and projects in PLM, to knowledge chunks and sources in RAG, and to customer data in SaaS.

06
Enforcement at the data level

Policies are enforced with PostgreSQL Row-Level Security. Different applications and services rely on one access model and do not duplicate it.

What you get
  • Access follows the data: a user is granted a scope of data, not a set of screens
  • A single enforcement point: applications do not need to repeat the same checks
  • Context instead of exceptions: organization, project, group, role, ownership
  • Traceable denials: you can see which condition of the model was not met
  • The model grows, not the number of rules: new objects and applications change the state of the model, not the checks in every interface
Limitations
  • Requires PostgreSQL: policies are enforced with Row-Level Security
  • Guardian controls access to data rows; encryption of files, storage and individual fields is a separate layer of protection

Let's review the access model in your systems

We consult on users, objects and access contexts in your applications. Limpopo Guardian Engine is preparing for launch, and you can already discuss how to build a single access model for your data.

We will reply to the email you provide