FutrixData Technical Overview

The capabilities of AI agents are expanding rapidly — from writing code and tracing issues to producing analytical conclusions. The next step is inevitable: agents will reach into real data environments to query orders, investigate logs, profile user behavior, inspect cache state, read vector stores, and access cloud databases.

Databases, however, are not ordinary tools. They hold customer privacy, business secrets, and production credentials, and a single faulty statement can degrade performance or destroy data. Handing a database account directly to an AI agent may seem expedient, but over time it produces three categories of risk that cannot be ignored:

• Data exfiltration risk — the agent may forward sensitive query results to an external model.
• Operational safety risk — the agent may execute deletions, updates, or full-table scans without sound judgment.
• Observability risk — the organization cannot answer which agent accessed which data, and when.

FutrixData is built to address all three. It sits between AI agents and data sources as a unified, secure, auditable access entry point: AI continues to handle querying, SQL generation, and analysis, while database credentials, risk evaluation, sensitive-data protection, and operation logging are governed by FutrixData.

Product Positioning#

FutrixData is an enterprise-grade secure data gateway built for AI agents. It connects MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch, ChromaDB, DynamoDB, and Cloudflare D1 into a single local application, then exposes controlled access through three channels: a built-in AI Chat, Skills, and MCP.

• For developers, it is a desktop tool that lets AI safely query databases.
• For teams, it is the entry point for centrally governing AI data access.
• For security and platform owners, it transforms AI data access from "every agent connecting on its own" into "every agent passing through one controlled channel."

Why You Should Not Hand Database Credentials Directly to Agents#

A common starting pattern is to drop a database connection string into Claude Code, Cursor, Codex, or a custom agent and let the model generate SQL or commands. This works for demos but quickly breaks down in real environments, in four distinct ways.

First, credentials sprawl beyond governance. Every developer, every agent, and every machine maintains its own configuration; revocation, rotation, and offboarding become difficult.

Second, models do not inherently understand production risk. A model may generate SELECT * to answer a trivial question, or treat operations like DELETE, DROP, FLUSHALL, and _delete_by_query as routine steps.

Third, query results continue to flow into model context. Once email addresses, phone numbers, tokens, addresses, salaries, or payment fields appear in a result set, they may be transmitted to an external LLM or relay service.

Fourth, post-incident attribution is hard. Database logs reveal that access occurred, but rarely tie it cleanly to a specific agent, channel, tool call, and risk rule.

The value of FutrixData is consolidating these problems into a single product.

How It Works#

FutrixData runs locally. Through a desktop application, users configure data sources, AI models, sensitive-data classifications, and risk-control policies. AI agents no longer hold database passwords — they access data through tools exposed by FutrixData.

A typical access cycle proceeds as follows:

1. The agent issues a request through AI Chat, Skill, or MCP.
2. FutrixData identifies the target data source and the operation.
3. The risk-control engine determines whether the operation is low risk, requires confirmation, or should be blocked.
4. After the database returns results, FutrixData applies masking to programmatic responses according to the sensitivity classification.
5. The system records the agent identity, the protocol used, the data source touched, and the outcome of execution.

The experience remains natural for end users — AI continues to assist with their work — yet from a data perspective, exposure is no longer scattered across each agent's local configuration.

Supported Data Sources#

FutrixData does not aim to support a single database type; it covers the data entry points most relevant to AI-assisted troubleshooting and analysis. The currently supported sources are:

As a result, a single agent need not learn eight different connection methods — it works exclusively through FutrixData's unified tooling for discovery, structure inspection, and query execution.

Built-in AI Chat: Query Data Without Leaving the Application#

FutrixData ships with a built-in AI Chat. Inside the application, users can ask in natural language:

• "Help me figure out why orders dropped recently."
• "What fields exist in this Mongo collection?"
• "Count session-related keys in Redis."
• "Will this SQL trigger a full-table scan?"
• "Explain the result of this Elasticsearch query."

