Demesne
The authorisation engine Fóir runs on. Access rules are written once, in one spec file, and Demesne compiles them into Postgres row-level security, so the database applies them to every query. We built it for Fóir and published it under the Apache 2.0 licence.
What it does
A Demesne spec describes four things: the shape of your tenancy, the kinds of user and credential that act, the tables they act on, and the relations that connect them, such as ownership, roles, sharing and group membership.
From that file the compiler generates the row-level security policies and the database functions those policies call. It also generates a permission map for Go and TypeScript, for the questions that are not about rows ("may this user publish?"), and the claims a session has to carry. Change the spec and regenerate, and the database and the application code move together.
Why the rules live in the database
Authorisation usually sits in application code: a service you call, or checks spread across request handlers. Either way it protects only the paths that remember to ask. A background job, a new endpoint or a query typed into a database console goes round it.
Demesne puts the decision on the data. The same policy filters every query, whichever code sent it, so a path that forgets to check gets back only the rows its caller was allowed to see.
Why we wrote a compiler
Row-level security is the right place for a rule and an awkward thing to write by hand. A multi-tenant product needs ownership, roles, nested groups and sharing, repeated across every table, and those patterns are easy to get subtly wrong.
The engines that share Demesne's model, Google's Zanzibar and the open-source projects that follow it, run as a separate service. Your application has to call that service for each decision and keep its copy of the relationships in step with your data. We wanted the model without the service, so Demesne's rules read your existing tables in the same transaction as the query.
How its output is checked
Demesne's build compares every generated file byte for byte against a committed copy. Each permission check on the application side carries the matching policy's condition verbatim, so the code cannot drift from the database without failing the build. Run against a real Postgres, the test suite installs the generated functions and confirms that the SQL agrees with the Go and TypeScript versions case by case.
For a database that is already deployed, demesne diff reports any difference between the spec and the policies that are live.
Why it is open source
The component that decides who can read your data is the one you should be able to inspect. Any platform can say that its tenants are isolated. With Demesne you can read the compiler that writes our policies, the tests it has to pass and the SQL it produces, and you can run all of it yourself.
Nothing in Demesne is specific to Fóir. It works with any Postgres database and reads the session your own sign-in provider issues, and the repository's guide walks through adopting it on an existing schema. A team with no interest in our platform can use it, which is the best check we know of on whether the model holds up.
What it means on Fóir
Fóir's access model is one Demesne spec, which at the time of writing governs about a hundred tables. A test lists every table in our schema and fails on any that was added without a recorded decision about how it is protected.
The rules you set for your own project, such as who owns a record and which roles may read a model, are data those policies read, so they take effect inside the database as well. Enforced in the database describes how the policies are generated, forced and tested.
It leaves with you
A Postgres export of your project includes row-level security policies that reproduce which rows each of your users could read, ready for you to apply to the database you now own. If you want the whole model on your own infrastructure, the engine is there to use under a licence that allows it.
Where it is the wrong tool
Demesne is Postgres only. It is a library and a command-line tool, with no hosted service to call. Every rule has to be expressible as a SQL condition, and questions that run the other way ("who can see this record?") are answered conservatively. The repository carries a comparison with Zanzibar, Ory Keto, OpenFGA, Cerbos and Oso that says where each of them is the better choice.
Read it for yourself
The spec language, the generated SQL and the test suite are all in the repository.