Authentication, roles and permissions, at every level.

Nobody gets the authorisation check wrong on an entity's main endpoint: it's the first thing anyone thinks of and the first thing reviewed.

Incidents happen elsewhere, and almost always in the same places: an export added in a hurry, a global search function written for internal support and later exposed, a report aggregating data while skipping the filter, an interface created for an integration and never reviewed with the same care. The code works: it does what it says, and what it says is incomplete.

When permissions are declared on the domain rather than written into the paths, those paths have no way of being incomplete: they pass through the same authorisation engine as the main screens. It isn't a guarantee against every possible mistake — a badly declared permission stays badly declared — but it shifts the risk from "someone forgot" to "someone declared the wrong rule", which is far easier to find because it's written in a document you can read.

Who can get in. Token authentication, lockout policies after failed attempts, secure credential handling, two-factor where needed. It's the level everyone implements and rarely the weak point.

Which records they can see. Conditional ownership rules resolve questions like "only their own", "only their organisation's", "only those in a given state" at runtime. This is the level that protects against the costliest incident, where a user sees someone else's data.

Which fields of that record. Granularity at single-attribute level, per role and per operation: a field can be visible but not editable, or invisible entirely to certain roles. It's the level that traditional systems implement screen by screen and that therefore diverges most easily.

The property that matters is that all three hold on every path: screens, searches, exports, exposed interfaces and plans compiled by an AI agent all pass through the same engine.

A declarative application layer solves data and operation security. It doesn't solve, and shouldn't claim to solve, everything else.

• Infrastructure security: network segmentation, perimeter protection, administrative access management and operating system patching remain the responsibility of whoever operates the environment, with the tools they already use.
• Secret management: credentials for external systems belong in your environment's dedicated tooling, not in the domain configuration files.
• Independent security testing: a penetration test before go-live is good practice that no architectural property replaces, and it's also the most direct way to verify the claims on this page.
• Data protection obligations: the declarative configuration assists with the record of processing and impact assessment, but the obligations remain yours as controller.