AI Chat invokes the appropriate tools based on the current data source context: listing data sources, reading table structure, explaining execution plans, executing queries, looking up Redis command documentation, and requesting confirmation when needed.

AI Chat supports multiple model providers, including OpenAI, Anthropic, Gemini, Qwen, Zhipu, DeepSeek, OpenRouter, and any custom OpenAI-compatible endpoint. Teams can choose the provider they trust, or route through a self-hosted or private model gateway.

With AI Chat, users do not need to copy database content elsewhere or paste connection strings into third-party chat tools. The AI operates entirely within FutrixData's controlled environment, and every result passes through the same security policies.

Skill and MCP: Bring Existing Agents into Safe Database Access#

Many developers already work in Claude Code, Cursor, Codex, OpenCode, or other MCP clients. FutrixData does not require a toolchain switch — it embeds secure data access into existing agent workflows.

Through Skill, FutrixData installs a set of database tools into a local agent. The agent can then discover data sources, read schemas, execute queries, and save sensitive-data classification reports.

Through MCP, FutrixData operates as a standard MCP Server callable by any compatible client. The MCP toolset includes:

• List data sources
• View data source details
• Test connections
• List databases, tables, collections, indices, or keys
• Inspect fields, indexes, and structure
• Execute SQL, MongoDB, Redis, Elasticsearch, DynamoDB, D1, and ChromaDB queries
• View execution plans
• Look up Redis command documentation
• Read and save sensitive-data classification results

Each Skill or MCP installation generates an independent agent identity. As a result, audit no longer stops at "an access occurred" — it can answer precisely which agent accessed which data source through which channel.

Risk Control: Safety Checks Before Execution#

FutrixData's risk control is not a blanket ban on writes. It interprets the semantics of each operation per data source type and decides whether to allow, request confirmation, or block based on assessed risk.

It recognizes archetypal dangerous operations, including:

• SQL DROP, TRUNCATE, and DELETE/UPDATE without WHERE
• MongoDB drop, dropDatabase, and broad updates or deletes
• Redis FLUSHALL, FLUSHDB, SHUTDOWN, and CONFIG SET
• Elasticsearch DELETE, _delete_by_query, _bulk, and _reindex
• DynamoDB unconditional deletes or updates

It also evaluates query cost. For MySQL, PostgreSQL, D1, and MongoDB, FutrixData uses EXPLAIN or describe information where available to detect full-table scans, missing indexes, large scan estimates, complex joins, temporary tables, or unverifiable views. For Elasticsearch, it inspects HTTP method, path, and request body to identify oversized searches, deep pagination, scripted queries, and wildcard queries.

Each data source can be assigned its own trust level:

• Approval — every execution requires confirmation; suited for core production databases.
• Cautious — low-risk reads execute automatically, others require confirmation; the recommended default.
• Trusted — low- and medium-risk operations execute automatically, high-risk operations still require confirmation; suited for internal test environments.
• Danger — execute as much as possible automatically; only suitable for disposable sandbox data sources.

This capability resolves the longstanding tension between "letting AI do the work" and "not letting AI touch production data."

Data Masking: Analyze Without Exposing Raw Sensitive Values#

FutrixData supports field-level sensitivity classification. Working from schema information — that is, field names and data types — the system can help determine whether a field belongs to public, internal, confidential, sensitive, or critical tiers.

The default tiers are:

• L1 Public — public or non-sensitive operational data
• L2 Internal — internal identifiers and metadata
• L3 Confidential — indirect personal information, behavioral data, location data
• L4 Sensitive — direct personal information, financial data, medical data
• L5 Critical — credentials, payment instruments, high-sensitivity personal data

Users define which tiers an AI agent may access. Fields outside that range are automatically masked across programmatic paths — AI Chat, Skill, MCP, and CLI.

FutrixData currently uses a deterministic HMAC hash to replace sensitive values, which yields two practical benefits:

