A Secure Database Client Built for Teams (and AI Agents)
Most database clients are designed for solo developers. FutrixData is built so a team can answer two questions at any time: "who ran what" and "who saw which data." Same policy applies to engineers in the desktop app and to AI agents calling over MCP.
What "secure" means in a database client
For a team that has to answer to a privacy regulator, a security engineer, or an internal review, "secure database client" comes down to four properties:
- Per-identity attribution. Every query is tied to a real user or agent, not a shared service account.
- Field-level masking on the agent result path. Sensitive columns are replaced with stable secret-backed pseudonymous hashes before the row is returned to MCP, Skill, or CLI callers. The Console (authorized human) returns raw rows by design.
- Server-side guardrails. Destructive operations are governed by rules on the gateway — not by client-side dialogs the user can dismiss. Conservative on the agent path: parser failures, multi-statement edge cases, and unknown statements escalate to approval rather than auto-allow.
- Local hash-chained audit. Each row carries the hash of the previous row; a built-in
audit verifyCLI detects modified, deleted, inserted, or reordered rows in the chain. Local verification only — see limitations for what it does not detect.
FutrixData ships all four out of the box.
The control surface
| Concern | Mechanism |
|---|---|
| Credential exposure | Connection strings live on the FutrixData host. Engineers and agents authenticate; they never see the raw credentials. |
| PII on screen / in prompts | L1–L5 sensitivity classification + secret-backed deterministic HMAC masking applied on the agent result path. Console returns raw rows for authorized humans. |
| Destructive queries | Per-database rule sets — DELETE/UPDATE without WHERE, DROP, TRUNCATE, FLUSHALL, dropDatabase, _delete_by_query, etc. |
| Wide queries | Pre-flight EXPLAIN on SQL/Mongo/D1 escalates risk on full scans, missing indexes, deep pagination. |
| Per-identity access | Per-user keys, per-agent keys; revocation is instant and preserves audit history. |
| Audit | Every call records identity, source, target, statement, outcome, and the matched rule. |
Compliance fit
FutrixData is not a certification — your organization still owns its SOC 2, ISO 27001, GDPR, or HIPAA program — but the gateway gives you concrete artifacts most database clients don't produce:
- A local hash-chained audit log of every database read and write, with the identity and the matched rule, verifiable from the CLI. Local verification only — for stronger assurance, mirror to an external append-only store. See limitations.
- Documented field-level masking on PII columns, applied on the agent result path (MCP / Skill / CLI) by default; the human Console preserves raw values for authorized inspection (configurable per data source).
- An access model with per-user / per-agent identity revocation and environment scoping. Team RBAC with roles, environment, and schema scopes is an Enterprise-edition feature.
- A self-hosted deployment option so production data never traverses a vendor network.
See trust for the data-path map and capability state, and limitations for what the gateway is not.
Same gateway, same guardrails — calibrated for humans vs. agents
The desktop Console (humans) and MCP / Skill / CLI calls (AI agents) hit the same gateway, the same query guardrails, and the same local hash-chained audit log. The one place behavior differs by design is masking:
- Console (human ad-hoc queries) — raw values are preserved, on the assumption that an authorized engineer is at the keyboard. The Console exists to inspect real data.
- Agent result path (MCP, Skill, CLI) — sensitive result values are replaced with stable secret-backed pseudonymous hashes before they are returned to the caller. Schema metadata is a separate path with its own per-data-source toggle and its own audit record (see trust).
You can tighten or relax masking per data source. There is no separate "AI mode" with weaker guardrails — masking is the only place where the human and agent paths diverge, and it diverges in the safer direction.
Frequently asked questions
Does this replace my existing database client?
For ad-hoc queries, schema browsing, and team-wide query access on supported databases — yes. If you depend on advanced GUI tooling like ER diagram authoring or vendor-specific server admin GUIs, you may keep an existing client alongside FutrixData.
Which databases are supported?
Currently MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch, ChromaDB, DynamoDB, and Cloudflare D1.
Where do credentials live?
On the FutrixData host — the desktop machine for solo use, or the gateway server for team / Enterprise deployments. They are not stored in shared config files, in agent prompts, or in third-party LLM context.
Is the audit log tamper-evident?
Within the local-only scope, yes. The local audit log is hash-chained, and the built-in futrixdata-cli audit verify --json command detects modified, deleted, inserted, or reordered records inside the chain. Local hash-chain verification detects edits to the existing log; external anchoring or immutable storage is required for stronger protection against full local log rewrite. See limitations.
Can I run this entirely inside my own network?
Yes. FutrixData Enterprise Edition is a Docker image (Compose or Kubernetes) you run inside your VPC. No database credentials or query bodies leave your perimeter. See self-hosted gateway.
How does PII masking work on result sets?
The default classification spans L1 (public) through L5 (credentials / payment / high-sensitivity personal data). On the agent result path (MCP / Skill / CLI), L4 / L5 fields are replaced with stable secret-backed pseudonymous hashes before the row leaves the gateway, so analysts and agents see consistent hashes without ever seeing raw values. The HMAC key is derived from a local secret stored in OS-level secret storage. The desktop Console preserves raw values for authorized humans by default. The level names, descriptions, example fields, and per-agent accessible range are all customizable — including defining additional levels beyond the default L1–L5. See PII masking and masking limitations.
Does FutrixData send schema metadata to LLM providers?
It can, on the AI Chat / schema-knowledge / ER-assistance paths. Schema metadata may include table names, column names, types, indexes, and comments — a separate data path from query result rows. Result masking does not automatically cover schema metadata. The desktop app exposes a per-data-source toggle for schema-to-LLM transmission, and each transmission is recorded as its own audit event. See trust for the full data-path map.
Try FutrixData on your own database
Free desktop app on macOS, Windows, and Linux. Self-hosted Enterprise Edition for production deployments.