Connections: One Integration Layer, Scoped by Design
Checkout latency doubles at 14:10. The cause could be in a Datadog trace, a pod event, last hour's deploy, a slow query, or the internal feature-flag service your platform team wrote three years ago.
An engineer checks those in five tabs with five logins. An agent has to do the same, and it can only check what it can reach. If it can see the cluster but not the database, it'll blame the cluster.
So the quality of an investigation starts with access. In Frontier Investigation Agents, that access comes from one place: Connections.
The problem: evidence lives in a dozen systems
A real incident crosses cloud, cluster, telemetry, code and tickets. Each system has its own API, its own auth and its own idea of what read-only means.
And the system that matters most is often one no vendor supports: the homegrown metrics service, the deploy tracker, the legacy billing API.
Why the usual approaches break
Integrations per agent. Each agent or bot gets its own plugin set. They drift. The incident bot can read Datadog, the cost bot can't, and nobody remembers which credential lives where.
One broad credential. Faster to set up, impossible to reason about. When a single key can do everything, "what can the agent touch?" has no short answer.
Keys pasted into chat. It works once. Then the key sits in a transcript, and the next person has no idea it's there.
Nothing for internal tools. If the integration list is closed, the systems only your team runs stay invisible to the agent.
What we built
A connection is a credential for one service: an AWS account, a Kubernetes cluster, a GitHub organization, a Datadog account. Connections give agents access through the Model Context Protocol (MCP), an open standard for giving AI agents tools.
Connect a service once and every agent in the workspace can use it, with no separate setup.
01Your systems
Where the evidence lives
- Cloud and infrastructureAWS, Google Cloud, Azure, Kubernetes, SSH
- TelemetryDatadog, Grafana, Prometheus, Sentry
- Code and ticketsGitHub, GitLab, Jira, PagerDuty
- Your own toolsAnything that exposes an MCP server
One credential per service
02Connections
One integration layer
- Model Context ProtocolOne open standard for every tool
- Tested on connectTesting, then Connected
- Scoped by the credentialThe outer limit for every agent
- Controlled per toolAlways allow, Needs approval, Never allow
Connect once
03The work
Every agent in the workspace
- CloudThinkerAnd the subagents it spawns
- Custom agentsDefined by your team
- ModulesResolve, Review, Optimize, Cyber
- AutomationsScheduled work on the same connections
No separate setup per agent
The catalog spans cloud platforms, infrastructure and access, databases, messaging, observability, CI/CD, incident and ticketing, and security tools. When a service isn't in it, you add it as a custom MCP connection, with no connector code.
How a connection comes online
Adding one is four steps: pick the service, create least-privilege credentials (read-only wherever possible), enter them under Connections, and verify with a question. CloudThinker tests the credentials in the background, so the status reads Testing first, then Connected.
01Credential
Least privilege
Read-only wherever possible. Widen it later if you want changes.
02Test
Testing, then Connected
CloudThinker checks the credential in the background.
03Discovery
One read-only pass
A first investigation of how the service is set up.
04Results
Evidence and opportunities
Observations that cite their reads, plus notes saved to workspace memory.
The first time a connection reaches Connected, CloudThinker starts discovery: a one-time, read-only investigation of the new service. It never changes anything. It publishes Evidence, observations about how the service is set up, each citing the read that produced it. It also publishes Opportunities: a related service worth connecting, or a recurring task you can accept as an automation.
Each discovery run saves notes about the service to workspace memory, so the next investigation on that connection starts already oriented.
Custom MCP: your tools, same layer
Any service that exposes an MCP server can join the same layer. The server must be reachable from CloudThinker over HTTPS and speak Streamable HTTP or SSE.
You give it a Prefix, and its tools appear to agents as prefix__tool_name. A server with prefix weather that exposes get_forecast becomes weather__get_forecast.
Authentication goes in Headers, sent on every request, typically Authorization: Bearer <token>. The URL must not embed credentials. For basic auth, put Basic <base64(user:password)> in the Authorization header instead.
Scoped by design
The integration layer is also where the limits live.
01Credential
The outer limit
No agent sees or does more than the connection allows.
02Served tools
What exists at all
A tool your MCP server does not serve cannot be called.
03Tool permission
Per tool, per call
Always allow, Needs approval or Never allow, set on each tool.
04Status
Error stops the schedule
Background work that depends on a broken connection waits.
The credential is the outer limit. Agents can only see and act on what the workspace's connections allow. A read-only credential makes a read-only agent, whatever the prompt says.
Served tools are a hard edge. For custom MCP, the docs put it plainly: a tool your server doesn't serve can't be called, which is a stronger boundary than any setting inside CloudThinker. Issue the server a credential dedicated to CloudThinker, and expose only the tools agents should have.
Tool Permissions work per tool. Each connection tool can be Always allow, Needs approval or Never allow. A read tool can need approval too. A disabled tool is hidden from agents entirely. Tool Permissions are the Manual-mode control. With Auto Mode on, Auto Mode decides instead, so you still choose what runs on its own and what waits.
A broken connection stops its schedule. When background credentials stop working, the connection flips to Error and workspace admins get one notification per outage, not one per retry. Scheduled work that depends on it waits: Optimize cost refreshes, scheduled automations, Pulse alert polling. When the status returns to Connected, everything resumes on the next cycle.
The decisions behind it
An open protocol over closed connectors. Built-in connections and your own MCP servers reach agents the same way. Your internal tool doesn't need us to ship an integration.
Connect once, not per agent. One credential per service, shared by every agent in the workspace, means one place to scope it, rotate it and revoke it.
Read-only first. Adding a connection starts with least-privilege credentials. Discovery is read-only. Widening access is a deliberate step you take later.
Credentials stay out of chat. Connections hold access to your cloud, databases and monitoring tools. Other run-time secrets go in workspace Credentials, which reject reserved prefixes like AWS_ and KUBECONFIG because that access belongs to Connections. More in The Agent Never Holds Your Keys.
Honest limits
- A custom MCP server has to be reachable from CloudThinker over HTTPS. If CloudThinker can't reach it, it can't connect.
- Header credentials are sent on every request. Your server should validate them each time, and you rotate them on your own schedule.
- A connection is only as narrow as the credential behind it. If you hand over an admin key, the agent's outer limit is admin.
- The other direction, CloudThinker as an MCP server for your IDE, isn't available yet. Today MCP runs one way: CloudThinker agents call your servers.
- Chat platforms (Slack, Microsoft Teams, Google Chat) are workspace integrations, not connections.
Try it
No credentials ready? A new workspace can use a shared, read-only demo environment for Kubernetes, AWS, Google Cloud or Azure, when its demo target is available. Agents can read it but never change it.
With your own connection in place, start with:
"Give me an overview of the Kubernetes cluster: what runs where, anything unhealthy, and what you'd look at first."
For a custom MCP server, the docs' own check:
"List the tools available from my custom MCP connection and call the simplest read-only one to confirm it responds."
Start a trial or book a walkthrough.