Database Risk Control Engine

AI agents are moving from "answering questions" toward "executing tasks on someone's behalf." They connect tools, read databases, generate SQL, call MCP services, and issue successive queries while diagnosing problems. This shift produces both new efficiency and new categories of risk: database operations that were once typed and reviewed by humans may now be generated, retried, and broadened automatically by a model.

The goal of FutrixData's database risk control engine is not to confine agents to read-only behavior. It is to build an explainable, configurable, auditable execution layer between agents and data sources. Risk is judged before a statement reaches the database; execution pauses for human confirmation when needed; clearly dangerous operations are blocked outright; and masking and audit continue to run on the result before it is returned to the agent.

This document covers three subjects:

1. Why the AI agent era heightens the need for database risk control.
2. How risk policies are configured for each database type within FutrixData.
3. How the FutrixData service layer identifies, approves, and blocks high-risk operations.

Why AI Agents Make Database Risk Control Necessary#

Traditional database permissions answer "who can connect, who can read or write." Agents introduce a finer-grained problem: under the same connection, account, and tool, different statements carry vastly different risk.

For example:

• SELECT * FROM orders WHERE id = 1001 may be a single point lookup.
• SELECT * FROM orders may pull out a large volume of customer data.
• UPDATE users SET status = 'inactive' affects an entire table.
• DELETE FROM logs WHERE created_at < now() - interval '7 days' may be routine cleanup, or may erase audit data still under retention.
• POST /_delete_by_query may trigger a bulk delete in Elasticsearch.
• FLUSHALL will wipe an entire Redis instance.

Risk also stems from the agent's own execution patterns. It may interpret a vague request as a broad query, retry with a more aggressive variant after a failure, transfer experience from a development database to production, or access the same data through CLI, MCP, or Skill. Database account permissions alone cannot express requirements like "allow low-risk reads, require confirmation for writes, and block destructive operations entirely."

FutrixData's risk control engine moves the control point in front of execution and reasons over the semantics of each statement and the type of database it targets. What matters is not which model the agent runs on, but what effect this particular operation will have on a specific data source, table, collection, index, or key pattern.

Risk Model: Rules, Probes, Trust Modes#

Risk evaluation in FutrixData is composed of three parts.

Part one: rules. A rule describes how a class of statement should be handled within a given scope. Actions fall into four categories:

Part two: pre-execution probes. For data sources that support execution plans or metadata analysis (MySQL, PostgreSQL, D1, MongoDB), FutrixData inspects the actual execution path beyond static rules — whether indexes are used, whether full-table scans occur, whether estimated or actual scan volume is excessive, whether D1 views can be expanded to underlying tables, and whether DynamoDB queries use partition or secondary index keys.

Part three: per-source trust modes. Trust modes govern whether programmatic entry points (Agent, MCP, Skill, CLI) can execute automatically at each risk level.

These three layers, combined, express policies that resemble real production environments: the same SELECT is low risk if it uses an index over a small range, but escalates to medium risk when the plan reveals a wide scan. The same write statement requires approval in standard mode but executes automatically against a disposable test database explicitly set to Danger.

General Rule Configuration#

A rule has three basic fields: scope, condition, action.

Scope describes where the rule applies:

• Database type — for example, MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch, DynamoDB, D1.
• A specific data source instance — for example, only the production MySQL.
• A specific table, collection, index, or key pattern — for example, orders, audit-*, user:*.

Condition describes which statements match:

• SQL or DynamoDB PartiQL command type — for example, SELECT, INSERT, UPDATE, DELETE.
• Whether a WHERE clause is present.
• MongoDB operation type — for example, find, aggregate, updateMany, dropDatabase.
• Redis command family — write, scan, scripting, administrative.
• Elasticsearch HTTP method, path, and request-body characteristics.

Action describes how the match is handled:

• Allow reads.
• Warn on writes, DDL, or wide queries.
• Require approval for bulk writes, index structure changes, and collection management.
• Block schema-clearing operations, database drops, and permission changes.

FutrixData ships with a baseline rule set and supports user-defined rules. User rules can override built-in rules by virtue of more precise scope and higher priority. For example, all MySQL UPDATE ... WHERE may default to a warning, while one production source's orders table additionally forbids any DELETE.

The thresholds embedded in built-in probes are also adjustable, including:

• Maximum scan rows.
• Maximum number of joins.
• Maximum count of full-table scans.
• A toggle and threshold for "treat sequential scan over a small table as normal" in PostgreSQL, MySQL, D1, and MongoDB.

These thresholds let teams calibrate to actual data volume: small-table queries in development are not falsely flagged, while wide queries on large production tables are caught in time.

Per-Database Risk Configuration#

Different databases imply different dangerous actions. FutrixData does not apply a single string blacklist to all of them — it parses statements and requests by database type.

MySQL, PostgreSQL, and Cloudflare D1#

Risk in SQL data sources comes mainly from writes, DDL, permission changes, and wide queries.

