Per-Agent Identity, Scoped Access, and a Verifiable Audit Trail
Each AI agent connecting to FutrixData gets its own access key, scoped permissions, and a local hash-chained audit trail. Every tool call records the agent, source, target, statement, outcome, and matched rule — written to a chain you can verify end-to-end with a CLI command.
Per-agent identity instead of shared credentials
The default pattern with raw database access is "the developer's connection string." FutrixData issues a distinct access key for each agent: each Skill installation, MCP client, and CLI session is uniquely identifiable. The proxy validates the key on every call; calls without a key are rejected; calls with a revoked key are rejected and recorded.
Scoped access
An agent's access is constrained on three axes:
- Data source. Which databases the agent can see at all.
- Risk action. What the agent is allowed to do (read-only, write with approval, write auto).
- Sensitivity range. Which classification levels the agent receives in the clear (default L1–L3; L4–L5 masked).
Trust modes (Approval / Cautious / Trusted / Danger) overlay the per-source risk policy without touching the agent's own scope.
Audit log fields
Every execution — successful, failed, blocked, or approval-required — produces an audit entry containing:
- Agent identity (which key, which channel — MCP / Skill / HTTP / CLI).
- Data source and target (table, collection, index, key pattern).
- The statement or request, parsed and normalized.
- Outcome (allowed / warned / approved / blocked).
- Matched rule and risk source — whether a specific user rule fired or a system-level approval policy was triggered.
- Masked column list, if egress masking applied.
- Timestamps and the approval reason, when present.
Instant revocation
Revocation cuts off an agent's future access immediately. Existing audit history is preserved — revocation is not deletion. Combined with per-agent keys, this gives the security team a clean response to "rotate credentials when X leaves" or "this Skill installation is compromised."
What the gateway gives a security reviewer
FutrixData is not a certification, and we do not claim it satisfies any specific control framework on its own — your organization owns its SOC 2, ISO 27001, GDPR, or HIPAA program. What the gateway does produce, on every database call:
| Reviewer question | What FutrixData provides |
|---|---|
| "Who did this?" | Per-agent access key with channel, label, and revocation state — recorded on every call. |
| "What did they touch?" | Data source, target (table / collection / index / key pattern), and the parsed statement. |
| "Was it allowed, and why?" | Outcome (allow / warn / approve / block) plus the matched rule(s) and risk source. |
| "What got out?" | The list of columns that were masked on the agent result path before the row left the gateway. |
| "Has the log been edited?" | Local SHA-256 hash chain across audit rows. futrixdata-cli audit verify --json detects modified, deleted, inserted, or reordered rows. Local verification only — see limitations. |
For environments that need stronger guarantees than local verification, you can mirror agent-tool events to an append-only external store of your choice — 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 on trust). See trust and limitations for the full data-path map and what the gateway does not cover.
Examples
{
"audit_id": "audit_01HQ8R...",
"ts": "2026-04-29T14:21:08.142Z",
"agent": { "key_id": "fxd_live_a1b2", "channel": "mcp", "label": "claude-code-laptop-01" },
"data_source": "prod-postgres",
"target": { "table": "users" },
"statement": "SELECT id, email, status FROM users WHERE id = $1",
"outcome": "allow",
"rule_hits": ["sql.read.indexed"],
"masked_columns": ["email"],
"duration_ms": 18
}Frequently asked questions
What's recorded in each audit entry?
Agent identity (key, channel, label), data source, target, parsed statement, outcome, matched rules, masked columns, duration, and any approval reason. Both successful and rejected calls are recorded.
How long are audit logs retained?
Configurable. The default for self-hosted deployments is governed by the storage backend (persistent volume or external PostgreSQL) — no automatic purge unless you set one. Hosted plans expose retention as an account setting.
Can I export audit logs to a SIEM?
Not yet, as a built-in feature. Audit entries are stored locally as JSONL and can be reviewed and verified with the audit verify CLI. If you need real-time SIEM ingestion today, you can tail the local audit file from your agent of choice. A documented external SIEM export will land alongside the Enterprise gateway's external-anchoring work — until that ships, this page does not promise it. See limitations.
Who can read audit logs?
Workspace admins via the desktop console; in self-hosted deployments, anyone with database-level access to the audit table. In Enterprise Edition, the admin console gates audit access by role.
Is the log tamper-evident?
Within the local-only scope, yes. Audit entries are written to a local hash chain — each row carries the SHA-256 hash of the previous row — and the built-in futrixdata-cli audit verify --json command checks the chain end-to-end. The verifier detects modified, deleted, inserted, or reordered records inside the chain. 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. For environments that need that, mirror events to an append-only external store (Postgres with WAL archiving, an object store with object lock, or a write-only sink in another network). See 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. This is a separate 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 so you can review what schema left the host, when, and to which provider. See trust for the full data-path map.
Is "RBAC" team RBAC, or per-agent only?
On the free desktop client, what you get is per-agent identity, access keys, revocation, and audit attribution — enough for solo developers and small AI-native teams. Team RBAC with roles, permissions, environment scopes, and schema scopes is an Enterprise-edition feature on the self-hosted gateway. We avoid the unqualified phrase "team RBAC" on free-edition pages so the wording stays honest about what edition gives you which slice. See self-hosted.
Does revocation delete history?
No. Revocation cuts off future access; the agent's prior audit entries remain. That's how you answer "what did this agent see while it was active."
Try FutrixData on your own database
Free desktop app on macOS, Windows, and Linux. Self-hosted Enterprise Edition for production deployments.