AccessFlow changelog — every release, newest first

v2.7.0 — Identities for machines, finer data-access controls, and governed schema changes

Released 1 October 2026 · Release on GitHub

• Governed schema changes. Write a set of schema statements once, under a deployment pipeline, and promote it environment by environment — development, then staging, then production. An environment only ever receives a change that already applied cleanly in every environment below it. Each statement is parsed for the target database's dialect before it can be saved: data reads and writes are refused, and a blocking SQL review rule refuses the save. The statement list locks the moment it is first promoted — unlocking only if every promotion failed or was cancelled — so "applied to staging" still means the same text when production is asked. Promoting needs the right to change that database's structure for everyone, admins included, is refused inside a freeze window, and goes through the same review as any other request. There is no automatic rollback — a failure part-way leaves the environment marked partially applied, and a new change set is the remedy. An opt-in scheduled scan compares each environment's tables, columns and foreign keys with where they should be and reports drift for an admin to acknowledge; it never changes anything.
• Service accounts for pipelines and agents. CI jobs, Terraform runs and AI agents get identities of their own instead of borrowing a person's key. A service account can never sign in to the web app; it works only through API keys an admin issues — shown once, rotated with a grace period so running jobs keep working, revoked instantly. An account created from the admin page starts read-only (one declared in configuration should always name its role), can be limited to a list of AI-agent tools, and has its own request limits; every API key is now rate-limited per identity, and the bundled CI steps and the Terraform provider wait and retry when they hit the limit. An agent can say which person it is acting for, once that person has agreed: its permissions stay its own, the person is recorded on the request and in the audit log, and they can no longer approve that request themselves.
• Saying no as precisely as yes. An access grant can now deny specific schemas and tables — including ones created later — and that always wins over what it allows. It can refuse any query that touches a named column, even through SELECT *, rather than masking it, and refuse query shapes such as joins, subqueries or aggregates, which routing can also send to a reviewer instead. Row limits can be set per table, for everyone or for chosen people, roles or groups, and only ever tighten the limits already in place. Masking gains new strategies — keep the first characters, a constant, an empty value, regex replace, number bucketing and date generalisation — each checked on save and falling back to a full mask on a value it cannot handle. And the schema browser now shows each person only the tables they are allowed to query.
• Cost and volume budgets. On BigQuery, Snowflake and Databricks, where a ten-row result can scan a terabyte, a query whose estimated scan exceeds the cap you set is refused before it runs, and checked again just before execution. Per-person data budgets bound how many rows or how much data each user can read from a datasource over a rolling window: results are trimmed to what is left, and once the allowance is used up new reads are refused or sent for review. Everyone sees their remaining allowance in the editor, and heavy readers can be routed to a reviewer before they hit the limit.
• Your own policy service in the loop. For rules that routing conditions cannot express, AccessFlow can ask your own policy service — Open Policy Agent or an in-house API — over signed HTTPS. It may let a query through to the normal path, escalate it, require more approvals or reject it, but it can never approve one, and any failure sends the query to a person. The SQL is shared only if you opt in, and the service's address is checked so it cannot point inside your private network.
• What can this person do, right now? One read-only view shows everything a user can do on a datasource — capabilities, allowed and denied objects, masked columns, row filters and the row limit that applies — and names the grant, group or policy behind each. The decision traces for queries, API calls and deployments get their own pages, next to the answer to who can reach a table, and recertification evidence now records each grant's effective row limit.
• Clearer records of what ran. An executed query now keeps the statement as it actually ran — row filters and hidden-row rules included, with the values bound into it shown only as placeholders — with a toggle to compare it with what was submitted. Requests and audit entries can name the application that sent them, trusted when it comes from the API key and marked untrusted when the caller supplied it, and the audit log and query list filter on it.
• A monitor for background jobs. Platform admins get a page listing every scheduled job in the running install — how often it runs, when it last ran, how long it took, whether it failed and how many times in a row — with each job's run history a click away.
• Four more SQL review rules. New checks for schema changes that hurt in production, such as adding a required column with no default or building an index in a way that locks the table, each applying only to the databases where it matters and warning by default.

v2.6.0 — Answering from what AccessFlow already knows

Released 15 September 2026 · Release on GitHub

