Pangea Docs FAQ Get early access

Docs / Connectors

Connectors

Connect team tools and personal accounts, control who can use each one, and choose which ones a conversation may use.

Connect the systems your work needs: source control, issue trackers, cloud accounts, observability, databases and documents. You can start with local code and add connections later. Coding work does not need a cloud account.

For what each connector lets you and the agent do, see What each connector can do.

How connecting works

There are two kinds of connections.

Team connectors

A team connector is shared by the team. Only Admins can add one.

  1. Open Connectors in the sidebar.
  2. Find the connector and click Add. On a connector that already has connections, click Add connection.
  3. Follow the dialog. Depending on the provider, you set up cloud trust, authorize in your browser, or paste a token.

Once connected, the row shows Connected, or Needs attention when a connection has a problem.

Personal Credentials

For your own GitHub, Linear, Gmail or Google Drive, use Settings → Account → Personal Credentials. The agent then acts as you: it uses these accounts when you send a message, and for automated runs in conversations you own.

Who can use a connection

Each team connection has its own Access List, which an Admin edits with Manage access on the connector's page. It controls which team members can use the connection, including from their agents.

Pangea checks the list on every credential request. See Access control.

Choose connections per conversation

Each conversation uses only the connections selected for it. Pick them in the composer under Agent credentials. You can select all, clear all, or pick single accounts and roles. Your role, the access lists and the provider's own permissions still apply.

Some entry points start with a different selection. For example, a conversation started over MCP starts with every credential you can use, except Resend, which sends email. Review the selection before you work with production.

Authentication depends on the provider

Mechanism Examples What to review
Federated identity or impersonation AWS, Google Cloud, Azure, Tencent Cloud, Alibaba Cloud, Volcengine, Huawei Cloud Team-pinned trust and the role's IAM permissions
OAuth GitLab, Linear, PostHog, Cloudflare, Sentry Account, projects, granted scopes and revocation
Encrypted API token or client secret Notion, Grafana, Linode, Hetzner, Upstash Token owner, reach, rotation and expiry

Short-lived access tokens do not mean that no integration stores a long-lived refresh token or secret. See IAM trust model.

A local runtime may also use sign-ins that are already on its computer. Selecting connections does not remove those sign-ins.

Find a connection

Some connectors have their own resource pages in the app. Others work through the agent. A resource list in the app does not limit what the authorized provider CLI or API can do.

Read, change and automate

A Watch turns an alert into agent work. It needs a provider notification path, a Pangea trigger, an approved destination when it posts to chat, a test run and a clean-up plan. Slack is the main incident-delivery path, so don't assume every chat integration supports every Watch destination. The Monitoring view brings together Grafana, Better Stack and Google Cloud. Other providers have their own pages.

Verify and disconnect