How should I configure Gemini CLI tool permissions when allowed tools expose capabilities of disabled tools?

[LLLLLQ-4]

I am trying to use Gemini CLI for read-only database inspection and query-plan analysis. The agent should be able to inspect schemas and run EXPLAIN, but it should not be able to execute SQL that creates or modifies database objects.

I configured an admin policy that denies every tool by default and then allows a small set of PostgreSQL inspection and analysis tools with higher-priority rules:

[[rule]]
toolName = "*"
decision = "deny"
priority = 100

[[rule]]
mcpName = "postgres"
toolName = "explain_query"
decision = "allow"
priority = 999

[[rule]]
mcpName = "postgres"
toolName = "get_object_details"
decision = "allow"
priority = 999

[[rule]]
mcpName = "postgres"
toolName = "list_objects"
decision = "allow"
priority = 999

[[rule]]
mcpName = "postgres"
toolName = "list_schemas"
decision = "allow"
priority = 999

The policy also allowed the server's three named analysis helpers. I did not add an allow rule for execute_sql, so mcp_postgres_execute_sql remained denied by the wildcard rule. Shell execution and file reads and writes also remained denied. The model's tool list contained only the seven explicitly allowed PostgreSQL inspection and analysis tools; mcp_postgres_execute_sql was absent.

The intended read-only boundary was bypassed through the arguments and effect of the allowed explain_query tool. It accepted more than one SQL statement, for example:

SELECT 1;
CREATE INDEX IF NOT EXISTS idx_participant
ON participants_events(participant_id);

The tool returned Error: No results returned from EXPLAIN, but the index had actually been created in the database. The same route created a second composite index. The agent never called the denied execute_sql tool; it obtained the prohibited write effect through the allowed plan-analysis tool.

How should I correctly configure this read-only use case in Gemini CLI?

[abhiramshaji-cyber]

Hey @LLLLLQ-4, hope you're doing well! Thanks for writing this up so clearly, the policy file and the two statement example made it really easy to follow.

From what I can see on main, the policy engine decides per tool call. It matches the tool name (plus mcpName) and, optionally, argsPattern, which is a regex over the call's JSON args. It can't see what a tool does with those args once it runs. So once explain_query is allowed, any SQL that server accepts goes through, and I think the read only guarantee has to live below Gemini CLI, in the server or the database.

The tool names look like crystaldba's postgres-mcp, is that the one you're using? If so, it has a mode for exactly this: start it with --access-mode=restricted instead of unrestricted. In that mode every tool, explain_query included, goes through its SafeSqlDriver, which checks each parsed statement against an allowlist and runs inside a read only transaction, so the CREATE INDEX should get rejected. That matters for analyze: true too, since that option really runs the query. A Postgres role with only SELECT and no CREATE gives you a second wall that doesn't depend on any parser.

You could also add a higher priority deny rule with an argsPattern that matches ; in explain_query args, but regex over SQL is easy to slip past, so I'd treat it as an extra rather than the boundary. Would that setup cover what you need?