Your Cloud SQL Instance Has No Public IP.
Reach It by Name, Without a Bastion VM.
AgentsRoom starts the Cloud SQL Auth Proxy when you open the connection and points its database client at it. You give the instance connection name, project:region:instance, or pick it from the list your own gcloud login can see.
The proxy is authorized by your Application Default Credentials, so AgentsRoom stores no service account key. With IAM database authentication, there is no database password either. And an AI coding agent can query the same instance, read-only.
How AgentsRoom reaches a Cloud SQL instance on its private IP through the Cloud SQL Auth Proxy, with nothing stored on the app side.
A Cloud SQL instance with a private IP only is the right setup and an awkward one. The database lives in your VPC, its public IP is off, and the only machines that can reach it are the ones inside that network. Then a bug needs three rows looked at, from a laptop.
Google already ships the answer: the Cloud SQL Auth Proxy. It opens an encrypted connection to the instance, authorized by your Google identity rather than by an IP allowlist, and exposes it as a local port. The usual friction is everything around it: installing it, remembering the instance connection name, starting it in a terminal before opening a client, and forgetting it running afterwards.
AgentsRoom does that part. You choose Google Cloud SQL in the Reach through field of a database connection, give the instance, tick Private IP or IAM database authentication if you need them, and from then on opening that database is one click. The proxy starts with the connection and stops with it.
The Usual Ways Around It All Cost Something
Three answers to the same problem, and what each of them charges you.
A bastion VM just for this
A Compute Engine VM with an SSH port, kept in the VPC only so someone can tunnel to the database now and then. It needs patching, it costs money every hour, and its SSH keys and firewall rules drift as the team changes.
A public IP and an allowlist
Turning the public IP on and adding your home address to the authorized networks works until your address changes, and in the meantime the database is listening on the internet. It is the exception that never gets removed.
A service account key on a laptop
Downloading a JSON key to run the proxy is the shortcut everyone regrets: a long-lived credential in a Downloads folder, copied into scripts and prompts, that nobody rotates and nobody can trace.
From a Private Cloud SQL Instance to a Result Set
Four steps, done once, then it is one click.
Log in with gcloud, once
Run gcloud auth application-default login on your machine. The Application Default Credentials it creates are what the proxy uses to reach the instance. AgentsRoom reads none of it and stores none of it.
Pick the instance in Reach through
Create a MySQL or PostgreSQL connection and choose Google Cloud SQL in Reach through. Type the instance connection name, project:region:instance, or click List my instances to pick it from what your gcloud login can see. Host and port disappear: the instance is the address.
Choose private IP and IAM authentication
Tick Private IP when the instance has no public address and your machine reaches its VPC through a VPN or Interconnect. Tick IAM database authentication to sign in with your Google identity: the password field goes away, and the user is your IAM database user.
Query it, or let an agent query it
Opening the connection reserves a free loopback port, starts cloud-sql-proxy on it and waits until it accepts a TCP connection. The console connects to 127.0.0.1 like any other connection, and an AI agent can query it over MCP, read-only. Closing the connection stops the proxy.
The command AgentsRoom spawns
Nothing is reimplemented. AgentsRoom runs Google's own cloud-sql-proxy binary (version 2) as a child process, with its arguments passed directly rather than through a shell. If you have ever started the proxy by hand, this is the line you already know.
cloud-sql-proxy acme-prod:europe-west1:orders \
--address 127.0.0.1 --port 54321 \
--private-ip \
--auto-iam-authnThe instance and the two options come from the connection you saved. The local port is chosen by the operating system at open time.
The proxy accepts the local connection before it checks anything, then drops it and logs why when something is wrong. AgentsRoom reads that log and tells you the actual cause: the proxy is not installed, your gcloud login has expired (with the command to run), your account lacks the Cloud SQL Client role, the instance has no private IP, or the instance name is wrong.
What has to be true before it works
AgentsRoom drives your Google Cloud setup, it does not replace it. These are the same things the proxy needs on its own.
cloud-sql-proxy on your machine
Version 2 of the Cloud SQL Auth Proxy, on your PATH. gcloud components install cloud-sql-proxy is the quickest way; Google also ships it as a standalone download. If it is missing, AgentsRoom says so and names the command.
Application Default Credentials
gcloud auth application-default login, run once. When that login expires, the error tells you to run it again rather than showing a closed socket.
The Cloud SQL Client role
Your Google account needs the Cloud SQL Client role on the instance's project, and the Cloud SQL Admin API has to be enabled there. IAM database authentication also needs the Cloud SQL Instance User role and an IAM user on the instance.
gcloud for the pick list
List my instances runs gcloud sql instances list in your active project, or in the project you started typing. Without gcloud you can still type the connection name by hand.
A route to the VPC for private IP
Private IP means your machine itself must reach the instance's VPC, through a VPN, Interconnect or a machine inside the network. Without that route, leave Private IP off and use the public IP with the proxy's encryption.
What the Proxy Does, and What It Refuses to Do
The properties that decide whether this is safe to leave configured on a laptop.
Loopback only
The proxy listens on 127.0.0.1 and nothing else. The database is never republished on the local network, so a café Wi-Fi does not become a path to production.
A port picked by the OS
AgentsRoom asks the operating system for a free port and hands it to the proxy. No fixed port to remember, no collision with another proxy you started by hand.
Ready means ready
The connection opens only once the local port accepts TCP, and a proxy that exits straight away reports the reason it printed. No arbitrary sleep, no client connecting too early.
No key stored
The proxy is authorized by your Application Default Credentials. AgentsRoom stores the instance connection name and two options, none of which is a credential, and no service account key ever touches the app.
The database stays read-only
A database connection is read-only when created. A write needs that connection made writable and an explicit confirmation, louder on a connection flagged as production.
One statement per call
Each call carries exactly one statement, so nothing hides behind a semicolon, and result sets are capped so a wide query cannot flood a window or an agent context.
Why This Is Less Access, Not More
Nothing is opened on the instance side. The public IP can stay off, no network is added to the authorized list, and no VM with an SSH port is kept alive for the occasional query. The proxy encrypts the connection end to end to the instance.
Authorization stays where your organisation manages it: your Google identity and its IAM roles. Access granted to that identity is logged like any other Cloud SQL connection and ends the day the role is removed. AgentsRoom keeps the instance name, the Private IP choice and the IAM choice, and nothing that could be replayed by someone who read them.
On the database side the guardrails are the same ones every AgentsRoom connection gets: read-only by default, one statement per call, capped result sets, and a production flag that hardens the write confirmation. An AI agent querying through MCP gets a result set, never a credential, and cannot write unless you made that connection writable and turned on Allow agents to write for it.
MySQL and PostgreSQL, not SQL Server yet
Cloud SQL runs MySQL, PostgreSQL and SQL Server. AgentsRoom reaches the first two through the proxy, and does not have a SQL Server client today. AlloyDB, which has its own proxy, is not covered either.
Which engine or service comes next is decided by what people ask for. If yours is missing, say which one on the public backlog and it gets counted.
Request your database engineAn agent can query it too, read-only
Once the connection exists, an AI coding agent uses it through AgentsRoom MCP by naming it: db_list, db_schema to walk tables and columns, db_query for one statement with capped rows. An agent can also register a Cloud SQL connection itself with db_connection_new or db_connection_save, by giving the instance connection name.
AgentsRoom starts the proxy itself when the agent asks, so the agent never handles a Google credential, a database password or a port number. What travels back is a result set. Writes require a writable connection and the Allow agents to write setting, off by default.
An agent debugging against a production replica reads the rows that explain the bug, with no credential to leak into its context and no path to the database once the app is closed.
FAQ
How do I connect to a Cloud SQL instance that only has a private IP?
Create a MySQL or PostgreSQL connection, choose Google Cloud SQL in Reach through, give the instance connection name and tick Private IP. AgentsRoom starts the Cloud SQL Auth Proxy with --private-ip on a loopback port and connects its client to it. Your machine must reach the instance's VPC, through a VPN or Interconnect for example.
Does AgentsRoom store a service account key?
No. The proxy is authorized by the Application Default Credentials that gcloud auth application-default login created on your machine. AgentsRoom stores the instance connection name and the two options, none of which is a credential.
Can I connect without a database password?
Yes, with IAM database authentication. Tick it in the connection and the proxy runs with --auto-iam-authn: it signs in with your Google identity, the password field disappears, and the user is your IAM database user. The instance must have IAM authentication enabled and that user created.
What do I need installed?
The Cloud SQL Auth Proxy, version 2 (gcloud components install cloud-sql-proxy, or Google's standalone download), and a gcloud login for the Application Default Credentials. gcloud itself is only needed for the List my instances button.
What happens when my gcloud login expires?
The proxy refuses the connection and logs the reason. AgentsRoom reads that log and shows a plain message telling you to run gcloud auth application-default login, instead of a bare connection error. Then you retry.
Which local port is used, and who can reach it?
The operating system picks a free port when the connection opens, and the proxy listens on 127.0.0.1 only. Nothing on the local network can reach it, and the proxy stops when the connection closes or the app quits.
Which Cloud SQL engines are supported?
Cloud SQL for MySQL and Cloud SQL for PostgreSQL. Cloud SQL for SQL Server is not supported because AgentsRoom has no SQL Server client yet; ask for it on the public backlog and it gets counted.
Does it work on Windows and Linux?
Yes. cloud-sql-proxy is a native binary on macOS, Windows and Linux, and AgentsRoom starts it the same way on all three. The phone app lists the same connections and queries them read-only through your desktop.
Can an AI agent query the database through the proxy?
Yes, read-only by default. An agent names a saved connection through AgentsRoom MCP, the app starts the proxy and runs the statement itself, and only the result set travels back. The agent never receives a Google credential or a database password, and db_query refuses anything but a read unless the connection is writable and you turned on Allow agents to write for it.
You may also like
Database Connections
Save your MySQL, PostgreSQL and MongoDB connections, reach a database in a private subnet through an SSH tunnel or an AWS SSM session, and let your AI agents query it over MCP. Read-only by default, one statement per call, capped result sets, and the password never reaches the agent. Export, import and database-to-database copy included.
RDS through AWS SSM
Reach an Amazon RDS instance that has no public endpoint, from your own machine, through aws ssm start-session and the AWS-StartPortForwardingSessionToRemoteHost document. No bastion to maintain, no VPN, no inbound SSH rule. AgentsRoom opens the session on a loopback port and connects its database client through it. MySQL, PostgreSQL and MongoDB, so RDS MySQL, RDS PostgreSQL, Aurora and DocumentDB.
Secret Manager
Store API keys, tokens and passwords in your OS keychain, reference them as {{secret:NAME}} in dev commands and agent environments, and let AgentsRoom resolve them at launch. Agents see the names, never the values, and nothing is ever synced to a server.
SSH Connections
Save your SSH connections, open a built-in terminal over SSH, and run Claude Code, Codex or Antigravity CLI directly on your remote server or VPS. SSH key or password auth, per-project connection profiles, no separate SSH client needed.
Query Your Private Cloud SQL Instance
Download AgentsRoom, pick your Cloud SQL instance, and query it through the Cloud SQL Auth Proxy with your own gcloud login: no bastion VM, no public IP, no key on disk.
Companion app: monitor your agents on the go
Bring your own: Claude, Codex, Antigravity CLI, or other AI provider.
Push bugs and requests straight to your public backlog.