Built-in rules:

• Allow SELECT, SHOW, DESCRIBE, EXPLAIN, and similar reads.
• Warn on routine INSERT, REPLACE, UPDATE ... WHERE, DELETE ... WHERE, CREATE, ALTER.
• Block DROP, TRUNCATE, GRANT, REVOKE.
• Block UPDATE and DELETE without WHERE.

Pre-execution probes continue with execution plan checks:

• Escalate to medium risk when no index is hit.
• Escalate to medium risk when scan rows exceed the threshold.
• Escalate to medium risk when the plan is unavailable or unverifiable.
• For MySQL, inspect full table scans, temporary tables, filesort, dependent subqueries, and join row estimates.
• For PostgreSQL, inspect sequential scans, join counts, subplans, and large result-set sorts.
• For D1, inspect SCAN versus SEARCH stages and validate base-table scans after view expansion.

Rules can be configured by data source, table name, command, and WHERE condition — for example:

• Require approval for every DELETE on the production database.
• Forbid TRUNCATE on the audit_logs table.
• Loosen small-range updates on archive tables.
• Tune the wide-scan threshold for stricter behavior on large tables.

MongoDB#

MongoDB risk arises from collection-level writes, collection structure changes, user-role management, and implicit writes inside aggregation pipelines.

Built-in rules:

• Allow find, aggregate, count, and similar reads.
• Warn on insertOne, insertMany, updateOne, updateMany, replaceOne, deleteOne, deleteMany.
• Warn on cross-collection aggregations such as $lookup, $unionWith.
• Require approval for aggregations containing $merge or $out, since they write to other collections.
• Block drop and dropDatabase.
• Block user and role management — createUser, dropUser, grantRolesToUser.
• Require approval for structural management — renameCollection, collMod, dropIndexes.

MongoDB supports execution plan probes. Based on explain output, FutrixData checks:

• Whether a collection scan occurs.
• Whether the actual document scan count exceeds the threshold.
• Whether a blocking sort or complex access path is present.

Rules can be configured per collection or per data source. For example, allow ordinary inserts in development while requiring approval for any users collection update in production.

Redis and Redis Cluster#

Redis risk is closer to command safety and key-range safety. Without an EXPLAIN equivalent for cost estimation, FutrixData uses command semantics and key patterns as the control surface.

Built-in rules:

• Block FLUSHALL, FLUSHDB, SHUTDOWN.
• Block CONFIG SET, CONFIG RESETSTAT, dangerous CLUSTER subcommands, ACL SETUSER, ACL DELUSER, SCRIPT FLUSH, FUNCTION FLUSH, MODULE LOAD, CLIENT KILL, MIGRATE, and similar administrative commands.
• Warn on writes — SET, DEL, HSET, LPUSH, SADD, ZADD, EXPIRE, RENAME.
• Warn on reads that may return large volumes or block the service — KEYS, SCAN, HGETALL, SMEMBERS, broad ZRANGE, broad LRANGE.
• Warn on script execution — EVAL, EVALSHA.

Constraints can be configured by key pattern, for example:

• session:* allows reads only, no deletes.
• Writes against prod:* require approval.
• All administrative commands are forbidden to agents.

The Redis policy emphasizes preventing accidental deletes, database wipes, configuration changes, script execution, and broad scans.

Elasticsearch#

In Elasticsearch, risk often hides in the HTTP method, API path, and request body. A POST may be a search or a bulk write; a _search may turn into an unbounded scan.

Built-in rules:

• Allow GET, HEAD, and reads such as POST _search, POST _count.
• Block DELETE requests.
• Block POST _delete_by_query.
• Require approval for _bulk, _reindex, _update_by_query.
• Require approval for configuration writes — _settings, _mapping, _aliases, templates, pipelines, ILM/SLM.
• Warn on routine PUT, PATCH, and non-search POST.

Request body analysis additionally checks for:

• Wide queries — match_all, wildcard, regexp, fuzzy.
• Searches missing a query field.
• Aggregations without filters.
• Excessive size or deep pagination via from + size.
• script and script_score.
• Deeply nested aggregations.
• Terms aggregations without size set.

Rules can be configured by index pattern, method, and path. For example:

• Forbid DELETE on audit-*.
• Require approval for _reindex against production indices.
• Keep filter-less aggregations at warning level.

The Elasticsearch focus is preventing bulk deletes, index structure changes, deep pagination, scripted queries, and unbounded aggregations.

DynamoDB#

When DynamoDB uses PartiQL, statements look like SQL, but actual risk depends on whether partition keys, sort keys, or secondary indexes are used.

Built-in rules:

• Allow SELECT.
• Warn on INSERT, UPDATE ... WHERE, DELETE ... WHERE.
• Block UPDATE and DELETE without WHERE.

Pre-execution probes read table-structure metadata to verify access path reliability:

• Whether the query carries a partition-key condition.
• Whether the partition key is also present when a sort key is used.
• Whether the query correctly follows the key schema of the specified index.
• Escalate to medium risk when metadata is missing.
• Escalate to medium risk when key-based access cannot be proven.

