Connections

A connection is a saved credential for one external service, such as an AWS account, a Kubernetes cluster, or a GitHub organization. Agents can only see and do what your connections allow, so this page covers how to add one, scope it, check it, and keep it healthy. The full list of services is in the connection catalog.

Add a connection

Open Connections

In the sidebar, click More → Workspace settings → Connections. The Builtin Connections tab lists every supported service. Filter by category or search by name. When a setup guide says “open Connections”, it means this screen.

Connections screen with the service list on the left and a selected connection's detail panel on the right — Connections: pick a connection to see its discovery, settings, Allow writes switch and agents

Open the setup guide and follow its order

Open the setup guide for your service from the catalog, or click Setup guide on the service’s detail panel. Each guide lists the minimum permissions for the credential. The order depends on the service:

Service	Do this first
AWS	Open the connect dialog. It generates the External ID your role needs.
OAuth services, such as GitHub, Linear, and Sentry	Usually nothing: click Connect and sign in. A few need one-time setup first. Asana needs your own Asana app’s Client ID and secret, Atlassian needs an org admin to allow the CloudThinker domain, and Bitbucket asks for the workspace slug. See each guide.
Everything else, such as Google Cloud, Azure, Firebase, and Cloudflare	Create the credential at the provider, then open the dialog.

Connect

Select the service and click Connect. Enter or upload the credential and click Connect in the dialog.Services that support several accounts, such as AWS, Google Cloud, and SSH, also ask for an Alias (a short name like production) and a Description. Agents read the description to pick the right account, so make it specific: Production AWS account, us-east-1 workloads.

A service allows several connections only when its detail panel shows Supports multiple connections. Others, such as Microsoft Azure, Kubernetes, VMware vCenter, and every service you connect by OAuth sign-in, allow one connection per workspace. To connect a second Azure tenant or a second cluster, use a separate workspace.

Wait for the test

CloudThinker tests the connection before saving it. For most services the test calls the service with your credential. For some, such as Argo CD, Buildkite, CircleCI, Clarity, Databricks, Notion, Prowler, Render, and Rollbar, it only checks that the connection’s tool starts, so a wrong token can still show Connected. On those, the verify prompt in the setup guide is the real test.

Status	What it means	What to do
Connecting	The test is starting	Wait
Verifying	CloudThinker is calling the service with your credential	Wait
Connected	The test passed and the connection is saved. On services whose test doesn’t check the credential, it only means the tool started.	Run the guide’s verify prompt, then ask a question against it
Failed	The service rejected the credential. The provider’s error is shown.	Fix the credential or its permissions, then connect again
Timed out	The test didn’t finish in time	Check the service is reachable from CloudThinker Cloud. See Reaching private services.
Error	It worked before, then failed in the background	See When a connection breaks

Success state: the service shows Connected in the Connections list.

Ask a question against it

Open a chat and ask something only that service can answer. Each setup guide has a verification prompt.

Which AWS account and regions can you reach through my connection?

Success state: the answer names your real account ID or project, not a generic explanation.

Set the environment

Each connection has an Environment: Production, Staging, Development, or Not set. It labels the connection for the people and agents who read it. Rules (conditions that decide whether an agent’s change runs, waits for a person, or is refused) don’t read it.

The connect dialog doesn’t ask for an environment, so set it right after you connect. Single-connection services, such as Microsoft Azure, and every OAuth service, such as GitHub, Linear, and Sentry, can’t be changed from Not set. To treat one connection differently from another, write a Rule that names that connection.

On a service that supports multiple connections, each account shows as a row on the service’s detail panel. To set the environment, click the pencil icon on the account’s row, and update Environment in the Edit Instance dialog.

What happens after you connect

The first time a connection reaches Connected, CloudThinker runs Discovery: one background investigation of the service you just connected. Results fill the Discovery section of the connection’s detail panel.