• Suggested queries in the editor. A third tab in the editor's right rail offers whole draft queries mined from your organisation's own approved history on that datasource, each with the evidence behind it — how often it was approved, by how many people, how recently. Ranking is a local heuristic, so there is no provider call, no cost, and it keeps working with AI switched off. Every suggestion is filtered against what you are actually allowed to run, break-glass and recurring runs never enter the corpus, and applying one only fills the editor: the draft is then analysed, routed and reviewed like any other query.
• An explainer for "why". Describe a hypothetical request and AccessFlow replays it through the very evaluators that decide real ones — the datasource and quota gates, the merged permission with each contributing grant named, every routing policy in priority order including the near misses, the grant fast path, the review plan, who could review it, and the row-security and masking that would apply — returning a stage-by-stage trace with the outcome. Nothing is written, run, published or sent to an AI provider, and what a hypothetical request cannot know is named rather than guessed. With it comes the reverse index: who can write to this table, one row per person, naming every source of the access — including the query-admin role that bypasses per-datasource permissions and appeared on no screen before.
• The same trace for API calls and deployments. A hypothetical governed API call can be traced through the connector gate, the read/write classification, the schema catalog, the effective permission, routing, the review requirement and the masking that would rewrite the response — without ever contacting the API. A hypothetical deployment reports the trigger grant, the freeze window, routing, the environment's own policy, the approvers, the deferred-release moment and the gate's own verdict, computed by the very function the CI job blocks on — and it takes an optional point in time, so "would a release this Friday evening be held?" is answerable today.
• Deterministic SQL review rules. A catalog of fourteen named checks — a DELETE or UPDATE with no WHERE, an always-true WHERE, SELECT *, unbounded or full-sort reads, cross joins, leading-wildcard LIKE, DROP / TRUNCATE / any DDL, banned functions, protected tables by pattern, and DML outside a transaction — each set to off, warn or block per environment. Tag a datasource development, test, staging or production, bind one ruleset per environment, and keep an organisation-wide default for the rest. Findings appear in the editor as you type and again on the query detail, the review queue, the break-glass retro-review and grouped requests. Block escalates, it never rejects: a blocking finding switches off every path that would have approved the query without a person and sends it to a reviewer, while a routing auto-reject still rejects.
• A privileged-access report. Everyone who can reach data without appearing in any permission table: holders of the query-admin permission — the built-in admin role or a custom role carrying it — and every break-glass grantee, direct or through a group. One row per person, with the role that carries the bypass, each break-glass datasource and its expiry, and how many queries — and how many break-glass runs — that person has actually submitted and when last. Readable by admins and auditors, recorded in the audit log on every read, and advisory only.
• An in-app help assistant. A launcher in the app shell opens a chat panel that answers "how do I submit a query for review?" or "how do I connect Snowflake?" from AccessFlow's own documentation, bundled with the running build so an install never describes a version it is not running, and cites the sections it used. An admin enables it and binds it to an AI configuration like any other AI-backed feature; where retrieval cannot be configured, a bundled quick-reference block answers instead. It is a documentation reader, not a data surface — no tools, no actions, and never a query, result, schema or audit row in the prompt. Conversations are private, retention-pruned, rate-limited per user and counted against the monthly AI token budget; remote corpus refresh is opt-in and off by default, and air-gapped installs can pin the corpus to what shipped.
• Policy simulator. Every routing, masking and row-security form has a Simulate button that replays a chosen window of your own past traffic twice — once under the current rules, once with the draft applied — and reports the difference: how many past queries would change outcome, which users would be affected, and which query shapes a row predicate would newly filter, deny or reject. Strictly a preview: nothing is saved, nothing is re-run, AccessFlow never connects to your database, and a shape an engine cannot classify offline is reported as unclassifiable rather than assumed safe.
• Onboarding by governance domain. The first-run wizard asks which of the three governed request kinds you intend to use — database access is always on; outbound API calls and CI/CD deployments are opt-in — and the answer shapes the dashboard checklist, the sidebar and the review hub, so an organisation that only governs databases never sees API or deployment navigation. It is visibility, not entitlement: every route and permission is unchanged, deep links keep working, and an admin can switch a domain on later. The dashboard also gains deployment widgets — pending deployment reviews, your recent deployments, and an environment version and drift tile.
• Sensitive-data discovery, hardened. The scanner now looks inside nested document and map values on MongoDB, Elasticsearch, DynamoDB and Neo4j, reporting findings under a dot-path field name so a confirmed tag lands on exactly the nested field the masker already understands. A pending finding that a scan of its table stops re-detecting is retired as stale and audited — never a finding on a table the run did not sample — and the "a scan is already running" guard is now cluster-wide, so two replicas can no longer sample the same datasource at once.
• Warehouse connectors. Snowflake key-pair authentication accepts a passphrase-protected private key, which Snowflake's own tooling generates by default. Databricks result sets larger than the inline limit are fetched through the API's external-links mode and streamed up to the proxy's own row and byte caps, with the temporary links never stored.
• Voyage AI embeddings. A first-class embedding provider for the RAG knowledge base and the help assistant, with a prefilled endpoint and model and an impossible vector dimension refused at configuration time rather than at ingest.
• Interface refinements. A permission created from an approved just-in-time access request now records which request produced it, so the explainer can say with certainty whether queries under that grant also skip review; help-assistant answers render as formatted text; and the datasource settings page adapts its credential fields to the engine.

