Seven access problems, one governed checkpoint

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, to open AccessFlow's connections to the database, and never held beyond that — 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

How credentials are stored → Set up a datasource →

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 →

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 →

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
• A privileged-access report names who can bypass the permission gate — query admins and break-glass holders — and how often they have used it
• "Who can write to this table?" answered per table, naming every grant behind each person — and a decision trace that explains why a request would be approved, routed or held, without running it
• Signed PDF/CSV compliance reports and a dedicated read-only auditor role

How the audit chain works → Audit log → Recertification campaigns →

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 →

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 →

The database is not the only thing that reaches production — so does the deploy that changes it, and it usually goes out because a pipeline said so. AccessFlow puts a checkpoint in front of that step: the CI job asks whether this version may go to this environment, and waits for the answer. The approvals come from the same review plans, the same reviewers and the same audit trail as every query.

The answer is deliberately hard to get wrong. A release nobody recognises, an approval that has not been granted, a freeze window that is open, a deploy scheduled for later, or an outright error all come back the same way: not releasable. Each environment carries its own rules, a freeze can either hold a release or turn it away outright, emergencies have a break-glass path that tells every admin at once and demands a review afterwards, and the pipeline reports back what actually happened — succeeded, failed, or rolled back — so the record does not stop at "approved".

• A gate that fails closed: anything unclear answers "not releasable", never "go ahead"
• Per-environment rules, freeze windows, scheduled releases and audited break-glass
• A version matrix of what is live where, and how far behind each environment has fallen

How the deployment gate works → Set up deployment approvals → Deployment pipelines →