Result	What it is	What you can do
Evidence	Facts about how the service is set up, each citing the read that produced it	Review it to see what agents can reach
Related connection	A service that would make the evidence more useful	Click Connect on the card
Recurring check	A repeat of the check, suggested from the evidence	Click Schedule to create an automation

Discovery is often the first useful answer you get, so check it before you write your first prompt. It runs automatically once, for at most 30 minutes. You can rerun it with Run Discovery, for example after you widen the credential’s permissions. You need the workspace Admin role to rerun it. Discovery spends credits, and the cost depends on how much the service holds. It can’t use daily credits (the 100 free credits a day that cover chat on the Light model only), so it needs credits in the workspace balance. If the balance is too low, it pauses with a notice. Add credits, then click Run Discovery. Discovery uses the same tools and Approvals as a chat, but no one is there to answer, so it never waits for approval. A call that would ask a person is skipped, and Discovery carries on with the reads it can make. On Cloudflare and PostHog, where every API call goes through approvals, on Databricks and Neon, where every SQL statement does, and on Firebase, where project switches and deploy status checks do, Discovery finds less whenever those calls would ask a person. If Discovery hits its time limit, it ends as Partial discovery and keeps the results it already verified. If it verified nothing, it shows Discovery could not finish. Your connection keeps working either way.

How access works

Every connection belongs to one workspace. Anyone working in that workspace, including the built-in CloudThinker agent and your custom agents, can use it without setting it up again.

Workspace role	See connections	Add, edit, rotate, delete, rerun Discovery
Admin	Yes	Yes
Developer, Viewer	Yes	No

Organization Owners and Admins hold workspace Admin in every workspace. See Workspace roles.

On most connections that have it, Allow writes starts on. That includes AWS, Google Cloud, Azure, Kubernetes, GitHub, GitLab, Bitbucket, Azure DevOps, AWS CodeCommit, Cassandra, Drata, FortiGate, Okta, and Rootly. A few start off, such as Docker Hub, Fly.io, FireHydrant, and Snowflake. Argo CD has no toggle: its READ_ONLY field in the connect form starts on Full access. If the credential you connect has any write permission, agents can propose changes the moment you connect, and your Rules and Approval mode decide each one. There’s no workspace or organization setting to start it off, so the controls are a read-only credential and turning off Allow writes on each connection. Each setup guide’s Write access or Agent capabilities section says what its connection starts with.

Two controls decide what an agent can do with a connection:

Nested limits: the credential's permissions contain Allow writes, which contains Rules and Approval mode; ClickHouse-style connections skip Rules and Approval mode. — The credential is the ceiling, Allow writes opens changes, and Rules and Approval mode settle each one, except on Connection setting, no approvals connections.

Control	Where it lives	What it decides
The credential’s own permissions	Your provider (IAM role, service account, API token scopes)	The ceiling. Agents can never do more than the credential allows.
Allow writes	The connection’s detail panel in CloudThinker	Off: agents can only read, and every change is refused. On: agents can propose changes, and your Rules and Approval mode settle each one. Manual asks a person before every write. The default, Auto · Rules + AI · Ask me, lets an Allow Rule or AI judgment approve a safe change and asks you about the rest. An Allow Rule decides only once CloudThinker turns on Rule enforcement for your workspace, so choose Manual until then.

How writes are controlled depends on the connection. Each setup guide’s Agent capabilities section says which model applies.