Rules can be configured per table or per data source. For example, require approval for all writes to production tables, or restrict agents to automatic execution only when reads can be proven to hit a primary or secondary key.

How the Service Layer Identifies and Blocks Risk#

FutrixData's risk control does not live in front-end buttons — the real control runs in the service layer and execution path.

Unified Execution Entry Point#

Every database operation eventually reaches a unified execution manager. Before invoking a specific database adapter, the manager first invokes the risk-control interceptor. The full flow:

User or Agent triggers operation
        |
        v
Resolve data source and statement
        |
        v
Static rule evaluation
        |
        v
Run EXPLAIN / Describe / body analysis when applicable
        |
        v
Resolve to allow / warn / require_approval / block
        |
        v
Trust mode decides automatic execution, approval, or block
        |
        v
Database adapter executes
        |
        v
Mask result, write audit, return to caller

CLI, MCP, Skill, and AI Chat therefore do not need to implement separate logic — they all share the same service-layer policy and produce consistent outcomes.

Statement Parsing and Static Matching#

The risk engine parses by data source type:

• SQL — extract leading command, target table, presence of WHERE, joins, subqueries.
• MongoDB — extract collection and operation type, accepting both JSON and shell-style syntax.
• Redis — extract command and key pattern.
• Elasticsearch — extract HTTP method, URL path, body.
• DynamoDB — extract PartiQL command, table name, index name, condition information.

After parsing, the rule engine selects the matching rule by scope and priority — more specific rules outrank broader ones; at equal scope, higher priority wins; user rules override built-in rules.

When no rule matches, the system does not blindly allow unknown statements. Empty statements and clear reads are treated as low risk; non-read statements that cannot be classified are routed into warning state.

Dynamic Probing#

Static rules can identify what a statement intends to do, but cannot fully determine how much data it will scan or whether it will use an index. FutrixData performs a second check on data sources that support inspection.

• SQL, D1, MongoDB — run the execution plan and inspect indexes, scan volume, joins, sorts, subplans, and D1 view expansion.
• DynamoDB — read table and index metadata to verify whether PartiQL can use key-based access.
• Elasticsearch — analyze path and JSON body statically rather than running profile queries, avoiding expensive searches purely for pre-flight checks.
• Redis — judge by command semantics, since no suitable pre-execution cost estimation interface exists.

Dynamic probes only escalate risk; they never downgrade an operation that has already been classified as high risk.

Approval and Automatic Execution#

Agent entry points evaluate risk first and combine it with the data source's trust mode to decide execution:

• For automatic execution, the service layer carries an "approved at the entry point" context as it proceeds.
• For approval, CLI and MCP return an approval-required response; the caller must reissue the request with approve: true.
• For human action in the desktop Console, after the user clicks confirm, the request takes a dedicated interactive confirmation path.
• For a block result, normal mode returns structured risk information immediately.

The crucial detail: approval is not a free-form field that the caller can simply pass. FutrixData verifies agent identity at the entry layer, records the approval requirement, and forwards an approved context downstream. The execution service still passes through the unified manager — it merely skips redundant interception when authorization is explicit.

Agent Identity and Audit#

Agent-facing tool calls in FutrixData require an agent access key. The service layer validates this key before execution:

• Calls without a key are rejected.
• Calls with a revoked key are rejected and recorded in audit.
• Successful execution, failed execution, approval requirements, and rule hits all generate audit entries.
• The audit record retains risk source: whether a specific risk rule fired, or a system-level approval policy was triggered.

This makes three questions answerable:

• Which agent initiated the operation?
• What did it attempt to execute?
• Why did the system allow, require approval, or reject?

Result Protection#

Risk control answers "should this run." After execution, FutrixData also processes sensitive fields in the returned result. Data classification and masking are independent modules but live on the same service path as the risk engine: statements pass risk control, then execute against the database, then results are masked at field level by sensitivity rules before reaching the agent.

Recommended Configuration Steps#

When enabling database risk control, we recommend the following sequence:

1. Separate production, staging, and test data sources into distinct trust modes. Production should start at Approval or Cautious.
2. Keep the built-in block rules, and do not enable Danger on production.
3. Add stricter user rules for critical tables, collections, indices, and key patterns.
4. Tune probe thresholds to be more conservative for large tables and high-value data sources.
5. Enable audit and routinely review approval-required and blocked records.
6. Apply both classification and masking to sensitive fields returned to agents.

The point of risk control is not to prevent agents from using the database — it is to give agents a clear boundary in which to work: safe reads run automatically, risky operations pause for human confirmation, clearly dangerous operations are blocked, and a complete record is retained.

As AI agents take on more roles in database operations, data analysis, and business investigation, this layer becomes core data-platform infrastructure. FutrixData places it at the data-access entry point, so enterprises can keep using a wide range of agents without leaving database safety to model improvisation.