Database access governance — every query reviewed before it runs

Every query is parsed before it runs

AccessFlow is a full proxy, not a linter bolted onto a client. Nothing reaches the database except through it, and nothing goes through it unparsed. Each submitted statement is turned into a syntax tree first; anything that will not parse is rejected outright rather than passed along and hoped for. From that tree AccessFlow reads the statement type — read, write, or schema change — and the exact set of tables and columns referenced, which is what the schema allow-list is checked against. Matching on the tree rather than on the text is the difference between a rule you can rely on and one that a comment or an alias can walk straight past.

The same treatment covers the engines that are not plain SQL. MongoDB, Couchbase, Redis, Cassandra, ScyllaDB, Elasticsearch, OpenSearch, DynamoDB and Neo4j each bring their own classifier, and so do the cloud warehouses — Snowflake, BigQuery and Databricks — so a document-store command and a warehouse query reach the same checks by a different route. Server-side scripting and the destructive administrative commands are blocked before review rather than after it. Every engine AccessFlow connects to →

What the proxy enforces at execution

Approval decides whether a query runs; these decide what it is allowed to see when it does.

• Row-level security rewrites the query so a user only ever receives the rows they are cleared for, from policies evaluated against their own attributes.
• Dynamic masking hides or partially redacts sensitive columns per person, so the same query returns different results to a support agent and to a DBA.
• Data-classification tags (PII, PCI, PHI, GDPR) attach to columns, derive masking automatically, and raise the risk score of any query that touches them.
• Automated discovery samples column data on a schedule and proposes those tags for you — emails, card numbers, SSNs, IBANs and phone numbers are found by local checksum-verified detectors, optionally aided by your AI analyzer, which only ever sees redacted samples. An admin confirms or dismisses each proposal.

Knowing the cost before approving

A reviewer approving a query they cannot estimate is guessing. Every submission carries a pre-flight cost estimate — the database's own EXPLAIN plan plus an exact affected-row count for updates and deletes — shown alongside the request, folded into the AI analysis, and usable in routing rules such as "escalate any full-scan DELETE over 100k rows". A dry-run preview shows a statement's impact without changing data; on the cloud warehouses it reports the bytes the query would scan, which is the number the bill is based on. Every executed query is kept as an exact snapshot that can be replayed in a test environment afterwards. Datasource, masking & row-security docs →

Risk-scored before a human sees it

An AI analyzer reads every query before it reaches a reviewer and returns a 0–100 risk score, missing-index detection, anti-pattern flags, and concrete fixes offered as a draft edit. The point is not to replace the reviewer — it is to make the queue triageable, so the twenty routine reads are visibly routine and the one unbounded delete is visibly not.

The provider is chosen per organization: Anthropic, OpenAI, Ollama, any OpenAI-compatible backend, or Hugging Face. The system prompt is editable, and a RAG knowledge base lets you feed the analyzer your own house rules so it flags what your team actually cares about. Configurations can be marked as an ordered fallback pool — typically a local Ollama behind a cloud model — so analysis keeps working when the primary provider is unreachable, which is what makes an air-gapped deployment practical.

More than one opinion

Several models can run on the same query, with their verdicts combined by weighted, highest-risk, or majority voting — a fast local model alongside a deep cloud one, for instance — and per-model cost and latency charted so the trade-off is visible rather than assumed. Guardrails block configured prompt patterns before a model is ever called. Text-to-query is opt-in: describe what you want in plain language, and the draft comes back in the database's own dialect, still routed through review like anything else.

Signals beyond the single query

Behavioral anomaly detection learns each user's normal pattern and escalates what falls outside it. Separately, a purely statistical model trained on your team's own past decisions shows reviewers the historical approval likelihood of a pending request. That one is deliberately advisory: it is a triage hint for a busy queue and it never approves or rejects anything. AI analysis docs → Governed access for AI agents →

Who signs off — and what happens when nobody does

A review plan is attached per datasource and says who must approve what. Chains can be multi-stage, reads can be auto-approved while writes are not, decisions can be taken in bulk, and each queue is scoped to the right team by user or by group. One rule holds everywhere and is enforced in the workflow service rather than the UI: nobody approves their own query, regardless of role.