v2.5.0 — Deployment version tracking and drift

Released 4 September 2026 · Release on GitHub

• AccessFlow now tracks which version is running where. Every environment records the release it last deployed and the one it was running before, updated as part of the deploy itself, so the record cannot drift from what actually happened.
• A version matrix across every pipeline. One row per environment: the version live on it now, the previous one, when it got there, and how that deploy ended. Each environment also keeps its own history, newest first.
• Drift, counted two ways. A row says how many newer releases have gone out since it last moved and how many days have passed, measured against the newest release that succeeded on that pipeline. It is a plain comparison, not an attempt to parse your version numbers, so it works whether you ship 2.4.1, a date or a commit hash — and it is computed when you look, with nothing scheduled and nothing alerted on.
• Environment tags. Environments carry up to ten short labels of your choosing — a customer, a region, a tier — and the matrix filters on them, which turns one application deployed for many customers into a single readable view.
• Rollbacks restore the record. A failed or rolled-back deploy puts the environment back on the version it was actually running, rather than leaving a version on screen that is no longer live. Drift badges appear on the deployment list and detail pages for the deploy currently live on its environment.
• An update hint for self-hosted installs. Every signed-in user sees the running version under the sidebar logo, and when a newer stable release exists it becomes a link straight to that release's entry on this page. The check is a single unauthenticated request for a small file, made at most once a day and off the request path — nothing about your install is sent, and ACCESSFLOW_UPDATES_ENABLED=false switches it off entirely for air-gapped deployments.
• Interface refinements. Query, API-call and deployment reviews now share one review queue with the rollback worklist beside them; reviewers can approve or reject straight from a deployment's own page; the sidebar is grouped by domain with collapsible sections; a pipeline id can be copied without reading it out of the address bar; and API keys can be given an expiry when they are created.

v2.4.0 — Deployment approval governance

Released 27 August 2026 · Release on GitHub

• Deployments are now a governed request, alongside queries and API calls. A CI/CD job asks AccessFlow for permission to release, an AI analysis scores the release metadata, reviewers decide in the web UI, and the pipeline blocks on a gate that only opens for an approved request.
• Pipelines and environments. Admins define pipelines for GitHub Actions, GitLab CI, Azure Pipelines, Jenkins, CircleCI, Bitbucket Pipelines or any generic runner, with ordered per-environment policies: required approvals, review-plan overrides and break-glass opt-in. Trigger and break-glass rights are granted per user or per group.
• Fail-closed release gate. The gate answers "not releasable" by default and opens only for an approved request with no active freeze window and a scheduled time that has passed. Any error or unknown request keeps the gate shut.
• Freeze windows — one-off or weekly recurring, org-wide, per pipeline or per environment — either hold releases or reject them at submission, and hold when a definition cannot be evaluated.
• Audited break-glass deployments need both an explicit grant and an environment that allows them, with no admin bypass and a mandatory retrospective review.
• Outcome reporting. After the deploy, the pipeline confirms execution and reports success, failure or rollback; a rollback on a review-required environment opens a follow-up review the submitter can never close.
• Native CI steps for GitHub Actions, GitLab CI and Azure Pipelines, plus a plain-curl walkthrough; notifications for every transition; an audit row for each state change; and a full web UI with a deployment list, detail page, reviewer queue, rollback worklist and pipeline administration with a copy-paste CI setup panel.

