CloudThinker Connections: How We Securely Connect to Your Infrastructure

A technical guide to CloudThinker's connectivity architecture: four network tiers from public HTTPS to private VPN, scoped credential management, and the security controls that let AI agents work on your infrastructure without weakening your security posture.

---

A security review for any new operations tool usually ends at the same diagram. The production database sits in a private subnet with no route to the internet. The Kubernetes API server has a private endpoint. The on-premise warehouse is reachable only over the corporate VPN. Then the vendor's onboarding guide asks for an inbound rule from 0.0.0.0/0, or an admin API key, or an agent installed on every host with root. The review stops there, and so does the project.

AI-powered cloud operations are only as useful as the infrastructure they can reach. Your network rules, IP restrictions and compliance controls took months to put in place. You're not going to punch holes in all of that for an AI platform.

CloudThinker Connections exists to solve that. The question isn't "how do we integrate with AWS". It's how we reach your infrastructure through the network architecture you already have, without asking you to lower your guard. The answer is four connectivity tiers, from simple public access to fully private VPN tunnels, and one set of credential and audit controls that applies to all of them.

---

Why the usual integration patterns break

Most tools reach private infrastructure in one of three ways, and each one fails a security review for structural reasons.

Open the endpoint. Give the database or cluster a public address and restrict it later. The restriction tends to be "later" forever, and the endpoint shows up in the next external attack-surface scan.

Install an agent everywhere. A daemon on every host with broad local rights solves reachability by moving the trust problem inside your network. Now you're patching, upgrading and auditing someone else's privileged software on every node.

One admin credential. A single broad key is the fastest way to make an integration work. It's also impossible to scope after the fact, and when it leaks, everything it touched is in play.

The pattern underneath is the same: the integration decides how much access it needs, and your network bends to fit. Connections turns that around. You pick the network path. You create the credential, scoped to what a skill actually needs. CloudThinker uses it only for the operation in hand.

---

Architecture overview

Every CloudThinker connection follows the same pattern: a skill needs access to a system, and a connection provides that access through a secure, audited channel.

01Request

CloudThinker

• SkillNeeds data from one system
• SandboxFresh sandbox per execution
• CredentialInjected for this operation only
• AuditEvery call logged

On demand, never persistent

02Network path

Your choice of tier

• PublicHTTPS with TLS 1.3
• Whitelist IPStatic source IPs
• VPC EndpointAWS PrivateLink
• VPNSite-to-site IPsec, IKEv2

Mix tiers per connection

03Your infrastructure

Where it lives

• Cloud accountsIAM role
• ClustersService account, namespaced RBAC
• DatabasesSELECT-only user
• ObservabilityRead-only API token

Scoped by credentials you create

The architecture is deliberately simple. CloudThinker doesn't hold a persistent connection to your infrastructure. Connections are on demand: opened when a skill needs them, scoped to the minimum required access, and logged at every step.

What varies is the network path between CloudThinker and your infrastructure. That's where the four tiers come in.

---

Four connectivity tiers

Each tier is built for a different set of network policies. You choose the one that matches yours, per connection.

01Tier 1

Public

HTTPS straight to public APIs and SaaS tools. Set up in minutes.

02Tier 2

Whitelist IP

Same encrypted path, gated to CloudThinker’s static IP range.

03Tier 3

VPC Endpoint

AWS PrivateLink. Traffic never leaves the AWS backbone.

04Tier 4

VPN

Site-to-site IPsec for on-premise and hybrid networks.

Tier 1: Public (direct HTTPS)

The simplest option. CloudThinker connects to your service over the public internet using HTTPS with TLS 1.3 encryption.

Best for:

• Cloud services with public APIs (AWS, GCP and Azure management APIs)
• SaaS tools (Datadog, PagerDuty, Jira, Slack)
• Development and staging environments
• Teams getting started with CloudThinker

How it works: CloudThinker makes HTTPS requests directly to your service endpoints. All traffic is encrypted in transit. Authentication uses standard credentials: API keys, OAuth tokens or IAM roles.