Routing policies sit in front of the plan and decide where a request goes without anyone touching it — auto-approve, auto-reject, escalate, or demand extra approvals, keyed on query type, AI risk, who is asking, time of day, and where the request came from. Standing just-in-time grants can pre-approve queries within their capability and table scope, but they lose to any matching routing policy and are suppressed on high or critical risk, on an open anomaly, and whenever the SQL fails to re-parse.

Reviews that stall

The failure mode of an approval workflow is silence, so both remedies are built in and both are notify-only — waiting never changes who is allowed to approve.

• Out-of-office delegation hands a reviewer's duty to a named colleague for a set window, across queries, API calls and grouped requests. Every decision records both names, a delegate can never act on the delegator's own requests, and delegation never grants a permission the delegate does not already hold.
• Escalation windows and nudge cadences are set per review plan. AccessFlow raises a stalled request to the reviewers it is actually waiting on and to your admins, and reminds them, well before the approval timeout auto-rejects it.

Where reviewers actually decide

Notifications go out over email, Slack, Discord, Telegram, Teams, PagerDuty or webhook. ServiceNow and Jira ticketing opens an incident when a query is rejected, escalated, or times out, and a ticket resolution can sync back as the decision. Reviewers can approve straight from Slack, or with one tap on a mobile push behind a step-up check. While a query waits, the reviewer and the submitter can co-author it live — and any edit re-enters review, so an approval is never inherited by different SQL.

Emergencies

Break-glass exists because the alternative is a shared credential in a password manager. It is gated by a per-user, per-datasource permission that everyone needs including admins; it runs the query immediately, still through the allow-list, masking, row security and row caps; and it pays for that with an instant fan-out to every org admin, a prominent audit entry, and a mandatory retro-review that an admin — never the submitter — must acknowledge. Review workflow docs → Notification docs →

Several steps, one approval

A migration is rarely one statement. A grouped request bundles ordered members — queries across different datasources, calls to governed API connectors, or both — into a single element that is reviewed, approved and executed as a unit. The builder lets you add steps, drag to reorder them, and read a per-step AI risk preview beside an aggregate badge for the whole group.

Bundling never weakens a member's policy. Each member is validated against your permission for its own target, a break-glass group requires the break-glass grant on every target rather than one, the required approvers are the union across all member plans, and the group is approved only when every member's plan is satisfied. You still cannot approve your own group.

One property is worth stating plainly rather than discovering: there is no distributed rollback. On execute, members run in order and the first failure stops the run, skipping the rest — or, if you chose continue-on-error, the remainder still run. Either way an approved group is not atomic, and members that already applied stay applied. The UI says so before you submit. Each member records its own snapshot and audit row alongside the group-level audit and live progress over WebSocket. Grouped request docs →

When data should be retired

Access governance answers who may read a row. It says nothing about whether the row should still exist. Retention and erasure rules close that gap: per datasource, target a table, a column set, or a classification tag, give it a retention window plus arbitrary conditions — a structured, parameter-bound predicate builder, with a parser-validated raw WHERE clause as the escape hatch — and choose an action: hard-delete, soft-delete, or pseudonymize. Rules run on an optional cron schedule through a clustered scan job, with a dry-run preview first and execution through the proxy like any other statement.

A GDPR or CCPA right-to-erasure request takes the same configuration and adds people to it: AI-assisted scope detection proposes what is in range, and the request goes through review-plan-based peer review — reviewer-eligible, multi-stage, no self-approval, auto-rejected on timeout — before anything is removed.

Enforcement is at the proxy and therefore transparent to the caller: soft-deleted rows stop appearing in reads, a DELETE against them becomes a marker update, and aged PII resolves to an irreversible salted hash at read time, so aggregates survive while the personal data does not — pseudonymization is enforced on the way out rather than by a destructive batch write. A completed erasure request writes a tamper-evident proof-of-deletion audit row naming the affected rows, tables and method; a scheduled retention run writes its own execution record. Data lifecycle docs →

Which team is this for

The same checkpoint answers a different question depending on who is standing at it — a platform team removing shared credentials, an on-call engineer who needs production access at 03:00, a DBA drowning in review requests, or a privacy team that has to prove erasure happened. Platform engineering, SRE and on-call, DBAs and data platform, and privacy and data protection each get the long version. For where the credentials live and how the audit chain is built, see the security architecture.