Redis Safety for AI Agents — Block FLUSHALL, KEYS *, and Admin Commands
Redis safety for AI agents intercepts wipe commands (FLUSHALL, FLUSHDB, SHUTDOWN), administrative commands (CONFIG SET, MIGRATE, SCRIPT FLUSH), and blocking reads (KEYS *, broad LRANGE / ZRANGE). Redis has no EXPLAIN equivalent — FutrixData governs by command semantics and key patterns.
Redis risk surface
Redis risk is closer to command safety and key-pattern safety than to query optimization. The dangerous operations are wipe commands, wide scans that block the single-threaded server, and administrative commands that change cluster state, ACLs, or modules.
Built-in Redis rules
| Command class | Default action |
|---|---|
FLUSHALL, FLUSHDB, SHUTDOWN | block |
CONFIG SET, CONFIG RESETSTAT, dangerous CLUSTER subcommands | block |
ACL SETUSER, ACL DELUSER, SCRIPT FLUSH, FUNCTION FLUSH, MODULE LOAD, CLIENT KILL, MIGRATE | block |
Writes — SET, DEL, HSET, LPUSH, SADD, ZADD, EXPIRE, RENAME | warn |
Broad reads — KEYS, SCAN, HGETALL, SMEMBERS, broad ZRANGE / LRANGE | warn |
Scripts — EVAL, EVALSHA | warn |
Key-pattern rules
Rules can be configured by key pattern, for example:
session:*allows reads only — no deletes.- Writes against
prod:*require approval. - Reads against
secrets:*are not allowed. - All administrative commands are forbidden to agents, even on dev sources.
Why no EXPLAIN equivalent for Redis
Redis does not expose pre-execution cost estimation. FutrixData uses command semantics and key patterns as the control surface — there is no probe layer like the SQL EXPLAIN path. This is intentional: running a probe that itself involves KEYS would create the exact problem we're preventing.
Examples
// Agent attempts:
FLUSHALL
// FutrixData response:
{ "ok": false, "risk": "block", "rule": "redis.flush_all" }// Agent attempts:
KEYS *
// FutrixData response:
{ "ok": false, "risk": "warn", "rule": "redis.broad_scan",
"reason": "KEYS * blocks the server on large keyspaces; use SCAN with MATCH" }Frequently asked questions
Does this support Redis Cluster?
Yes. Cluster connections are auto-detected and rules apply per command. Dangerous CLUSTER subcommands (CLUSTER FAILOVER, CLUSTER RESET) are blocked by default.
Are blocking commands handled?
Yes. BLPOP, BRPOP, and WAIT are recognized; you can scope timeouts and require approval for unbounded blocking calls.
Can I allow FLUSHDB on dev keys only?
Yes — by data source. Block FLUSHDB on prod-redis, allow it (or warn) on dev-redis. Trust mode adds another lever: dev sources can run on Trusted, prod on Cautious.
What about Lua scripts (EVAL)?
EVAL / EVALSHA land at warn by default. You can hard-block them per source. SCRIPT FLUSH and FUNCTION FLUSH are blocked outright.
Does this work with Sentinel?
Yes. FutrixData connects via Sentinel-aware Redis clients; rule evaluation is identical.
Try FutrixData on your own database
Free desktop app on macOS, Windows, and Linux. Self-hosted Enterprise Edition for production deployments.