In-engine enforcement
The strongest architectural claim in the data plane is a plain one: enforcement lives inside the engine. Row filters compile into the plan as predicates; column masks compile in as projections. A query returns exactly the rows and columns the caller is entitled to, and there is no second path that returns more.
Why in-engine matters
A platform that mediates policy through a separate catalog or proxy has a gap: a caller who reaches the engine directly gets ungoverned data. Pushing enforcement into execution closes that gap by construction, the control is part of the query, so choosing a different door does not change the answer. This is the platform's clearest data-plane differentiator, and it is a claim about mechanism, not a certification.
What the enforcement plane covers
| Control | How it works |
|---|---|
| Row-level security | Predicate pushdown limits which rows a caller sees, evaluated in the engine. |
| Column masking | Projection pushdown redacts or transforms sensitive columns in the plan. |
| Tag policy and grants | Policy over tags and classifications, and grants: including agent grants, so an agent reads as a scoped, attenuated citizen of the data. |
| User-defined functions as masks | A customer can author a function, publish it along a visibility ladder, and bind it as a column mask, with a tiered sandbox and invocation metering. |
Above the data-security plane, a capability-control plane decides whether a workspace may even hold a given capability, by licence tier, export control, classification, and role, with human-in-the-loop approval and agent attenuation on the action guard. See Security governance for the deny-closed action boundary this connects to.
The policy plane: one policy, every engine
Row-level security and column masking are compiled once and pushed into each engine as native predicates and projections, rather than applied by a catalog service that a caller could sidestep by reaching an engine another way. One policy becomes native enforcement in seven engine types, and the PostgreSQL wire and Redis-protocol servers re-enter the same authorizer, the wire is not a bypass.
Figure C2: the policy plane. One policy is compiled once (green) into engine-native predicates and projections and enforced at a single engine-boundary authorizer with DENY precedence, which pushes it into all seven engine types. The two external wire servers (dashed edges) do not get their own copy of the policy, they re-enter the same authorizer, deny-by-default before authentication, so the wire is not a bypass. This holds identically single-cell and multi-cell, sovereign and cloud.
Table equivalent
| Element | Role | State (meaning) |
|---|---|---|
| One data-security policy | The single source of row filters and column masks | neutral |
| Compiled once → predicates & projections | Turned into engine-native filters, not a wrapper | verified (green) |
| Engine-boundary authorizer | Single decision point; DENY precedence, deny-by-default | verified (green) |
| SQL/analytical, graph, document, key-value, search, stream, vector | The seven engine types the one policy is pushed into | neutral |
| PostgreSQL wire server | Re-enters the same authorizer: not a bypass | neutral (dashed edge) |
| Redis-protocol server | Deny-by-default before authentication; re-enters the same authorizer | neutral (dashed edge) |
The evaluation pipeline, and DENY precedence
A single pipeline turns a request into a governed result. Policies resolve with DENY precedence (where grants conflict, the deny wins) and masking is the last step, redacting whatever the predicates left behind.
Figure C3: the data-security evaluation pipeline. The request builds a security context, the evaluator resolves policies with DENY precedence, the predicate compiler emits engine-native filters, the engine adapter enforces them in the plan, and the mask applicator redacts what remains before the governed result is returned. Enforcement is a mechanism, not a certification, nothing here is graded or hardened.
Table equivalent
| Step | Stage | What it does |
|---|---|---|
| 1 | Middleware | Builds a security context from the request |
| 2 | Orchestrator | Coordinates evaluation |
| 3 | Evaluator | Resolves policies with DENY precedence |
| 4 | Predicate compiler | Emits engine-native filters (predicates + projections) |
| 5 | Engine adapter | Enforces the filters inside the query plan |
| 6 | Mask applicator | Redacts what remains, using one of ten masking strategies |
The ten masking strategies available to step 6: null · redact · full ·
partial · hash · noise · range bucket · format-preserving encryption ·
tokenise · custom. Masking is tag-driven, tag a column as personal data and
the mask applies across every engine, and predicate protection blocks or
rewrites queries that reference a masked column in a filter or ordering, so a
mask cannot be defeated by side-channel inference.
Honesty about coverage
In-engine row- and column-level enforcement is the strong claim here, as a design and as a mechanism.
This page is about row- and column-level enforcement compiled into the query plan. Adjacent capabilities have their own maturity and their own pages: data-loss prevention at rest, insider-threat and user-behaviour analytics, and the deeper key-custody options such as TPM-sealed keys, per-compartment cryptographic isolation and auto-zeroize on disconnect are on the roadmap. Scope an evaluation of in-engine enforcement to in-engine enforcement.
Nothing here is graded, hardened, or certified, these pages describe how the enforcement is built, not a proven outcome.
Across the deployment matrix
- Single-cell and multi-cell: enforcement is compiled by the local engine, so a cross-cell query is governed like a local one.
- Sovereign / air-gapped: no external policy service is required; the engine on the box enforces the policy.
- Cloud-enabled: identical behavior; external tools connect over open interfaces and still read only what they are entitled to.