Where AccessFlow sits

AccessFlow is an application-layer governance proxy. A person or a tool submits a request to AccessFlow — a query, an outbound API call, or a deployment. AccessFlow parses it, optionally has a model analyse it, routes it through the review workflow, and once it is approved executes it itself against the datasource, with the credential AccessFlow holds for that datasource. The result comes back the same way the request went in — through the web UI or the REST API — masked before the result snapshot is stored.

Nobody receives the database password. Datasource credentials are AES-256-GCM encrypted at rest, decrypted only to open the connection pool, and never returned by any endpoint. "Your team connects to AccessFlow instead of the database" therefore means people submit work to AccessFlow and AccessFlow talks to the database — not that AccessFlow speaks the database's protocol on their behalf.

Every way in

This list is complete. These are the only interfaces AccessFlow exposes. If a client, protocol or driver is not on it, AccessFlow does not offer it.

Web UI — the browser application: query editor, review queue, audit log, administration. Also installable as a mobile PWA with push approvals.
REST API — everything the UI does, under /api/v1. A browser session authenticates with a JWT; a program authenticates with an API key (Authorization: ApiKey af_… or X-API-Key). Personal keys are minted under Profile → API keys and carry exactly their owner's role and datasource permissions; service-account keys are API-key-only users for automation. The full endpoint reference is docs/04-api-spec.md.
MCP server — a Model Context Protocol tool surface for AI agents, authenticated with the same API keys. An agent can discover, validate, sample and submit; submitting enters the same review pipeline as a human submission, never a fast path.
Terraform / OpenTofu provider — declarative management of datasources, review plans, routing, row-security and masking policies, AI configs and notification channels over the REST API. See Infrastructure as Code.
CI templates — reusable GitHub Actions, GitLab CI and Azure Pipelines steps that provision a datasource, run a governed query, or block a release on the deployment gate.
SCIM 2.0 — inbound user and group provisioning from your identity provider (Auth & SSO).
SSO — sign-in delegated to an identity provider over SAML 2.0 or OAuth 2.0 / OIDC.

Outbound, AccessFlow notifies and integrates rather than being called: email, Slack, Discord, Telegram, Microsoft Teams, PagerDuty, ServiceNow and Jira tickets, and HMAC-signed webhooks (Notifications).

What AccessFlow is not

Not a driver, and not a database endpoint

AccessFlow exposes no database wire protocol. There is no ODBC, JDBC, ADO.NET or other client driver, no connection string, and no host and port that psql, mysql, DBeaver, DataGrip, Tableau, Metabase, Power BI or application code in C#, Java, Python, Go or any other language can point at as if AccessFlow were the database. The JDBC drivers and native SDKs the documentation talks about are what AccessFlow uses outbound, to reach your datasources — they are not something it offers inbound.

Can my C# (or Java, Python, …) application connect through AccessFlow with ODBC or ADO.NET?

No. An application cannot open a database connection to AccessFlow. The way for an application to run a governed query is the REST API: submit with POST /api/v1/queries using an API key, watch the request's status (GET /api/v1/queries/{id}, or a webhook on the decision), and read the result with GET /api/v1/queries/{id}/results once it has executed. An AI agent does the same through the MCP server. Both paths go through the full review workflow — an application never gets a shortcut around approval.

Not a database, and not a replacement for database-native grants

AccessFlow holds no copy of your database and does not manage the roles and grants inside it. It needs its own credential for every datasource and enforces its policies — allow-lists, masking, row-level security, row caps, approval — on top of whatever that credential is already allowed to do. Tighten the database side as you normally would; AccessFlow governs what reaches it.

Not a hosted service

There is no SaaS edition. AccessFlow is self-hosted, in your own infrastructure — and with a local Ollama analyser, air-gap friendly.

Supported engines, sign-in methods and AI providers

Each list below is complete. Something not on it is not supported today.

Databases and warehouses

The complete list of engines AccessFlow governs — an engine not named here is not supported today:

Relational — PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, and any other JDBC-compatible engine (ClickHouse, for example) via an admin-uploaded driver JAR.
Document — MongoDB, Couchbase.
Key-value — Redis, Amazon DynamoDB.
Wide-column — Apache Cassandra, ScyllaDB.
Search — Elasticsearch, OpenSearch.
Graph — Neo4j.
Warehouse — Snowflake, Google BigQuery, Databricks SQL.

Beyond databases, the same pipeline governs outbound REST, SOAP, GraphQL and gRPC API calls. Per-engine detail is in Connectors.

The complete list of ways a person or a program can authenticate:

Email and password issued in AccessFlow, optionally with TOTP two-factor.
OAuth 2.0 / OIDC — Google, GitHub, GitHub Enterprise Server, Microsoft, GitLab, self-managed GitLab, and any other OIDC provider (Keycloak, Auth0, Okta, Authentik, Zitadel, …).
SAML 2.0.
API keys, for programs and agents (see Every way in).

AI providers

The complete list of providers AccessFlow can call — a provider not named here is not supported today:

Analysis and help — Anthropic, OpenAI, Ollama, any OpenAI-compatible endpoint (vLLM, LM Studio, Together, Groq, OpenRouter, …), Hugging Face.
Embeddings (knowledge base and help index) — OpenAI, Ollama, any OpenAI-compatible endpoint, Hugging Face, Voyage AI. Anthropic publishes no embeddings API, so it is not offered here.

AI analysis is optional per datasource; see AI.

Deployment shape

One backend service (Java / Spring Boot) and one static frontend, run with Docker Compose or the Helm chart. It needs a PostgreSQL database of its own (with the pgvector extension for the knowledge base and the help index) and Redis for token revocation and scheduler locks. Open source under the Apache 2.0 licence. Details in Install & first run.

What AccessFlow stores

Its own PostgreSQL holds the governance record, not a copy of your data: the query or call text, the AI analysis, every review decision, the tamper-evident audit log, result snapshots (masked before they are written, and governed on export), and the encrypted datasource credentials. Retention of results and audit rows is configurable per organization (Audit & compliance).

Three governance surfaces

Database queries — the original surface: End-user workflows.
Outbound API calls — REST, SOAP, GraphQL, gRPC: Govern an API call.
CI/CD deployments — a pipeline blocks on approval: Gate a CI/CD pipeline.

One approval pipeline and one audit trail sit behind all three.