How FutrixData Handles Your Data — Local Execution, Local Secrets, Local Audit

Data paths at a glance

FutrixData has three data paths. They are intentionally separate and behave differently:

• Console (authorized human). The desktop Console is where engineers run ad-hoc queries against their databases. Raw rows are returned by default — the human at the keyboard is the authorized inspector.
• Agent result path (MCP, Skill, CLI). When an AI agent calls FutrixData via MCP, a Skill, or the agent CLI, sensitive result values are replaced with stable pseudonymous hashes before they are returned to the caller. This is where the masking guardrail lives.
• Schema metadata path. Schema knowledge — table names, column names, indexes, comments, types — can be sent to the LLM provider configured in AI Chat / schema knowledge / ER assistance. This is a separate path from result rows. Result masking does not automatically cover schema metadata. See the schema-to-LLM section below.

Where credentials and secrets live

Database credentials, datasource definitions, agent identities, sensitivity rules, AI provider keys, and the agent audit history are stored locally. From first launch the daemon uses a local encrypted store backed by an OS-keyring root key, so these files are encrypted at rest before any login takes place. If the OS keyring is unavailable on a given platform, the daemon surfaces a plaintext-fallback warning rather than silently downgrading.

None of these values are uploaded to FutrixData servers. The hosted gateway and license server only see what is required for billing and licensing — not your database credentials or query bodies. See limitations for the inverse: the things FutrixData does not protect against.

Result masking is secret-backed, deterministic, and one-way

On the agent result path, sensitive values are replaced with stable pseudonymous hashes. The substitution is a deterministic HMAC backed by a local secret stored in OS-level secret storage. The hash for a given input is stable inside an install (so analysts and agents see consistent values across calls) but cannot be reversed without that local secret.

Deterministic masking reduces leakage surface — it is not full anonymization. Two callers with the same secret will see the same hash; an attacker with full local-host control can recompute hashes for known inputs. See masking limitations.

Local hash-chain audit and the verify command

Every agent tool call writes an entry to the local agent audit log. New entries are hash-chained: each row carries the SHA-256 hash of the previous row, plus a payload hash and chain version. A built-in CLI command verifies the chain end-to-end and detects modified, deleted, inserted, or reordered records inside the chained section.

Run the verifier:

What the verifier reports

The JSON output includes whether verification passed, how many records were verified, how many legacy (pre-chain) records were found, the first failing position when verification fails, and the expected vs. actual hash for that position. The verifier is fully local — it does not need a network connection, an account, or the desktop app.

Local-only scope. Local hash-chain verification detects edits to the existing log, but external anchoring or immutable storage is required for stronger protection against full local log rewrite. The chain proves consistency of the file as you read it now; it cannot prove that an attacker with full local file control did not rewrite the entire file and recompute every hash. For higher assurance, you can mirror agent-tool events to a separate append-only store you control (for example Postgres with WAL archiving, an object store with object lock, or a write-only sink in another network). External immutable anchoring is not built into the gateway today; it is on the Enterprise roadmap (see the capability-state table below).

Risk-engine failure behavior on agent paths

Agent tool calls go through the same risk engine as Console queries: rules classify each statement as low / medium / high risk and decide whether to allow, warn, require approval, or block. On the agent path the engine is biased toward fail-closed: when the SQL parser cannot extract risk facts, when a probe fails, or when a multi-statement input mixes safe and unsafe operations, the agent path requires approval rather than auto-allowing. The Console (human) path may be more permissive on the same edge cases by design — see RBAC and audit for the full rule list.

Schema metadata to LLM providers

FutrixData's AI Chat, schema knowledge, and ER-assistance features may include schema metadata — table names, column names, indexes, comments, types — in prompts to the LLM provider you configured. This is on a separate path from query result rows. Result masking does not automatically cover schema metadata, because the schema is the question, not the data.

The desktop app exposes an explicit setting to enable or disable schema metadata transmission per data source. Each schema-to-LLM transmission is recorded so you can audit what schema left your machine, when, and to which provider. See the FAQ below for what to check before pointing FutrixData at databases whose schema itself is sensitive.

Capability state

This is the current implementation state of the security capabilities the rest of the marketing site references. We update this table when capabilities ship.