The governance pitch for a semantic layer is that you define row filters and column masks once, on the model, instead of re-implementing them in every source. It is a good pitch, and it has a gap: it assumes someone notices when the shape of the data changes. When an upstream team adds an email address, a national identifier, or a date of birth to a table you already model, nothing announces it. The policy you wrote last quarter silently stops covering everything it should.
This loop watches for exactly that. It scans the dimensions of modelled entities for fields whose names and types suggest sensitivity, and for each candidate proposes a column-scoped deny policy attached to the right entity — arriving inactive, as a draft awaiting review.
The restriction to proposing is absolute here, and it is the most important design decision in the whole autonomous story. An agent that could activate a deny policy on its own could break every dashboard and query that legitimately depends on a column — an outage delivered by robot. An agent that could deactivate one could expose data that policy existed to protect — a breach delivered the same way. Neither is an acceptable risk to trade for convenience, so the design keeps policy activation exclusively human and treats any code path that would let an agent flip it as a bug.
What the loop is really buying is latency. A governance lead who currently learns about a new sensitive column during an audit would instead get a specific, pre-drafted, one-click-to-review proposal close to when it appeared. The judgement stays with the person accountable for it; only the noticing is automated.
Proposals land in the same policy model a person uses — column, row, and entity scopes with allow and deny effects, attachable to a model or an entity and individually toggleable — so reviewing one is the same act as writing one.
Illustrative scenario — not a record of a real deployment or a customer result.
Ready to make this your story?
