Execute any valid read only SQL statement on a Cloud SQL instance. To support the execute_sql_readonly tool, a Cloud SQL instance must meet the following requirements: * The value of data_api_access must be set to ALLOW_DATA_API. * For a MySQL instance, the database flag cloudsql_iam_authenticati...
Risk signalsAdmin/system-level operation
Part of the Mcp server.
Free to start. No card required.
AI agents invoke execute_sql_readonly to trigger processes or run actions in Mcp. Execute operations can have side effects beyond the immediate call -- triggering builds, sending notifications, or starting workflows. Rate limits and argument validation are essential to prevent runaway execution.
execute_sql_readonly can trigger processes with real-world consequences. An uncontrolled agent might start dozens of builds, send mass notifications, or kick off expensive compute jobs. PolicyLayer enforces rate limits and validates arguments to keep execution within safe bounds.
Execute tools trigger processes. Rate-limit and validate arguments to prevent unintended side effects.
{
"version": "1",
"default": "deny",
"tools": {
"execute_sql_readonly": {
"limits": [
{
"counter": "execute_sql_readonly_rate",
"window": "minute",
"max": 10,
"scope": "grant"
}
]
}
}
}See the full Mcp policy for all 15 tools.
These attack patterns abuse exactly the kind of access execute_sql_readonly gives an agent. Each links to the full case and the policy that stops it:
Other execute tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
Execute any valid read only SQL statement on a Cloud SQL instance. To support the execute_sql_readonly tool, a Cloud SQL instance must meet the following requirements: * The value of data_api_access must be set to ALLOW_DATA_API. * For a MySQL instance, the database flag cloudsql_iam_authentication must be set to on. For a PostgreSQL instance, the database flag cloudsql.iam_authentication must be set to on. * An IAM user account or IAM service account (CLOUD_IAM_USER or CLOUD_IAM_SERVICE_ACCOUNT) is required to call the execute_sql_readonly tool. The tool executes the SQL statements using the privileges of the database user logged with IAM database authentication. After you use the create_instance tool to create an instance, you can use the create_user tool to create an IAM user account for the user currently logged in to the project. The execute_sql_readonly tool has the following limitations: * If a SQL statement returns a response larger than 10 MB, then the response will be truncated. * The tool has a default timeout of 30 seconds. If a query runs longer than 30 seconds, then the tool returns a DEADLINE_EXCEEDED error. * The tool isn't supported for SQL Server. If you receive errors similar to "IAM authentication is not enabled for the instance", then you can use the get_instance tool to check the value of the IAM database authentication flag for the instance. If you receive errors like "The instance doesn't allow using executeSql to access this instance", then you can use get_instance tool to check the data_api_access setting. When you receive authentication errors: 1. Check if the currently logged-in user account exists as an IAM user on the instance using the list_users tool. 2. If the IAM user account doesn't exist, then use the create_user tool to create the IAM user account for the logged-in user. 3. If the currently logged in user doesn't have the proper database user roles, then you can use update_user tool to grant database roles to the user. For example, cloudsqlsuperuser role can provide an IAM user with many required permissions. 4. Check if the currently logged in user has the correct IAM permissions assigned for the project. You can use gcloud projects get-iam-policy [PROJECT_ID] command to check if the user has the proper IAM roles or permissions assigned for the project. * The user must have cloudsql.instance.login permission to do automatic IAM database authentication. * The user must have cloudsql.instances.executeSql permission to execute SQL statements using the execute_sql_readonly tool or executeSql API. * Common IAM roles that contain the required permissions: Cloud SQL Instance User (roles/cloudsql.instanceUser) or Cloud SQL Admin (roles/cloudsql.admin) When receiving an ExecuteSqlResponse, always check the message and status fields within the response body. A successful HTTP status code doesn't guarantee full success of all SQL statements. The message and status fields will indicate if there were any partial errors or warnings during SQL statement execution.. It is categorised as a Execute tool in the Mcp MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the MCP server in PolicyLayer and add a rule for execute_sql_readonly: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp. Nothing to install.
execute_sql_readonly is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the execute_sql_readonly rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for execute_sql_readonly. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
execute_sql_readonly is provided by the MCP server (https://sqladmin.googleapis.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 15 Mcp tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.