Microsoft SQL Server

Connect SQL Server or Azure SQL so agents can map your tables, read and aggregate rows, and change single rows through your Approvals

Connect a SQL Server or Azure SQL database to let CloudThinker agents list your tables and columns, read and aggregate rows, and insert, update, or delete one row at a time through your Approvals. The connection signs in with a connection string for a dedicated SQL login, and that login’s grants decide which tables agents can see.

Prerequisites

• SQL Server 2016 or later, Azure SQL Database, or Azure SQL Managed Instance, reachable from CloudThinker on its SQL port (1433 by default).
• Permission to create a login or a contained database user and grant it access.
• SQL Server authentication enabled on the server. A server set to Windows authentication only rejects the login. This page covers SQL logins only. Windows authentication and managed identity can’t work, because the connection runs in CloudThinker Cloud, outside your domain and your Azure tenant.

Agents work with tables, not raw SQL. There’s no SQL console, no stored procedure calls, and no schema changes through this connection. Objects in sys and INFORMATION_SCHEMA are always excluded.

Setup

1. Create a dedicated user

   SQL Server or Managed Instance

   Create a login in master, then a user for it in your database:

   -- In master
   CREATE LOGIN cloudthinker WITH PASSWORD = '<strong-password>';
   -- In your database
   CREATE USER cloudthinker FOR LOGIN cloudthinker;
   

   Azure SQL Database

   Create a contained user directly in your database. No login in master is needed:

   CREATE USER cloudthinker WITH PASSWORD = '<strong-password>';
   
2. Grant read access to the tables agents should see

   Grant on one schema, or tighter, one table at a time:

   GRANT SELECT ON SCHEMA :: dbo TO cloudthinker;
   -- or: GRANT SELECT ON OBJECT :: dbo.orders TO cloudthinker;
   

   A table the user can’t read doesn’t appear to agents at all.

3. Open network access

   These docs don’t publish CloudThinker’s egress IP list: ask your CloudThinker contact, or contact us.

   • Azure SQL: in the Azure portal, open the SQL server, go to Networking, and add a firewall rule for each CloudThinker IP.
   • SQL Server: allow inbound TCP 1433 from those IPs and confirm the TCP/IP protocol is enabled, since some installs ship with it off.
4. Add the connection in CloudThinker

   In the sidebar, click More → Workspace settings → Connections, then on the Builtin Connections tab select Microsoft SQL Server. Paste your connection string into Connection string:

   Server=sql.example.com,1433;Initial Catalog=sales;User ID=cloudthinker;Password=<password>;Encrypt=True;
   

   Click Connect.

   Success state: the connection shows a Connected status. Run the verify prompt below to confirm agents can see your tables.

Connection details

The single Connection string field takes an ADO.NET connection string.

Keyword	What to put	Example
Server	Host and port, separated by a comma, not a colon	sql.example.com,1433
Initial Catalog	Database name. Required for an Azure SQL contained user	sales
User ID / Password	The user from step 1. Wrap a password that contains ; or = in single quotes, such as Password='a;b=c'	cloudthinker
Encrypt	True	True
TrustServerCertificate	Leave out, or False. Use True only for a self-signed or internal-CA certificate on a private network	False
ApplicationIntent	Optional. ReadOnly routes the connection to a readable secondary in an Always On availability group, so agent reads stay off the primary. Writes fail there, so use it only on a read-only connection	ReadOnly

Required permissions

You want agents to	Grant
List tables, read rows, and aggregate	SELECT on the schema or table
Insert, update, or delete rows	INSERT, UPDATE, DELETE on the specific schema or table

GRANT INSERT, UPDATE, DELETE ON SCHEMA :: dbo TO cloudthinker;

Skip db_datareader: it opens every table in the database. A schema or object grant is a tighter boundary. If agents should never change data, don’t grant INSERT, UPDATE, or DELETE at all. That’s stronger than declining each approval.

Agent capabilities

Capability	What agents can do	Checked by Approvals
Schema discovery	List reachable tables and their columns	No
Read rows	Select columns, filter, sort, and page through one table at a time	No
Aggregate	Count, sum, average, minimum, and maximum, with group by and having	No
Insert a row	Create one record	Yes
Update or delete a row	Change or remove one record, addressed by its primary key	Yes

Each read covers one table, so there are no joins in a single call. Reads return 25 rows by default and at most 100 per page. Aggregations time out after 30 seconds, and a single response is capped at 4 MB.

Every insert, update, and delete is checked on its own, one call at a time. Approving one delete doesn’t approve the next. Because updates and deletes target a primary key, a bad filter can’t sweep a table.

Every change an agent makes goes through your workspace’s Approvals first. On the default Auto · Rules + AI · Ask me mode, AI judgment can let a safe change run without asking — and an Allow Rule can too, once CloudThinker turns on Rule enforcement for your workspace. Choose Manual to approve every change yourself.

A Rule can also refuse a change outright, and approvers decide who can say yes.

Verify the connection

List the SQL Server tables you can reach and their columns

Expect each table named <schema>_<table>, such as dbo_orders, with its column list. In prompts you can write the usual dbo.orders, and agents match it to dbo_orders.

Example prompts

How many orders were placed per status in the last 30 days?
Show the ten most recent rows in dbo.orders
Set status to shipped on order 4821 in dbo.orders

Troubleshooting

Login failed for user

The user is in the wrong place, the password is wrong, or the server accepts Windows authentication only. A login lives in master. A contained user lives in your database and needs Initial Catalog set. Check the password for leading or trailing spaces, and wrap it in single quotes if it contains ; or =.

The connection fails on a certificate error

With Encrypt=True, the client refuses a server certificate it can’t verify instead of falling back to plaintext. Install a trusted certificate. For a self-signed or internal-CA certificate on a private network, add TrustServerCertificate=True. Traffic stays encrypted, but the server’s identity is no longer checked.

The server is unreachable or the connection times out

Check that Server uses a comma (host,1433). For Azure SQL, confirm the firewall rules include CloudThinker. For SQL Server, confirm inbound 1433 is open and TCP/IP is enabled.

An agent can't find a table

The user needs SELECT on that table or its schema. Name the table with its schema, such as dbo.orders, because an unqualified name can be ambiguous.

An update or delete is refused

The table has no primary key, or the user lacks the matching UPDATE or DELETE grant. Reads and aggregations still work. Add a primary key or the grant if agents should change that table.

The agent won't run my SQL statement

Expected. This connection has no SQL console or stored procedure access. Ask for the result you want, such as a filtered read or a grouped count, instead.

Security

• Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
• Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
• Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
• Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.

• Grant the schema, not the database: scope SELECT to the schema holding the tables agents need, and everything else stays invisible.
• Read-only by omission: a user with only SELECT can’t write, whatever gets approved in a conversation.

Related

Approvals

Decide which row changes run, wait for a person, or are refused.

PostgreSQL connection

Connect a PostgreSQL database with a read-only user. Unlike SQL Server, it runs in restricted mode with no writes, approved or not.