Six access problems, one governed checkpoint
Different teams reach for AccessFlow for different reasons. A platform team wants shared production credentials gone; an SRE wants access at 3 a.m. without a standing superuser grant; a DBA wants review that does not become a ticket queue; compliance wants evidence it can hand an auditor. Underneath the six database access management use cases below it is the same thing every time: one approval pipeline, one audit trail, one place where access policy actually runs — over SQL, NoSQL, cloud data warehouses and outbound APIs alike.
Production access without shared credentials
Shared logins and standing admin access are how breaches — and audit findings — happen. AccessFlow holds the database credentials, encrypted, and brokers every query through one checkpoint. Engineers sign in as themselves; nobody copies a password out of a vault again.
The credential never leaves the proxy. It is decrypted once when a connection pool is built and handed straight to the pool — or, if you would rather AccessFlow held nothing at all, the datasource stores a reference into HashiCorp Vault, AWS Secrets Manager or Azure Key Vault and the secret is resolved at connection time. Either way the user gets a result set, not a connection string, so rotating a password is a change in one place instead of a message to every engineer who has it.
- Every query attributable to a person, a reason, and an approval
- Credentials AES-256 encrypted — or fetched from Vault / AWS Secrets Manager / Azure Key Vault at connection time — resolved only inside the proxy, never shown to users
- SQL or NoSQL, the same flow — PostgreSQL and MongoDB governed identically
Just-in-time access that expires on its own
Standing privileges shrink to zero. Engineers request access for the window they need — minutes to days — to a database or a governed API connection (scoped down to specific operations), and the grant revokes itself when the clock runs out. When production is down at 3 a.m., break-glass lets on-call act immediately: every admin is alerted the moment it happens, and a mandatory retro-review closes the loop.
Break-glass is a permission, not a role — an admin does not get it by being an admin. It is held per datasource, granted to a user directly or through a group, and the effective answer is the most permissive grant that applies. What it skips is the queue, not the controls: masking, row security and row caps still apply to an emergency query, the run is written to the audit log under its own action, and the retro-review is opened against an admin who is never the person who ran it.
- Time-boxed grants — on databases and API connections alike — auto-revoked on expiry, no cleanup tickets
- Grants can pre-approve the queries they cover — one review for the access, not one per query
- Break-glass skips the queue, never the guardrails — masking, row security, and row caps still apply
- Every emergency run gets an after-the-fact review by an admin, never the submitter
Who a grant is issued to → Access requests and grants → Break-glass setup →
/admin/access-requests — each request names the scope and the window; the grant revokes itself when the window closes.Review at scale without a ticket queue
A governance process that takes days gets bypassed. AccessFlow's AI reads every query and API call first — risk score, anti-patterns, affected tables — so routing policies can auto-approve safe reads in seconds and send risky changes to the right approvers with the analysis already attached.
Routing policies are typed conditions, not a free-text rule language, and they see more than the analysis: risk band, statement type, the tables touched, the submitter's role or group, the time of day, and more. That makes the boring majority of a day's traffic — bounded reads against non-sensitive tables — disappear from the queue entirely, and it makes the queue that remains worth opening. Where the AI provider is unavailable the request does not sail through; it falls back to human review.
- Low-risk requests auto-approve — reviewers see only what deserves attention
- Once there's enough review history, pending queries show an approval likelihood learned from your own past decisions — a hint about what to open first, never a decision
- Approvers decide from Slack, email, or one-tap push, with AI findings inline
- Multi-stage approval chains for the changes that really matter
Watch a query move through review → Routing policies → AI configuration →
Audit evidence as a download, not a project
When the auditor asks who accessed customer data last quarter — and who approved it — the answer shouldn't be a two-week log archaeology project. Every request, decision, and execution lands in a tamper-evident, HMAC-chained audit trail, with scheduled access recertification campaigns and signed compliance exports on top.
The chain is what makes it evidence rather than a log file: each row carries a hash of the one before it, the table is INSERT-only, and the application's database role has no UPDATE or DELETE on it at all — a deleted or edited row breaks the chain and is visible as a break. Recertification then answers the other half of the question, which is not who used access but who still has it.
- Append-only, tamper-evident record of every decision — built for SOC 2, ISO 27001 & GDPR evidence
- Recertification campaigns certify or revoke standing access on a schedule, with CSV evidence
- An over-provisioned access report ranks standing grants nobody uses — advisory, never an automatic revocation
- Signed PDF/CSV compliance reports and a dedicated read-only auditor role
How the audit chain works → Audit log → Recertification campaigns →
Privacy obligations as running processes
Classify sensitive fields once — PII, PCI, PHI, GDPR — and let policy do the rest. Masking redacts tagged columns in every result, retention policies age data out on schedule, and right-to-erasure requests run through a governed, approved, audited workflow instead of a spreadsheet.
Classification is not only a labelling exercise: a query that references a tagged table gets an automatic AI risk-score bump, so one routing policy written against risk level covers sensitive data everywhere without naming a single table. A scheduled discovery scan can propose the tags in the first place by sampling column data, and an admin confirms or dismisses each proposal — nothing is applied behind your back.
- Field-level masking applied to results across SQL and NoSQL engines alike
- Retention and pseudonymization policies executed through the same governed proxy
- Right-to-erasure with an approval trail you can show a regulator
Every engine masking applies to → Data classifications and masking → Retention and erasure →
The same governance for your APIs
Sensitive data doesn't only live in databases — it flows through payment processors, CRMs, and internal services. AccessFlow puts outbound REST, SOAP, GraphQL, and gRPC calls through the same submit → AI review → approve → execute pipeline, with response masking and classification-aware risk scoring.
An API connector is registered much like a datasource: you point AccessFlow at an OpenAPI document, a WSDL, a GraphQL or protobuf schema — or a Postman collection, for teams with no spec at all — it ingests the operations, and a grant can then be narrowed from the whole connector down to a named subset of them. From there the vocabulary is the one your reviewers already know — the same review plans, the same break-glass permission, the same scheduling, and an audit trail that mirrors the query one action for action — so governing an outbound call costs no new process.
- One connector catalog for third-party and internal APIs, with schema ingestion
- Response masking policies and data-classification tags on API payloads
- Break-glass, scheduling, and audit — identical to the database flow
All AccessFlow capabilities → API connectors → Governed access for AI agents →