Setup time: Minutes. Enter your credentials, test the connection, done.

Tier 2: Whitelist IP

For organizations that restrict inbound access by source IP, CloudThinker provides a static IP range you can add to your allowlists.

Best for:

• Databases with IP-based firewall rules
• Infrastructure behind security groups that restrict source IPs
• Network policies that require known source addresses
• Compliance requirements that mandate IP-level access control

How it works: CloudThinker routes all outbound traffic for the connection through a fixed set of static IP addresses. You add those IPs to your security groups, NACLs or firewall rules. Traffic is still encrypted with TLS 1.3. The allowlist adds a network-layer gate on top of encryption.

On AWS, that's one rule per address on the security group in front of the service:

aws ec2 authorize-security-group-ingress \
  --group-id sg-0a1b2c3d4e5f67890 \
  --protocol tcp \
  --port 5432 \
  --cidr <cloudthinker-static-ip>/32

Setup time: Add CloudThinker's IP range to your allowlist, then configure credentials as normal.

To get CloudThinker's static IP range for allowlisting, contact our team. We provide dedicated IP ranges per region to keep your allowlist small.

Tier 3: VPC Endpoint (AWS PrivateLink)

For workloads that must never cross the public internet, CloudThinker supports AWS PrivateLink. Traffic flows entirely within the AWS network backbone: no public IP addresses, no internet gateway, no NAT.

Best for:

• Production databases in private subnets
• Regulated industries (finance, healthcare, government)
• Organizations with "no public internet" network policies
• Workloads that need the highest network-level isolation

How it works: CloudThinker exposes a VPC Endpoint Service. You create an interface VPC endpoint in your AWS account that connects to it, in the subnets you choose, behind a security group you control:

aws ec2 create-vpc-endpoint \
  --vpc-endpoint-type Interface \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.vpce.<region>.vpce-svc-<id-from-cloudthinker> \
  --subnet-ids subnet-0aaa1111bbbb2222c subnet-0ddd3333eeee4444f \
  --security-group-ids sg-0123456789abcdef0

What this means in practice:

• Your RDS instance stays in a private subnet with no internet route
• Your EKS cluster doesn't need a public endpoint
• Network traffic never leaves the AWS backbone
• You keep full control over which VPCs and subnets can connect

Setup time: Typically 30 to 60 minutes with your network team.

VPC Endpoint connectivity is available for AWS. For GCP (Private Service Connect) and Azure (Private Link), contact our team for availability.

Tier 4: VPN (site-to-site)

For on-premise infrastructure, hybrid deployments or the strictest network requirements, CloudThinker supports site-to-site VPN tunnels.

Best for:

• On-premise databases and legacy systems
• Hybrid cloud architectures (cloud plus data center)
• Organizations with mandatory VPN policies
• Multi-cloud environments that need unified private connectivity

How it works: CloudThinker establishes an IPsec VPN tunnel between our infrastructure and your network. Traffic is encrypted at the network layer and routed through the tunnel, fully isolated from the public internet. We support standard IKEv2/IPsec with configurable encryption algorithms, DH groups and PFS.

What this means in practice:

• Your on-premise PostgreSQL server is reachable as if CloudThinker were on your LAN
• Your data center firewall only needs to allow the VPN peer, with no broad internet rules
• Multi-cloud environments can be unified through a single VPN hub
• Network-level encryption that doesn't depend on application-layer TLS

Setup time: 1 to 2 hours coordinating with your network team. CloudThinker provides the VPN configuration details and helps bring the tunnel up.

Site-to-site VPN requires coordination with CloudThinker's infrastructure team. Contact us to schedule setup.

---

Security at every layer

Whichever tier you choose, every connection enforces the same controls.

01Default

Read-only

Writes exist only if you grant them in the credential.

02Scope

Least privilege

Each credential covers the minimum the skill needs.

03Storage

AES-256

Encrypted at rest, never logged, rotatable and deletable.

04Execution