Write model	How it works	Default	Example
Allow writes toggle	Connections where agents run a command-line tool or script against the service. That covers the clouds and also script-based connections such as Bitbucket, Azure DevOps, Cassandra, Drata, and Docker Hub. The toggle is on the connection’s detail panel. Reads run without asking. With the toggle on, every write is checked against your Rules and Approval mode.	On for most, such as AWS, Google Cloud, Azure, Azure DevOps, Bitbucket, Cassandra, Drata, and Rootly. Off for a few, such as Docker Hub, Fly.io, FireHydrant, and Snowflake.	AWS, Google Cloud, Azure, Rootly
A write setting in the connect form	A field you set when you connect, instead of a toggle on the detail panel. With writes allowed, every change still goes through Approvals.	Set per guide. RabbitMQ’s RABBITMQ_ALLOW_MUTATIONS starts on Allow writes. Argo CD’s READ_ONLY starts on Full access.	RabbitMQ, Argo CD
Approvals on each change	There’s no toggle. The credential’s scopes set what’s possible, and every change goes through Approvals. Some reads go through approvals too: every Cloudflare and PostHog API call, Neon and Databricks SQL statements (`SELECT` included), and Firebase project switches and deploy status checks.	n/a	Neon, Firebase, Cloudflare
Connection setting, no approvals	A write setting in the connect form decides everything. With writes allowed, changes run with nobody asked, and your Rules and Approval mode never see them.	Read-only. ClickHouse’s Write access starts on Read-only (default).	ClickHouse
Read-only	Agents have no write actions at all, so no toggle or Rule can allow one.	n/a	Rancher, UptimeRobot
MCP tools, no toggle	A custom MCP connection has no Allow writes switch. CloudThinker sorts each tool the server serves into a read or a write: reads run without asking, and writes go through your Rules and Approval mode. A tool whose name contains a read word, such as `get` or `check`, counts as a read and runs without approval — `get_and_delete_user` included — unless the server marks it destructive.	Decided per tool, from the server’s own hints and tool names.	Custom MCP

On a Connection setting, no approvals connection such as ClickHouse, turning writes on lets agents change data with no Rule or approval in the way. Use a read-only database user unless you want that.

Allow writes starts on for most connections because the credential is the ceiling: a read-only credential already blocks every change. Start read-only, and widen the credential only when you have a specific change you want agents to make. Connections sign in one of two ways:

Method	How you connect	Examples
Credentials you paste or upload	An IAM role ARN, an access key, a service-account JSON file, or an API token	AWS, Google Cloud, Datadog, PostgreSQL
OAuth sign-in	You sign in to the provider in a pop-up and approve access	GitHub, GitLab, Linear, Sentry

Reaching private services

Connections run from CloudThinker Cloud, so the service must accept connections from the internet. That matters for anything on a private network, such as an internal vCenter, PostgreSQL, Prometheus, or Argo CD.

Option	When to use it
Expose the endpoint and allowlist CloudThinker’s egress IPs	You can put the service behind a firewall rule. These docs don’t publish CloudThinker’s egress IP list: ask your CloudThinker contact, or contact us. Never expose a service with no authentication.
Run a Worker inside your network	The service must stay private. A Worker is a folder on a machine you run where the agent can run commands. A Worker doesn’t make a connection private: workspace connections still run in CloudThinker Cloud, even in a Worker chat. Instead, install the service’s command-line tool (for example `psql`) and its credentials on the Worker machine, and the agent’s shell uses them there. The service won’t appear in More → Workspace settings → Connections. See What a Worker can reach. Workers are in beta.

Rotate a credential

You can replace a saved credential without disconnecting. The connection keeps its alias, settings, and history. AWS role connections use short-lived STS credentials, so there’s nothing to rotate: the External ID stays the same. Access keys, client secrets, JSON keys, and API tokens do need it.

Create the new credential at the provider

Create the new key or token first. Keep the old one active until the swap is done.

Replace it in CloudThinker

Open the service in More → Workspace settings → Connections, click the pencil icon on the account’s row, and in Edit Instance click Replace… next to the saved credentials. Enter the new values and click Save and test.Success state: the test passes and the connection stays Connected. If the test fails, CloudThinker keeps the previous credential and shows the error.

Revoke the old credential

Delete or deactivate the old key at the provider.

Single-connection services, such as Microsoft Azure and Backstage, have no pencil icon. Their Replace credentials button appears only while the connection shows Error, so to rotate early, disconnect and connect again with the new value. The exception is the token-based Git providers (GitLab, Bitbucket, Azure DevOps, and AWS CodeCommit): once Review is set up on them, rotate the token in Review → Settings → Connection actions → Update token, with no disconnect. See Azure DevOps and Bitbucket. A disconnect and reconnect starts a new connection, so plan it for a quiet period:

Agents, scheduled automations, and Optimize refreshes can’t use the service between the disconnect and the reconnect.
Discovery runs again and spends credits.
Allow writes goes back to its default, which is on for most connections. Turn it off again if you had it off.
Check that Rules naming the connection still list it.

Most OAuth connections don’t have a credential to replace. To switch the signed-in account, disconnect and connect again. Asana is the exception: it stores your Asana app’s Client secret, and you enter it again each time you reconnect.

When a connection breaks

If a credential stops working in the background (an expired token, a revoked key, a deleted role), the connection switches to Error. For AWS, that takes three background failures in a row, so one blip doesn’t trip it. Other connections switch when a background token refresh or a run hits an authentication failure. Workspace admins get one notification per outage, not one per failed retry. A test you run yourself never notifies anyone. While a connection shows Error, scheduled work that depends on it is skipped, including Optimize cost refreshes, scheduled automations, and Pulse alert polling. To recover:

Fix the cause at the provider, for example restore the role or issue a new key.
Open the connection. The detail panel shows the error. Click Retry to test the saved credential again, or Replace credentials to enter a new one. Replace credentials opens the same Edit Instance dialog as Replace…. For an OAuth connection, click Connect to sign in again.
When the status returns to Connected, scheduled work resumes on its next cycle.

Disconnect a connection

Open the service in More → Workspace settings → Connections. On a service with account rows, click the trash icon on the account’s row. On a single-connection service, click Disconnect on the detail panel. Confirm in the Disconnect dialog. It can’t be undone. Agents lose access to the service as soon as the disconnect finishes. Then delete the role, key, or token at the provider, because disconnecting doesn’t remove it there. If you connect the service again, it’s a new connection:

Discovery runs again and spends credits.
Allow writes goes back to its default, and Environment goes back to Not set.
Rules match connections by Alias. Reuse the same Alias when you reconnect, and Rules that name the connection keep matching.

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.

A connection isn’t read-only on its own. Many start with Allow writes on (see How access works), so a read-only credential is what keeps a connection read-only. How CloudThinker handles what you connect:

Question	Answer
Where is the credential stored?	Encrypted at rest. It’s injected into the CloudThinker-managed sandbox only when a command runs, never sent to a Worker, and never shown back in chat.
Can data reach the model?	Yes. Anything the credential can read can reach the model, because command output is part of the conversation. Scope the credential to what agents need.
Is data used for training, and how long is it kept?	These docs don’t cover model-provider data terms. See Security for what they do cover, and ask for the rest in a vendor review.
What’s logged?	Audit Logs (Admin Settings → Audit Logs) records connections created, edited, retried, and deleted, credential replacements, and approval decisions, on the Scale and Enterprise plans. Flipping a connection’s Allow writes switch isn’t recorded there.
Are agent commands logged?	Each command an agent runs, and its output, stays in the chat’s history. The calls also land in the provider’s own audit log, such as AWS CloudTrail or Google Cloud Audit Logs.

See Security for encryption details, retention, and the model provider.

Connection catalog

Cloud

Service	What agents can do
Amazon Web Services	See compute, storage, identity, cost, and monitoring.
Cloudflare	Review zones, traffic analytics, firewall events, and Workers.
DigitalOcean	See droplets, databases, Kubernetes, networking, and cost.
FPT Cloud	Inspect VMs, networks, activity, and resource tags.
Google Cloud Platform	See compute, GKE, BigQuery, storage, identity, and cost.
GreenNode	Operate compute, Kubernetes, databases, and storage by CLI.
Microsoft Azure	See virtual machines, AKS, databases, identity, and cost.
OpenStack	See compute, networks, storage, images, and quotas.
VMware vCenter	See virtual machines, hosts, clusters, and datastores.

Infrastructure