v2.3.0 — Data-aware governance and reviewer intelligence

Released 21 August 2026 · Release on GitHub

• Automated sensitive-data discovery. An opt-in per-datasource scanner samples column data through the governed sampling path, detects e-mail addresses, card numbers, national IDs, IBANs and phone numbers locally (optionally with the org's AI provider) and proposes classification tags an admin confirms or dismisses.
• Approval-outcome prediction. A per-organization model trained only on that org's own human review decisions shows reviewers how likely a query is to be approved. Advisory only — it never routes or decides.
• Recurring approved queries with result subscriptions. Approve a query, its cadence and its expiry once; each occurrence then runs through the full proxy pipeline and delivers results by e-mail or chat. Submitters and reviewers can stop a series at any time.
• Least-privilege intelligence. Standing grants are scored as never used, stale, over-scoped or active from real usage, surfaced in recertification worklists and a new over-provisioned-access report. Nothing is revoked automatically.
• Reviewer delegation and escalation. Out-of-office delegates with full attribution on every decision, plus optional escalation and nudge reminders for idle reviews.
• Result-export governance and DLP. Per-datasource export policies allow, watermark, cap or deny result downloads; every export is signed and audited.
• SIEM and WORM audit streaming to Splunk HEC, syslog/CEF, signed HTTPS batches and S3 Object Lock. Streaming is additive: the tamper-evident audit log remains the record.
• SCIM 2.0 provisioning. Okta, Entra ID, Keycloak and other identity providers create, update and deactivate users and groups over SCIM, so offboarding in the IdP revokes access here immediately.

v2.2.0 — Enterprise operations

Released 20 July 2026 · Release on GitHub

• External secrets managers. Datasource credentials resolve from HashiCorp Vault, AWS Secrets Manager or Azure Key Vault at connection time, with local encryption as the fallback and every resolve audited.
• High-volume proxy performance. Opt-in Redis-backed result caching for reads, batched inserts inside transaction envelopes, and multi-replica read load balancing with per-node health checks and primary failover.
• Backup, restore and disaster recovery. Helm backup and restore jobs, post-restore audit-chain verification, an AI provider fallback pool so analysis degrades to a local model when the primary is unreachable, and a documented runbook.
• ServiceNow and Jira ticketing. Tickets open automatically when a query is rejected, escalated or times out, link back to the request, and can sync a ticket resolution onto the pending decision.

v2.1.0 — API access governance, data lifecycle and reviewer productivity

Released 3 July 2026 · Release on GitHub · Patch release: v2.1.1

• API access governance. The same submit → AI risk → review → execute pipeline now governs outbound REST, SOAP, GraphQL and gRPC calls: a connector catalog with schema ingestion, a schema-guided request builder, response masking, break-glass and text-to-API drafting.
• Masking, data classification and dynamic variables for API connectors — field, JSON-path, XML-path and regex masking with reveal scoping, classification tags that raise AI risk, and per-call computed values (signatures, nonces, timestamps) that are never persisted.
• Request chaining and grouping. Bundle ordered query and API-call members into one request with a single aggregated review.
• AI optimization and index recommendations, applied as a draft that goes through the normal review, and a dry-run sandbox that previews the execution plan and estimated impact without changing data — including scan-cost signals on cloud warehouses.
• Saved-query version history and diffing, real-time collaborative editing of a query in review, and immutable query snapshots with replay into a test datasource.
• Mobile-friendly approvals as an installable app with one-tap push, guarded by step-up authentication.
• Multi-model AI orchestration with voting strategies and pre-call guardrails, per-model cost and latency tracked.
• Data lifecycle manager with retention policies, right-to-erasure requests and proxy-enforced pseudonymization; access recertification campaigns with CSV evidence; group-based access grants; and a personalized dashboard with an optional weekly digest.

v2.0.0 — Beyond relational databases

Released 24 June 2026 · Release on GitHub

• MongoDB, Couchbase and Redis governance through on-demand engine plugins: classification onto the standard approval workflow, row-level security, field masking and schema introspection for document and key-value stores.
• Text-to-query for NoSQL. A natural-language prompt drafts the engine's native query, still submitted through the full review pipeline.
• Behavioral anomaly detection. Rolling per-user baselines built from audit metadata flag out-of-pattern activity, escalate the user's next query and fan out notifications.
• Break-glass emergency access with instant admin fan-out, a prominent audit row and a mandatory retrospective review.
• Multi-tenant organizations with per-org quotas, a platform-admin console and a disable switch that blocks an org immediately.
• Data classification tagging for tables and columns; tagging derives masking and raises AI risk.
• Compliance reports and signed exports over the forensic query record, with a dedicated read-only auditor role.
• Terraform / OpenTofu provider and CI templates for declarative configuration, and OpenTelemetry tracing with Prometheus metrics and ready-made Grafana dashboards.
• Expanded MCP agent toolset — parse-only validation, governed column samples and the caller's own audit trail.

v1.4.0 — AI enhancements

Released 8 June 2026 · Release on GitHub · Patch release: v1.4.1

• OpenAI-compatible and Hugging Face providers. Point the OpenAI adapter at any compatible endpoint, or use the Hugging Face inference router out of the box.
• Editable analyzer prompts per AI configuration, with the default template shown in the admin UI.
• Langfuse integration for per-org call tracing and managed prompts.
• Text-to-SQL — draft SQL from a plain-language prompt, still reviewed like any other query.
• RAG knowledge base. Attach documents to an AI configuration so risk analysis and drafting can cite your own schema notes and policies.

v1.3.0 — Fine-grained access control and data protection

Released 3 June 2026 · Release on GitHub

• Just-in-time access requests. Users request temporary, scoped access that is granted on approval and revoked automatically on expiry.
• Policy-as-code routing. Attribute-based rules auto-approve, auto-reject, require extra approvers or escalate based on query type, tables, AI risk, role, group and time of day — and on client context such as source network and CI origin, failing closed when context is missing.
• Row-level security policies injected at the query layer so each user sees only the rows they are authorized for.
• Dynamic data masking per column — full, partial, hash, e-mail and format-preserving strategies with role- and group-based reveal.

v1.2.0 — Integrations and reviewer experience

Released 29 May 2026 · Release on GitHub

• Reviewer groups and scoping — user groups, per-datasource reviewer assignment and SSO group mapping so teams only see the queues they own.
• Read-replica routing sends reads to a replica and keeps writes on the primary.
• Query result diffing between repeated runs of the same query.
• Approve or reject from Slack via an interactive Slack app, and a PagerDuty channel for critical-risk and review-timeout events.
• Query templates library shared across the team, and a datasource health dashboard with pool statistics, query volume and latency.

v1.1.0 — Productivity and operations polish

Released 27 May 2026 · Release on GitHub

• Database drivers download on demand the first time an engine is used, instead of every driver shipping inside the application.
• Datasource creation wizard with engine logos and prefilled defaults.
• Query scheduling and bulk approvals.
• AI analysis history dashboard with risk trends and most-flagged query types.
• Schema explorer ER view and a searchable object tree with masking-aware sample previews.
• Review plan templates, audit log CSV export and an e-mail invitation flow for new users.

v1.0.0 — General availability

Released 26 May 2026 · Release on GitHub · Patch release: v1.0.1

The core platform — everything a team needs to govern database access end to end.

Proxy and execution

• Full SQL proxy for PostgreSQL, MySQL, MariaDB, Oracle and Microsoft SQL Server, plus admin-uploaded JDBC drivers for any other relational engine.
• Parser-based validation and classification, schema and table allow-listing, row caps, and DDL blocked by default — over reusable connections per datasource, so a governed query never waits on a fresh handshake.

SQL editor

• Dialect-aware highlighting, schema autocomplete, a formatter and a live AI hint panel.

Review workflows

• Per-datasource review plans, multi-stage approval chains, an AI review before human approval, auto-approve for reads, approval timeouts and submitter cancellation.

AI query analysis

• OpenAI, Anthropic and Ollama adapters with risk scoring, missing-index detection, anti-pattern flags and syntax suggestions.

Access control, audit and notifications

• Role-based access with per-user datasource permissions, time-limited grants and schema/table scoping.
• An append-only audit log with full event coverage and a searchable UI.
• E-mail, Slack and signed webhook notifications with retries.

Deployment and authentication

• Docker Compose, a Helm 3 chart with autoscaling and health probes.
• JWT sign-in with refresh-token rotation, SAML 2.0 single sign-on with auto-provisioning and attribute mapping, and OAuth 2.0 / OIDC sign-in with built-in provider templates.