• The AI cannot see raw email addresses, phone numbers, tokens, or keys.
• Identical raw values map to identical masked values, so the AI can still perform deduplication, grouping, and equivalence-based analysis.

The boundary is explicit: humans querying directly through the desktop Console see raw results by default; AI and programmatic call paths receive protected results by default. This preserves human investigative efficiency while limiting the surface for AI-driven leakage.

Agent Audit: Know Exactly What Every Agent Did#

When AI agents enter the data workflow, audit can no longer stop at "the database was accessed." Teams need to know:

• Which agent initiated the action?
• Through Skill or MCP?
• Which tool was invoked?
• Which data source was touched?
• What statement was executed?
• Did it succeed, fail, or require confirmation?
• If risk control triggered, which rule fired?

FutrixData assigns each agent its own identity and records the full history of tool invocations. Each audit entry contains the agent name, agent type, protocol, tool name, target data source, execution status, statement summary, and risk attribution.

Once AI is part of the data access chain, the question shifts from "can it query?" to "can incidents be traced?" — and that traceability is the core value of audit.

Value for Individual Developers#

The most common challenge for solo developers is wanting AI to help with database work without scattering credentials across many agent configurations.

FutrixData provides a local, secure, visual entry point:

• Connect multiple local or cloud data sources.
• Query directly through the desktop Console.
• Use the built-in AI Chat for analysis support.
• Hand database capabilities over to Claude Code, Cursor, Codex, or OpenCode.
• Apply classification and masking to sensitive fields.
• Confirm before executing risky statements.

It is not a heavyweight platform aimed exclusively at large organizations — it is designed around the day-to-day reality of how individual developers actually work with AI.

Value for Teams#

For teams, the real question is rarely "can AI query the database?" but rather "how can more people query through AI safely?"

FutrixData offers a path that scales gradually:

• Developers begin with the local desktop edition, integrating AI into their data investigation workflow.
• Teams begin to standardize sensitive-field classification and risk-control rules.
• Multi-agent access behavior is recorded.
• Data source credentials no longer scatter across individual agent configurations.

As adoption moves from individual exploration to multi-person use, FutrixData naturally shifts from "a useful AI data tool" into "the unified secure entry point for AI data access."

Difference from a Traditional Database Client#

Traditional clients assume the operator is human. They focus on connections, editors, result tables, and query ergonomics.

FutrixData assumes the operator may also be an AI agent. It therefore takes on additional responsibilities beyond the traditional capability set:

• Provide a unified tool entry point for agents.
• Evaluate risk before execution.
• Process sensitive fields before returning results.
• Track identity and history per agent.
• Plug existing AI tooling in directly via Skill and MCP.

In other words, FutrixData is not a chat skin over a database client — it is a redrawn safety boundary for AI access to databases.

Core Value#

The value FutrixData delivers can be summarized in five points:

1. Faster — AI directly assists with querying data, reading structures, and explaining results.
2. Safer — risky operations are detected and blocked; sensitive fields are automatically masked.
3. More transparent — every agent's access behavior is fully recorded.
4. Less burdensome — data source credentials live in FutrixData rather than across scattered agent configurations.
5. More open — built-in AI Chat, Skill, and MCP are supported in parallel; no lock-in to a single model or tool.

Where It Fits#

FutrixData is particularly suited to scenarios such as:

• Teams using Claude Code, Cursor, Codex, or other agents in daily development who want safe database access from those agents.
• Workflows that require AI to analyze MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch, DynamoDB, D1, or ChromaDB.
• Environments where sensitive fields must not be exposed to external models or relay services.
• Concerns about AI generating dangerous SQL or high-cost queries at runtime.
• The need to trace database access history across different agents.
• A preference to start with a local desktop application rather than deploying a complex service stack.

The positioning is straightforward: let AI get close to data — without crossing the safety boundary.