Connectors

Connectors give the agent secure, governed access to the systems your organization already uses, so Infracodebase becomes a single pane of glass for infrastructure operations. A connector can reach a cloud provider, source control, or a SaaS tool, and the agent uses it to gather context and take action without leaving the platform.

For example, the Terraform connector lets the agent connect to Terraform Cloud or Enterprise, look up modules, check provider versions, and pull configuration details. The GitHub connector lets it work with repositories, issues, and pull requests. Cloud connectors like AWS, Azure, and Google Cloud let it work against your accounts through their CLIs.

How connectors are modeled

There are three levels, and it helps to keep them straight:

Connector is the integration template (AWS, GitHub, Terraform) you add from the Connectors page. It defines how the integration authenticates and which surfaces it can serve.
Connection is a named instance of a connector that you add to your enterprise, with its own credential. You can add more than one connection of the same connector, for example "AWS Production" and "AWS Staging", each with its own account.
Surface is how a connection reaches the agent: an MCP tool, the agent's CLI shell (for tools like gh, git, aws), or both.

The agent sees one tool per connection, named by the connection, so two accounts of the same connector are distinct and selectable independently.

Adding a connector

Browse the available connectors at Connectors. When you find one you need, add it to your enterprise. Adding a connector creates a connection, which you then configure.

To add a second account of a connector you have already added, open the connection's menu and choose Add another account, then give it a name. You can rename any connection at any time from its menu, whether it is the only instance or one of several.

Authentication

Each connection decides who authenticates under "Who authenticates?":

Each user uses per-user OAuth: every member connects their own account, and the agent acts as that member. This is the right choice when actions should be attributed to the individual.
Shared uses one organization credential (an API key or token) for everyone.
Both lets members act as themselves, with a shared credential as a fallback for anyone who has not connected.

Per-user connections are isolated per company: a member can only connect a connection that the enterprise has enabled, and is governed and revoked per enterprise.

When a connection uses a shared credential, you provide it under Edit Connection. Credentials are stored as encrypted, connection-scoped secrets. Two connections of the same connector hold separate credentials.

Scope your credentials appropriately. Use accounts or tokens with the minimum permissions needed. If the agent only needs to read state, do not give it write access. Review the permissions of each credential you provide and follow the principle of least privilege.

Where it works (surfaces)

Under "Where it works", a connection can serve the MCP tool, the CLI shell, or both. Turning on CLI injects the connection's credential into the agent's shell so commands like gh, git, and the cloud CLIs act as that connection.

A note on multiple accounts and the CLI: the MCP surface supports several accounts of one connector at once, because each connection is its own tool with its own credential. The CLI shell holds one identity per tool (one GH_TOKEN, one set of AWS keys), so only one connection of a given connector should serve the CLI in a workspace. Keep extra instances MCP-only. Per-tool multi-account support on the CLI (named AWS profiles, gh account switching) is on the roadmap.

Granular tool control

Each connection exposes a set of individual tools. You get granular control over which are available:

An Enabled toggle turns the whole connection on or off.
Individual tool toggles disable specific tools while keeping the rest active.

For example, if a connection provides ten tools but three are not appropriate for your organization, disable just those three and the agent keeps the other seven.

Connection status

The Connectors settings page shows the status of each connection:

Connected for a working shared credential.
Per-user OAuth for an each-user connection (each member connects themselves).
Missing Credentials when a shared credential is required but has not been provided.
Disabled, Connection Failed, or Not Configured as applicable.

For shared connections you can test the connection after providing credentials to verify everything works.

Enterprise vs. workspace

Connections are enabled at the enterprise level, then governed per workspace. In each workspace's Connectors settings you choose which connections to turn on for that project, and each instance is enabled independently. A connection marked Required by an admin is always on and cannot be disabled per workspace.

Within a session, the agent's tool picker lists the workspace-enabled connections. An each-user connection shows an inline Connect until the member has personally connected that instance.

Connecting your own account

When a connection uses per-user OAuth, members connect their own account from Settings → Connections. Each connection of a connector appears as its own entry there, so a member connects each instance independently. Shared connections are not listed, since they use one organization credential rather than a personal login.

Runtime isolation

Each agent session gets its own MCP server processes, spawned fresh as isolated child processes with their own credentials and terminated when the session ends. They are not shared or pooled between users or sessions, so one member's credentials are never visible to another, even for the same connector.

Adding your own connector

In addition to the available connectors, you can connect the agent to your own MCP servers, which is useful for custom tooling, internal APIs, or proprietary systems. From the Connectors settings page choose Add Custom, then paste a JSON configuration snippet from any MCP server's documentation.

Here is an example configuration for a custom connector:

{
  "name": "internal-deploy",
  "description": "Internal deployment pipeline API",
  "transport": "sse",
  "url": "https://deploy-api.internal.yourcompany.com/mcp",
  "headers": {
    "Authorization": "Bearer ${DEPLOY_API_TOKEN}"
  }
}

The name identifies the connector in your list, description explains what it connects to, transport is the connection protocol, and url is where the MCP server runs. Any credential referenced in the configuration, like ${DEPLOY_API_TOKEN}, should be stored as a secret so it is encrypted and not exposed in the configuration. Once added, a custom connector behaves like any other: the same tool control, status monitoring, runtime isolation, and per-workspace governance.

Coming soon

We are working on support for connecting to MCP servers running behind your own VPC or virtual network, so the agent can reach data and services inside your private infrastructure without exposing them to the public internet.