Average basket over the last 30 days, by plan:
sales.orderssales.subscriptionslive data
Back to the overview
Security Security & data
An AI on your data,with the rules built in.
Connecting a real database is the moment to be careful. The guardrails below are part of the DMS, not a line in a prompt, and the code they produce runs on your servers.
01 The AI's place
The AI never gets more access than its user.
Whether it builds a page today or, soon, operates the dashboard, the assistant works inside the same limits as the people it serves: their role, their permissions, and a review before anything ships.
Scoped like a teammate
It sees what the role of the user it works for may see. Roles go down to each block of each page.
Your data stays in your database
No copy, no sync to a third-party warehouse. Data only goes to the model provider you configure.
Every page change is reviewed
What the AI builds is a diff in your repo. Nothing ships until someone reviews and versions it.
02 AI Builder · connecting a database
Six guardrails, on by default.
When the AI builds your back office from a real database, these rules apply before you change a single setting. They live in the DMS, not in a prompt, so the model cannot talk its way past them.
It never reads your rows
To build, the AI uses the database catalog and aggregates only. Customer data never goes to the model.
It never sees your credentials
The connection URL lives in an environment variable. The AI works with a connection name, not a password.
A read-only role
We recommend a read-only database role for the analysis, and the DMS tells you which tables it could not read.
Writes off by default
Generated pages are read-only until you decide, table by table, that a page may insert, update or delete.
Secrets left out
Columns that look like secrets, such as password_hash or api_token, are excluded from the mapping on sight.
Nothing runs before you press Run
The AI proposes a plan and the code it would write. Nothing is applied until you review it and press Run.
03 AI Operator · in production
It acts as the user. Never more.
The Builder stays a development tool: it refuses to start with NODE_ENV=production. Next, the AI Operator will work in production: answering your team, running scheduled prompts, acting through MCP and generating documents, under these rules.
Same access as the user. It sees and does what the connected user can, checked on every call.
A global exclude list. Tables, columns and actions that no AI, cron or connected agent can reach, whatever the role.
Crons run as their creator. A scheduled prompt uses its creator's current permissions, checked at each run.
MCP is off until you enable it. External agents such as Claude Code connect with a user's token and get exactly that user's access.
Every action is logged. Each action is recorded and attributed to the user it ran for.
04 The platform
The basics, already secured.
Security does not start with the AI. Roles, members, tenants and hosting are part of the DMS from the first commit, and every line of it is code you can read.
Roles down to the block
Every page and every component has its own permission, editable in the roles screen.
/docs/auth-and-tenancy/auth-and-permissionsMembers and invitations
Sign-in, invitations and member management ship with the core.
/docs/auth-and-tenancy/authenticationMulti-tenant when you need it
Isolate each customer's data with tenants, from the SaaS module.
/docs/auth-and-tenancy/multi-tenantSelf-hosted
The DMS runs on your servers, next to your database. Nothing leaves your infrastructure unless you send it, including to the model provider you configure.
Open source
Apache 2.0. Audit the code that touches your data instead of trusting a sales page.
Code you can review
Pages, permissions and controllers are TypeScript in your repo, reviewed like the rest of your code.