Security architecture
cloneside is built on a single security principle: your source data never leaves your machine on the local path. The gateway adds a read-only firewall between your AI tool and your database without changing that guarantee.
Local-first model
When you run cloneside scan or cloneside clone, the process runs entirely on your machine:
- Schema introspection and column classification run in-process.
- Synthetic data is generated locally using Faker and statistical models.
- No rows from your source database are uploaded to cloneside servers.
- Telemetry is opt-in and metadata-only (table count, dialect, duration) — connection strings are never included.
Gateway security
The MCP gateway sits between your AI tool and your database. The connection string lives in cloneside.toml on your machine — it is never passed through the MCP interface.
| Control | Implementation |
|---|---|
| Read-only by default | AST-level firewall (sqlglot) blocks INSERT, UPDATE, DELETE, DDL, and CTEs that wrap writes. Destructive SQL never reaches the database. |
| Row cap | Results capped at 500 rows at the database level (LIMIT injection) and in Python. Bulk data extraction is structurally impossible. |
| Connection string isolation | The target_url is read from cloneside.toml on your machine. The AI tool never sees the DSN — it calls describe_table and query with no credentials. |
| Statement timeout | Optional query_timeout_ms in cloneside.toml sets a per-query timeout at the database level (PostgreSQL SET LOCAL statement_timeout, MySQL max_execution_time). |
| Policy file | Optional [gateway.policy] lets you allowlist/denylist specific schemas and tables the AI can query. |
| Schema aliasing | The alias vault replaces real table and column names with opaque tokens (t001, c042) in the MCP interface. Real names never leave your machine. |
Hosted service controls
When you use the dashboard at app.cloneside.com, these additional controls apply:
| Control | Implementation |
|---|---|
| Passwords | bcrypt, cost factor 12 — never stored in plaintext. |
| Transport | TLS 1.3 enforced by Railway and Vercel on all endpoints. |
| Authentication tokens | Short-lived JWTs signed with SECRET_KEY; delivered as httpOnly cookies. |
| License keys | RS256 JWTs, offline validation — no live Stripe call at query time. Private key never stored in code or logs. |
| Audit logging | Append-only audit_logs table records all auth and data operations. |
| Secrets | All secrets in Railway / Vercel environment variables — never in source code or logs. |
Reporting a vulnerability
See our full security disclosure policy for scope, contact details, and our 48-hour acknowledgement commitment.