Service	What agents can do
AWX	Inspect Ansible inventories, then launch a job template.
HCP Terraform	Review workspaces and run health, then organize empty ones.
Pulumi	Review stacks, managed resources, and policy violations, then deploy to AWS.
SSH	Inspect server health, logs, disk capacity, and processes.

Containers

Service	What agents can do
ArgoCD	Inspect deployments, sync state, and managed resources.
Docker Hub	Review repositories, tags, sizes, and stale images.
Kubernetes	Inspect workloads, rollouts, logs, and node pressure.
Rancher	Inspect clusters, projects, nodes, and role bindings.

App Platforms

Service	What agents can do
Firebase	Review projects, apps, security rules, and deploy state.
Fly.io	Review apps, machines, regional placement, and capacity.
Heroku	Review apps, dynos, logs, add-ons, and deploys.
Netlify	Review projects, deploys, and forms, then deploy a change.
Render	Review services, deploys, logs, and Postgres, then deploy.
Supabase	Review projects, schemas, and migrations, then run a change.
Vercel	Review projects, deployments, and logs, then redeploy.

Databases

Service	What agents can do
Cassandra	Inspect keyspaces, tables, replication, and node health.
ClickHouse	Query databases, tables, and schemas across clusters.
CockroachDB	Inspect databases, schemas, and query performance.
Databricks	Inspect clusters, jobs, notebooks, and catalog assets.
InfluxDB	Query buckets, databases, retention, and series growth.
Microsoft SQL Server	Discover schemas and read or edit approved tables.
MongoDB	Inspect databases, collections, indexes, and query plans.
MySQL	Inspect schemas, indexes, table health, and slow queries.
Neon	Inspect projects, branches, schemas, and migrations.
PostgreSQL	Inspect tables, indexes, locks, and slow-query performance.
Redis	Inspect memory, capacity, expiration, and slow commands.
Snowflake	Track credit spend, query history, slow queries, and roles.

AI & Vectors

Service	What agents can do
Braintrust	Compare experiments, scores, and datasets across projects.
Langfuse	Investigate LLM traces, prompts, costs, and evaluations.
LangSmith	Explore run trees, projects, datasets, and experiments.
Pinecone	Inspect vector indexes and namespaces, then update records.

Monitoring

Service	What agents can do
AppDynamics	Trace APM transactions, tiers, nodes, and health rules.
Coralogix	Explore log pipelines, metrics, alerts, and incidents.
Datadog	Search logs, metrics, traces, monitors, and dashboards.
Dynatrace	Trace APM problems across logs, traces, and metrics.
Grafana	Explore dashboards, metrics, logs, and alert rules.
Honeycomb	Explore traces, datasets, waterfalls, triggers, and SLOs.
New Relic	Query APM entities, dashboards, alerts, and incidents.
Prometheus	Query live and historical metrics, labels, and alerts.
PRTG Network Monitor	Investigate sensors and alarms, read history, and act on monitoring objects.
Rollbar	Review top issues, deployments, and replay, then update one.
Sentry	Search issues, traces, events, and root-cause signals.
SigNoz	Trace services, dashboards, alerts, logs, and metrics.
Splunk Observability	Trace service health, dependencies, latency, and errors.
UptimeRobot	Track monitor status, uptime history, and recent incidents.
Zabbix	Review hosts, templates, triggers, events, and dashboards.

Logs & Search

Service	What agents can do
Elasticsearch	Inspect indices, mappings, shards, and cluster health.
Graylog	Search messages and streams with a read-only API token.
OpenSearch	Inspect indices, shards, documents, and search relevance.
Splunk Platform	Search logs over time ranges and review index volume.
Sumo Logic	Search logs, monitors, collectors, and Cloud SIEM insights.
Wazuh	Investigate alerts and agents, and manage detection rules.

Incidents