Sandbox

A fresh sandbox per run, destroyed afterwards.

05Record

Audit trail

Who, what, when, where and result for every access.

Read-only by default

Every connection starts with read-only access. CloudThinker can query your databases, inspect your infrastructure and analyze your metrics, but it can't modify, delete or write unless you explicitly grant write permissions.

This is enforced at the credential level. The IAM role, service account or database user you provide determines what CloudThinker can do. It never asks for more than a skill requires.

Read-only credentials are the floor. When a write is granted, CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval. A credential with write rights is a ceiling on what's possible, not a decision about what actually happens.

Scoped credentials (least privilege)

Each connection uses credentials scoped to the minimum access required:

• AWS: IAM roles with specific policy boundaries, never admin access
• Kubernetes: Service accounts with RBAC limited to target namespaces
• Databases: Database users with SELECT-only grants on specific schemas
• Monitoring: API tokens with read-only dashboard and metric access

For Kubernetes, a namespaced read-only role looks like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: cloudthinker-read
  namespace: payments
rules:
  - apiGroups: ['']
    resources: ['pods', 'pods/log', 'services', 'events', 'configmaps']
    verbs: ['get', 'list', 'watch']
  - apiGroups: ['apps']
    resources: ['deployments', 'replicasets', 'statefulsets']
    verbs: ['get', 'list', 'watch']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cloudthinker-read
  namespace: payments
subjects:
  - kind: ServiceAccount
    name: cloudthinker
    namespace: payments
roleRef:
  kind: Role
  name: cloudthinker-read
  apiGroup: rbac.authorization.k8s.io

Note what's missing: secrets, and any verb that writes. When you create a connection, CloudThinker tells you exactly which permissions are needed and why. No hidden scopes, no broad wildcards.

Encrypted credential storage

Connection credentials are encrypted at rest with AES-256 and stored in CloudThinker's secure vault. Credentials are:

• Never logged in plaintext: not in audit logs, error messages or execution traces
• Never shared across organizations or workspaces
• Rotatable at any time, without reconfiguring skills
• Deletable instantly: revoke a connection and all stored credentials are purged

Sandbox isolation

Every time a connection is used, the operation runs in CloudThinker's Sandbox. The sandbox:

• Starts fresh for each execution
• Injects credentials only for the duration of the operation
• Destroys all state immediately after execution
• Prevents lateral movement between connections

Even if an operation fails or behaves unexpectedly, the sandbox boundary keeps your credentials and infrastructure isolated.

Full audit trail

Every connection access is logged with:

• Who: which agent, skill and user triggered the access
• What: the exact API calls, queries and commands executed
• When: a timestamp with millisecond precision
• Where: which connection and target resource
• Result: success or failure, response metadata and execution duration

Audit logs are immutable, tamper-evident and exportable for compliance review.

---

One connection, end to end

Here's an illustrative case: connecting a production PostgreSQL database in a private subnet over a VPC Endpoint, so CloudThinker can investigate slow queries.

1. Create a read-only user. Grant only what the investigation needs, and make read-only the session default as a second guard:

CREATE ROLE cloudthinker_ro LOGIN PASSWORD '<generated-password>';
GRANT CONNECT ON DATABASE app TO cloudthinker_ro;
GRANT USAGE ON SCHEMA public TO cloudthinker_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO cloudthinker_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO cloudthinker_ro;
GRANT pg_read_all_stats TO cloudthinker_ro;
ALTER ROLE cloudthinker_ro SET default_transaction_read_only = on;

pg_read_all_stats lets the user read pg_stat_statements and other statistics views without being a superuser.

2. Create the endpoint. The create-vpc-endpoint call above, in the database's VPC, with a security group that allows port 5432 from the endpoint's subnets only.

3. Run the connection test, and read a failure by what it rules out. The test checks four things in order, and each failure points somewhere different:

• Reachability fails. The credential was never tried. The problem is the path: the endpoint isn't available yet, its security group doesn't allow 5432, or the database's own security group doesn't allow the endpoint's subnets.
• Authentication fails. The path works and the database answered. Check the password, and check pg_hba.conf rules if you're not on RDS.
• Authorization fails. The user logged in but can't read what the skill needs, usually a missing USAGE on a schema other than public.
• Scope validation fails. The permissions don't match what the skill expects. Check for grants inherited from another role, which can make a "read-only" user broader than you meant, and tighten them before any skill uses the connection.

When something fails, CloudThinker tells you which check failed and how to fix it.

4. Use it. From chat:

"Using the production Postgres connection, show the ten slowest queries by total time from pg_stat_statements and explain what's driving the top three. Read only, change nothing."

---

Getting connected in four steps

Setting up a connection takes minutes, not days. The process is the same for every integration.

01Select

Service

Pick from 50+ integrations or any MCP-compatible server.

02Create

Credentials

Follow the scoped instructions for that service.

03Validate

Four checks

Reachability, authentication, authorization and scope.

04Use

Ready

Available to skills in your Workspace, scoped by RBAC.

Step 1: Select a service

Choose from 50+ supported integrations across cloud providers, databases, infrastructure tools, observability platforms and collaboration tools:

Step 2: Create credentials

CloudThinker gives step-by-step instructions for creating properly scoped credentials for each service. For AWS, that's an IAM role with a specific trust policy. For Kubernetes, a service account with RBAC bindings. For databases, a read-only user with grants on target schemas.

We tell you exactly what to create and why. No guessing, no over-provisioning.

Step 3: Connect and validate

Enter your credentials in CloudThinker and run the built-in connection test. It verifies:

• Network reachability (can we reach your endpoint?)
• Authentication (are the credentials valid?)
• Authorization (do we have the expected permissions?)
• Scope validation (are permissions correctly scoped?)

If anything fails, CloudThinker tells you exactly what went wrong and how to fix it.

Step 4: Ready to use

Once connected, skills that target that system can use it. The connection is available across your Workspace, scoped by your RBAC configuration. No additional configuration is needed.

---

MCP: extend beyond built-in connections

For tools and services not covered by the 50+ built-in connectors, the Model Context Protocol (MCP) provides a standard way to add custom integrations.

An MCP server is a bridge between CloudThinker and any API, database or service. You define the tools, inputs and outputs. CloudThinker handles orchestration, security and audit logging.

So CloudThinker isn't limited to the integrations we've built. Internal tools, custom APIs and niche platforms get the same security guarantees as built-in connections.

---

Choosing the right connectivity tier

Most teams start with Public or Whitelist IP for setup and evaluation, then move to VPC Endpoint or VPN for production workloads.

You can mix tiers within the same organization: Public for your Datadog integration, VPC Endpoint for your production RDS, and VPN for your on-premise data warehouse. Each connection is configured independently.

---

Why this beats the usual integration patterns

The deeper difference is who sets the terms. A typical integration arrives with its access requirements and your network adapts. Connections adapts to your network instead: you choose the path, you write the credential, and every use of it is on the record.

---

What's next

Connections is the foundation everything else stands on. Without secure, reliable access to your infrastructure, AI agents are just chatbots with opinions.

With Connections, CloudThinker can:

• Monitor your infrastructure in real time through Grafana and Datadog
• Analyze your databases with read-only query access
• Investigate incidents by correlating data across your whole stack
• Optimize cloud spend by reading cost and usage data directly
• Review code by connecting to GitHub or GitLab repositories

A good first prompt once your first connection is green:

"List what you can reach through my connections, and for each one tell me whether the credential is read-only and which network tier it uses."

---

Related reading

• Sandbox: secure execution and private connectivity
• Auto Mode: you decide what runs on its own
• Connections overview
• Connect a repo, get your first PR review in minutes

Ready to connect your infrastructure?

• Read the Connections Guide: step-by-step setup for every integration
• Try CloudThinker Free: connect your first service in minutes
• Contact Us for VPC / VPN Setup: enterprise connectivity with dedicated support