The Access-Request Workflow Is Where Governance Goes to Feel Busy

Be fair to the pattern before dismantling it. The request-approve-provision workflow replaced something genuinely worse: emailed spreadsheets, tickets routed to whichever administrator happened to hold the keys, and tribal knowledge about who to ask. The marketplace framing the category built on top of it — browse a searchable, business-glossaried inventory of the estate, request a dataset with a stated purpose, have policy applied at the moment of grant — was a real improvement, and it earned its adoption. Discovery was a hard problem and the modern catalogs genuinely solved it; classification and sensitivity labeling at estate scale is real work, honestly done.

And the strongest tools in the category go a step further than paperwork: they enforce access policy at query time — attribute-based control, row- and column-level security, dynamic masking — with every query authorized and logged inside the platforms they front. That is enforcement, not advice, and it deserves to be named as such. We will come back to it.

So the critique here is not that approval is wrong. Approval is how human accountability enters the system, and it should. The critique is that approval-then-provision is the wrong shape — because of what happens in the long silence after the grant.

Trace the mechanics past the demo. The request captures rich context: who is asking, for which data, for what purpose, sometimes for how long. The approval evaluates that context — once, on the day it is made, against the org chart and the project list as they stand that morning. Then the final step: the workflow reaches into another system — a warehouse role, a group membership, a share — and provisions a standing grant.

And there the governance ends. The suite that recorded the promise stops watching; the platform that now holds the grant never knew the promise existed. The grant carries no purpose clause it can enforce, no live link to the role that justified it, no mechanism that notices when the justification dies. The two halves of the control are stored in different systems that nothing reconciles continuously: the reason lives in the governance suite, the power lives in the platform.

The marketplace framing is quietly honest about this: policy is applied at checkout. The checkout is governed. The eleven months after checkout are not.

Every standing grant is a bet that yesterday's context still holds tomorrow. Enterprises lose that bet constantly, in ways every CDO and CISO who co-own access risk can enumerate from memory:

• Role changes. The analyst whose access was justified by fraud investigation moves to marketing. The identity system knows the same day. The grant does not — it was cut for a person, and the person is still there.
• Purpose drift. Access approved for one model, one project, one quarter works equally well for anything else, indefinitely. The purpose was evaluated exactly once, on the day it was stated, and never again.
• Orphaned access. The contractor offboarded from the directory but not from the share. The service account whose owning project ended two reorgs ago. Grants with no living requester at all.

Notice the direction of drift: it is one-way. Access is granted at the speed of a workflow and revoked at the speed of an audit, so standing entitlements accumulate monotonically between reviews. The uncomfortable question for the executives who co-own this risk: of the entitlements active in your estate right now, what fraction could you tie — today, without a project — to a business purpose that is still true? Not the purpose stated at request time. A purpose that is still true.

The quarterly access review exists because everyone already knows the answer to that question. It is worth saying plainly what recertification is: a compensating control for a missing primitive. Because entitlement is not evaluated at the moment of use, the enterprise must periodically excavate who-still-has-what and ask managers to re-approve decisions whose original context they no longer remember — hundreds of line items, certified in an afternoon, because the alternative is blocking colleagues whose access is probably fine.

That is not a control operating. That is archaeology, performed on schedule, over grants once given. A control that must be re-confirmed every quarter is a control that was not running in between — the ritual is not evidence that access is governed; it is the clearest available evidence that, between reviews, it is not.

Now the strongest version of the pattern, stated fairly. The query-time access-control architecture — policy evaluated inside the data platforms they front, on every query, with attribute-based decisions, dynamic masking, and a log entry per authorization — genuinely closes much of the staleness gap within its zone. Change the attribute and the very next query is decided differently. It is the one architecture in this category where policy is enforcement rather than advice, and inside its perimeter it is the very model this essay argues for.

But the zone has walls, and they are structural, not roadmap items. It governs the data read, at the door of the platforms it integrates with. The moment data crosses that threshold — a BI extract, an application cache, a file export, an agent's context window — the enforcement zone ends and the copy lives on, ungoverned by the policy that authorized its birth. And one thing was never inside the zone at all: the business action the data exists to drive. Posting the journal entry, approving the loan, changing the customer record, releasing the payment — the read was authorized; the act it powered executes in some other system, out of scope by construction. Governing the read while the act runs elsewhere is better than governing neither. It is still governing one verb, in some rooms.

An enterprise does not need a better approval queue. It needs entitlement checked at the moment of each action — where the approval is the live policy and there is no provisioned artifact left behind to drift.

This is the architectural difference Entroid is built around. On the Composable Process Fabric, the Semantic Ontology is not a catalog standing beside the data; it is the governed model the runtime executes on. Policy — classification, entitlement, residency, quality — is part of that model, and every process runs through Deterministic Workflows on the same runtime. So each data action a process takes — the read, the write, and the business act it drives — is authorized inline, at execution, against the live policy object: this role, this purpose, this residency constraint, now. Follow what that shape eliminates:

• No standing grant, no drift. Nothing is provisioned into a downstream system, so there is nothing to go stale when the role changes or the project ends. The next action is simply evaluated against the current policy state.
• Revocation is a policy edit. It takes effect at the next action, everywhere on the fabric — no claw-back campaign across a dozen platforms, no window in which the departed contractor's access still works.
• Recertification collapses into a query. Every authorization decision lands in the immutable per-action audit as a byproduct of execution. The access review stops being archaeology over grants once given and becomes a readout of decisions actually made — who acted, on what, under which policy, when.
• The existing estate passes the same gate. ES does not ask you to abandon your platforms — Connectors are the only primitive that touches external systems, so every reach into the warehouse, the ERP, or the file store is itself a governed, audited action rather than a standing credential parked in an integration.

Where a human approval genuinely matters — sensitive data, exceptional purpose — it does not disappear; it moves. Human-in-the-loop review is a first-class step in a Deterministic Workflow, so the decision becomes part of the policy state the very next action is checked against, scoped and expiring by design, instead of a ceremony that fires once and is thereafter remembered only by the audit team. These are properties of the architecture — one runtime, one gate, one audit for the read, the write, and the act — which is precisely why they can be stated without a case study attached.