Execute any valid SQL statement, including data definition language (DDL), data control language (DCL), data query language (DQL), or data manipulation language (DML) statements, on a Cloud SQL instance. To support the execute_sql tool, a Cloud SQL instance must meet the following requirements: *...
Risk signalsAdmin/system-level operation
Part of the Mcp server.
Free to start. No card required.
AI agents invoke execute_sql 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 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": {
"limits": [
{
"counter": "execute_sql_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 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 SQL statement, including data definition language (DDL), data control language (DCL), data query language (DQL), or data manipulation language (DML) statements, on a Cloud SQL instance. To support the execute_sql tool, a Cloud SQL instance must meet the following requirements: * The value of data_api_access must be set to ALLOW_DATA_API. * For built_in users password_secret_version must be set. * Otherwise, for IAM users, 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. * 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 tool has the following limitations: * If a SQL statement returns a response larger than 10 MB, then the response will be truncated. * The execute_sql 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 execute_sql 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 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: 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 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 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. 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 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.