Three lanes, one review
Data, structure and MongoDB document changes all follow the same request, review and run.
Production data operations
keenbase puts a change request, a reviewer and a SQL guard between your team and the production database. Query through masked models, raise a change, get it approved, and keenbase runs exactly what was reviewed. Every step lands in the audit log.
Mark two refunded orders as refunded
UPDATE orders
SET status = 'refunded'
WHERE id IN (88412, 88413);
j•••@•••••.comHow it works
Declare the tables and collections people may touch and, for each field, whether it is visible, editable or masked. Import a whole connection in one pass.
The SQL and MongoDB consoles read through models only, on the read host, with masks applied and row limits capped. Hidden columns never leave the database.
Each change is checked against the model as it is written, with a masked before-and-after preview and an AI risk review.
A checker signs off and an owner executes. keenbase queues the run inside a transaction, then tells downstream systems.
Features
Data, structure and MongoDB document changes all follow the same request, review and run.
Per-model masks plus org-wide rules by column name, applied before anything is shown or cached. Built with UU PDP in mind.
An LLM reads the masked statement and flags its blast radius before reviewers do. Bring your own API key; raw values never leave.
Restrict a connection or a model to the people who need it. Anything out of scope simply doesn’t exist for them.
Add columns, widen types and create tables with seed rows through the same review. Each target opts in.
Who did what, to which resource, from where and when. Every action is recorded for ISO 27001 reviews.
Tell downstream systems a change landed via RabbitMQ, webhooks or Slack, with retries and a delivery log.
Reads go to replicas and writes to primaries, over SSH tunnels when you need them. Raw credentials never sit in keenbase’s own database.
Roles
Roles are fixed in code, so what each person may do is the same in every organisation and simple to explain to an auditor. Access scopes then decide where they may do it.
| Can | viewer | maker | checker | owner |
|---|---|---|---|---|
| View the dashboard, models and changes | ✓ | ✓ | ✓ | ✓ |
| Raise, edit and submit changes | — | ✓ | ✓ | ✓ |
| Run SELECTs in the consoles | — | ✓ | ✓ | ✓ |
| Run AI risk analysis | — | ✓ | ✓ | ✓ |
| Approve, reject or send back | — | — | ✓ | ✓ |
| Execute an approved change | — | — | — | ✓ |
| Manage connections, models, hooks and members | — | — | — | ✓ |
| View the audit log | — | — | — | ✓ |
Security model
Every statement is parsed and checked against the model before anyone approves it. What reaches the database is regenerated from the validated syntax tree, never the text someone typed.
WHERE.GRANT or REVOKE, and no DDL outside the allow-listed structure changes.> DELETE FROM customers;
✕ rejected DML without a WHERE clause
> UPDATE users SET role = 'admin' WHERE id = 7;
DROP TABLE audit_logs;
✕ rejected more than one statement
> SELECT * FROM customers LIMIT 5000;
✓ allowed * expanded from the model
hidden columns never selected
email, phone masked · limit 1000
Sign in, connect a database and model your first table. Your next change request is a few minutes away.
Open the console