Service	What agents can do
Better Stack	Review incidents, on-call coverage, uptime, and heartbeats.
FireHydrant	Review incidents, severity, alerts, and the service catalog.
Jira Service Management	Review alerts and on-call, then acknowledge or escalate.
PagerDuty	Send incidents to Resolve.
Rootly	Review incidents, alerts, and severity, then file an action.
ServiceNow	Review and update incidents, changes, and problems.

Opsgenie isn’t a connection. Send its alerts to Resolve as a webhook signal from Resolve → Integrations.

Code & CI/CD

Service	What agents can do
AWS CodeCommit	Browse repositories, pull requests, and review comments.
Azure DevOps	Review pull requests, pipelines, and work items.
Bitbucket	Review repositories, pull requests, pipelines, and issues.
Buildkite	Trace build failures through jobs and logs, then retry.
CircleCI	Review pipeline failures and flaky tests, then rerun.
GitHub	Review repositories, pull requests, and Actions runs.
GitLab	Review repositories, merge requests, issues, and pipelines.
Harness	Review pipelines, deployments, services, and cost.
Jenkins	Review jobs, builds, logs, and tests, then launch one.

Security

Service	What agents can do
Cortex XDR	Triage incidents, alerts, and endpoints, then update incidents.
FortiGate	Check device health and traffic, then edit configuration.
GitGuardian	Scan code for exposed secrets and trace each occurrence.
HashiCorp Vault	Read KV secrets and generate temporary credentials.
IBM QRadar SIEM	Triage offenses, search events with AQL, and update offenses.
Keycloak	Inspect realms, users, clients, roles, and auth flows.
Okta	Review users, groups, apps, and one person’s access.
Palo Alto PAN-OS	Check firewall health, security rules, logs, and live sessions.
Prowler	Review security findings, checks, and cloud compliance.
Semgrep	Scan code for security findings across your repositories.
SonarQube	Review issues, quality gates, hotspots, and duplication.

Compliance

Service	What agents can do
Drata	Track failing tests, control readiness, and personnel.

Productivity

Service	What agents can do
Asana	Review projects, tasks, and workload, then update a task.
Atlassian	Search Jira issues and Confluence pages, then update one.
Backlog	Review tickets, milestones, and wikis, then update a ticket.
Backstage	Search the catalog for services, owners, APIs, and docs.
ClickUp	Review tasks, docs, and time tracking, then update work.
Linear	Search issues, projects, and cycles, then update one.
monday.com	Review workspaces, boards, and items, then update a board.
Notion	Search pages and databases, then update content.

Analytics

Service	What agents can do
Google Analytics	Read traffic, key events, and realtime activity with a service account key.
HubSpot	Search contacts, companies, deals, tickets, and quotes.
Microsoft Clarity	Watch traffic, engagement, and session recordings.
PostHog	Explore feature flags, insights, and user trends.

Messaging

Service	What agents can do
Apache Kafka	Watch topics, partitions, consumer lag, and cluster health.
Flespi	Explore devices, channels, messages, and streams.
RabbitMQ	Watch queue depth, consumer lag, dead letters, and alarms.

Custom MCP

Service	What agents can do
Custom MCP	Add any tool or API that runs an MCP server. Set it up on the MCP Connections tab.

If a service isn’t listed, connect it as a custom MCP connection. MCP (Model Context Protocol) is an open standard for giving AI agents tools. Chat platforms are set up as workspace integrations, not connections: see Slack, Microsoft Teams, and Google Chat. Connecting GitHub, GitLab, Bitbucket, or Azure DevOps also powers Review.

Next steps

Connect AWS

Create a read-only IAM role with one script in CloudShell.

Connect Google Cloud

Create a viewer service account and upload its JSON key.

Approvals

Decide which changes agents can make on their own and which need a person.

Custom MCP connections

Connect a service that isn’t in the catalog.

Customize

Approvals

Workspace settings

Admin Settings

Artifacts and sharing

Connections

Add a connection

Set the environment

What happens after you connect

How access works

Reaching private services

Rotate a credential

When a connection breaks

Disconnect a connection

Security